DNS查詢怎麼查？A、CNAME、MX、TXT記錄怎麼看

DNS 查詢是排查域名解析、網站訪問和企業信箱問題最常用的方法之一。本文將介紹 DNS 查詢的基本操作，並重點講解 A、CNAME、MX、TXT 四類常見記錄的作用、查詢方法和結果判斷，幫助站長快速確認域名是否正確解析到伺服器、CDN 是否生效，以及信箱和域名驗證設定是否正常。

Chahu 團隊2026-08-245 分鐘閱讀

網站突然打不開、域名剛改完解析卻一直不生效、CDN 已經接入但不知道有沒有真正切過去，或者企業信箱設定完成後還是收不到郵件，這些問題看起來各不相同，實際排查時往往都繞不開同一個環節：DNS 查詢。透過 DNS 查詢能夠確認一個域名目前到底傳回了什麼解析結果。網站常見的 A、CNAME 記錄，企業信箱常用的 MX、TXT 記錄，都可以透過 DNS 查詢看到。

對站長來說，真正重要的並不是記住所有 DNS 術語，而是弄清楚一件事：查到這些記錄之後，該怎麼看結果是否正常。本文就從實際排查角度出發，講清楚 DNS 怎麼查，以及 A、CNAME、MX、TXT 這幾種常見記錄分別應該怎麼看。

一、DNS查詢到底是在查什麼？

平時我們訪問一個網站時，瀏覽器並不是直接透過 example.com 這樣的域名找到伺服器。在真正發起連線之前，需要先經過 DNS，把域名轉換成伺服器能夠辨識的位址，或者找到下一步應該訪問的服務目標。一個最簡單的過程大致是：

輸入域名
↓
DNS查詢
↓
取得解析記錄
↓
找到對應伺服器或服務位址
↓
建立連線

所以，當網站訪問異常時，DNS 是一個非常適合優先檢查的位置。比如你剛把網站從舊伺服器遷移到了新伺服器，如果 DNS 仍然傳回舊 IP，那麼不管新伺服器設定得多完善，使用者還是會繼續訪問舊環境。

類似的問題還包括：

CDN 已經設定，但域名仍然沒有指向 CDN CNAME
企業信箱的 MX 記錄寫錯，外部郵件無法投遞
TXT 驗證記錄沒有正確發布，第三方平台一直提示驗證失敗
DNS 修改後部分地區仍然傳回舊記錄

這些情況，都可以先透過 DNS 查詢確認目前對外生效的記錄。

二、DNS查詢怎麼查？

想查某個域名的解析對不對，最省事的方法就是透過 chahu DNS 查詢工具。直接把域名丟進去，分分鐘就能出結果。

整個過程其實就幾步：

輸入域名 ➔ 選擇記錄類型（比如 A、CNAME） ➔ 提交查詢 ➔ 盯著傳回的 IP、郵局解析（MX）或者 TXT 記錄看看對不對。

不過新手最容易在兩個小細節上踩坑：

第一，別把一整串網址直接貼進去。 DNS 查的是域名本身，比如 [www.example.com](https://www.example.com) 就夠了。千萬別帶上前面的 https:// 或者後面的路徑 /product/123，那些是網頁位址，DNS 可不管這些。

第二，帶 www 和不帶 www 是兩碼事。 example.com（根域名）和 [www.example.com](https://www.example.com) 在 DNS 裡很可能是分開設定的。比如根域名直接綁了伺服器 IP，而帶有 www 的那個反而加了 CDN 或是掛了 CNAME。你的網站平時是用哪個位址訪問的，就查哪個，別只查個根域名就以為萬事大吉了。

三、A記錄怎麼看？

A 記錄是網站 DNS 設定中最常見的一種記錄。它的作用是把域名解析到一個 IPv4 位址。比如：

www.example.com
↓
203.0.113.20

當使用者訪問 www.example.com 時，DNS 傳回 203.0.113.20，瀏覽器隨後再去連線這個 IP 對應的伺服器。

查詢A記錄時，最重要的是看IP是否正確

假設網站剛換了一台伺服器，新伺服器 IP 是：203.0.113.20。但 DNS 查詢結果仍然顯示：198.51.100.15。這說明目前對外解析仍然指向舊伺服器。這時應該繼續檢查：

DNS 記錄是否真的修改成功
是否修改到了正確的 DNS 服務商
TTL 快取是否還未過期
查詢的主機名稱是否正確

如果查詢結果已經變成了新 IP，那麼 DNS 層面基本已經切換完成，後續可以繼續排查伺服器、網站程式或者快取。

一個域名出現多個A記錄正常嗎？

正常。有些網站為了做負載平衡、容災或者 DNS 輪詢，會同時傳回多個 IP。例如：

203.0.113.20
203.0.113.21
203.0.113.22

看到多個 A 記錄並不代表解析錯誤。真正需要確認的是：這些 IP 是否都屬於你的業務架構，是否存在已經停用卻仍然保留的舊位址。

四、CNAME記錄怎麼看？

CNAME 和 A 記錄最大的不同，在於它通常不是直接指向 IP，而是指向另一個域名。

例如：

www.example.com
↓
abc123.cdn.example.net
↓
CDN節點IP

這類設定在 CDN、SaaS 平台、雲端服務和第三方代管服務裡非常常見。

為什麼CDN經常使用CNAME？

因為 CDN 節點 IP 並不是固定不變的。服務商可以根據使用者位置、網路狀態和節點負載，把同一個 CNAME 動態排程到不同的邊緣節點。如果使用者直接寫死一個 A 記錄，就很難實現這種靈活排程。所以接入 CDN 時，經常會看到服務商要求新增類似：

www.example.com
CNAME
abc123.provider.net

怎麼判斷CNAME是否已經生效？

最直接的方法，就是查詢實際業務域名。假設 CDN 後台要求設定：

www.example.com
CNAME
abc123.provider.net

那麼 DNS 查詢結果中應該能夠看到對應的 CNAME 目標。如果仍然顯示舊記錄，或者完全查詢不到 CNAME，就說明 DNS 切換可能還沒有真正完成。

常見原因包括：

DNS 修改後快取還沒有更新
CNAME 主機記錄填寫錯誤
域名實際使用的是另一家 DNS 代管服務
原有解析規則存在衝突
修改了根域名，但實際訪問的是 www

接入 CDN 後，不建議只看控制台裡顯示「設定成功」。

更穩妥的做法，是直接查詢實際業務域名，確認公開 DNS 傳回結果是否已經指向 CDN 提供的 CNAME。

五、MX記錄怎麼看？

如果說 A、CNAME 主要跟網站訪問有關，那麼 MX 記錄主要負責郵件。MX 是 Mail Exchange 的縮寫，它告訴網際網路：發往這個域名的郵件，應該交給哪台郵件伺服器處理。

例如：

example.com

MX 10 mail1.example.com
MX 20 mail2.example.com

這裡的 mail1.example.com 和 mail2.example.com 就是郵件伺服器。

MX前面的數字是什麼意思？

前面的數字表示優先順序。

一般來說：

數字越小，優先順序越高。

例如：

MX 10 mail1.example.com
MX 20 mail2.example.com

通常會優先嘗試 mail1.example.com，如果第一台伺服器不可用，再根據設定嘗試其他 MX 伺服器。

不過實際設定還是應該以郵箱服務商提供的記錄要求為準，不要自行修改優先順序。

企業信箱收不到郵件時，MX重點看什麼？

如果企業信箱突然收不到外部郵件，可以先檢查：

MX 記錄是否存在
郵件伺服器位址是否正確
是否仍然殘留舊郵箱服務商的記錄
MX 優先順序是否符合服務商要求
最近是否更換過 DNS 或郵箱平台

比如原來使用 A 郵箱服務，後來切換到 B 服務，但舊 MX 沒有刪乾淨，就可能造成部分郵件投遞異常。這種問題只看郵箱後台不一定馬上能發現，透過 DNS 查詢反而更直觀。

六、TXT記錄怎麼看？

TXT 記錄經常是新手最不容易看懂的一類。

因為查詢結果通常不像 A 記錄那樣簡潔，而是一長串文字。

例如：

v=spf1 include:_spf.example.com ~all

這通常是一條 SPF 相關的郵件驗證記錄。

TXT 的用途非常多，常見的包括：

SPF
DKIM
DMARC
Google Search Console 驗證
Microsoft 365 域名驗證
第三方 SaaS 平台驗證
SSL 或域名所有權驗證

所以查詢 TXT 時，不需要看到一串字元就急著理解每一個參數。

大多數場景下，更重要的是：

查詢出來的值，是否和平台要求你新增的值完全一致。

比如某個平台要求新增：

google-site-verification=abc123xyz

如果 DNS 查詢結果裡完全找不到這條內容，說明記錄可能沒有正確發布。

如果已經能查詢到，但平台仍然驗證失敗，就繼續檢查：

TXT 內容是否缺少字元
是否多了空格或引號
主機記錄是否填寫錯誤
是否新增到了錯誤的域名
DNS 是否還處在傳播過程中

七、A、CNAME、MX、TXT有什麼區別？

如果把這幾種常見記錄放在一起看，會更直觀。

DNS記錄	主要作用	常見場景	查詢時重點看什麼
A	域名指向IPv4位址	網站、伺服器	IP是否正確
CNAME	域名指向另一個域名	CDN、SaaS、雲端服務	CNAME目標是否正確
MX	指定郵件伺服器	企業信箱	郵件伺服器和優先順序
TXT	儲存驗證或策略文字	SPF、DKIM、域名驗證	文字內容是否完整

簡單記的話，可以理解成：

網站IP問題，先看A
CDN或別名解析，先看CNAME
收發郵件異常，先看MX
郵箱認證或域名驗證，先看TXT

這樣實際排查時，就不會面對一堆 DNS 記錄不知道先看哪個。

八、DNS記錄已經修改，為什麼查詢結果還是舊的？

這是域名解析裡非常常見的問題。

後台明明已經點了儲存，但外部查詢仍然顯示舊記錄，並不一定說明操作失敗。

1. DNS快取還沒有過期

DNS 記錄通常帶有 TTL，也就是快取時間。

例如：

TTL = 3600

表示相關 DNS 快取可能會儲存一段時間。

修改解析後，不同地區、不同遞迴 DNS 的快取更新時間並不會完全同步，所以短時間內可能出現：

有些地方已經傳回新記錄
有些地方仍然傳回舊記錄

這種情況在 DNS 切換過程中並不少見。

2. 修改錯了DNS服務商

域名在哪裡買，和 DNS 實際代管在哪裡，是兩回事。

例如域名是在註冊商 A 購買的，但 NS 已經改到了 DNS 服務商 B。

這時如果你還在註冊商 A 的解析面板裡修改記錄，很可能不會真正對外生效。

遇到這種情況，可以查詢域名的 NS 記錄，確認目前權威 DNS 到底由誰代管。

3. 查錯了主機名稱

比如你修改的是：

www.example.com

但查詢的是：

example.com

兩者對應的是不同 DNS 記錄。

類似地，api.example.com、mail.example.com、shop.example.com 也都應該分別查詢。

4. 本機快取還沒有更新

如果線上 DNS 查詢已經顯示新記錄，但自己電腦仍然訪問舊伺服器，那麼問題可能已經不在權威 DNS，而是在本機快取。

常見快取位置包括：

作業系統 DNS 快取
瀏覽器快取
路由器快取
本地網路使用的遞迴 DNS

這種情況下，可以換一個網路環境或 DNS 伺服器再次測試，看結果是否一致。

九、網站和郵箱問題，可以按這個順序查DNS

如果是網站打不開、CDN 不生效，可以按照下面的順序排查：

網站訪問異常
↓
查詢A / CNAME
↓
確認解析目標是否正確
↓
檢查NS是否屬於目前DNS服務商
↓
查看TTL和解析傳播情況
↓
DNS正常後繼續檢查伺服器或CDN

如果是企業信箱收發異常，則更適合：

郵件異常
↓
查詢MX
↓
確認郵件伺服器
↓
查詢TXT
↓
核對SPF / DKIM / DMARC
↓
再檢查郵箱平台設定

這種排查方式的好處是，先把最基礎的解析層確認清楚，再繼續看伺服器、CDN、郵箱系統或者網站程式，不容易在錯誤的方向上浪費時間。

DNS 查詢本身並不複雜，難點在於查到結果之後，知道哪條記錄和目前問題有關。網站解析到錯誤伺服器，重點看 A；接入 CDN 後想確認是否生效，重點看 CNAME；企業信箱收不到郵件，先查 MX；做 SPF、DKIM 或第三方域名驗證，則重點核對 TXT。

如果剛修改過解析，也不要只看後台是否「儲存成功」。透過實際 DNS 查詢確認公開網路已經傳回正確記錄，才算真正完成了這一步。對站長和維運人員來說，養成先查 DNS 再排查其他環節的習慣，很多網站訪問、CDN 接入和企業信箱問題都會更容易定位。