DNS記錄型別參考指南
彙總執行郵件和網站所需的DNS記錄型別——A、MX、TXT、SPF、DKIM、DMARC等——並說明每種記錄的用途、格式示例與注意事項。
DNS記錄型別一覽
| 型別 | 用途 | 格式示例 | 注意事項 |
|---|---|---|---|
| A記錄 | 最基本的記錄型別，將域名對映到IPv4地址，指出Web伺服器或郵件伺服器的實際所在位置。 | example.com. 3600 IN A 192.0.2.1 |
TTL（此例中為3600秒，即1小時）設定過短會增加對權威DNS伺服器的查詢次數、加重負載；設定過長則會延遲IP地址變更後的生效時間。 |
| AAAA記錄 | 將域名對映到IPv6地址，相當於A記錄的IPv6版本。 | example.com. 3600 IN AAAA 2001:db8::1 |
同時保留A記錄可以讓不支援IPv6的網路回退到IPv4連線（雙棧執行）。 |
| CNAME記錄 | 將一個主機名指向另一個規範主機名作為別名，例如將 www.example.com 指向 example.com。 | www.example.com. 3600 IN CNAME example.com. |
設定了CNAME的主機名不能再共存其他記錄（如MX、TXT，這是RFC 1034的限制）。域名根（@）也不能設定CNAME。 |
| MX記錄 | 指定該域名的郵件應由哪臺郵件伺服器接收，可通過優先順序（preference值）指定多臺伺服器。 | example.com. 3600 IN MX 10 mail.example.com. |
數值越小優先順序越高。為實現冗餘，通常會設定多個不同優先順序的伺服器。MX指向的必須是擁有A記錄的主機名，而不能是CNAME。 |
| TXT記錄 | 為域名附加任意文本資訊的通用記錄，常用於SPF、DKIM、DMARC，以及域名所有權驗證等多種用途。 | example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all" |
一個域名可以設定多條TXT記錄，但同一用途（如SPF）的記錄若重複設定會導致解析錯誤，需要合併為一條。 |
| SPF記錄（TXT記錄的一種） | 列出被允許代表該域名傳送郵件的伺服器（IP地址），是一種防止郵件偽造的發件人認證機制，以TXT記錄的形式配置。 | example.com. 3600 IN TXT "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all" |
每個域名只能有一條有效的SPF記錄。DNS查詢次數上限為10次，超過會導致永久性錯誤，需注意include的巢狀層數。專用的記錄型別（RRTYPE 99）已於2014年廢棄，如今統一使用TXT記錄表示SPF。 |
| DKIM記錄（TXT記錄的一種） | 為郵件附加數字簽名，用以驗證郵件在傳輸過程中未被篡改、且確實來自合法發件人。公鑰以TXT記錄形式公開。 | selector._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..." |
主機名字首（選擇器selector）因發件服務商而異。私鑰儲存在傳送伺服器一側，DNS中只公開公鑰。 |
| DMARC記錄（TXT記錄的一種） | 基於SPF和DKIM的驗證結果，宣告對認證失敗的郵件應如何處理（放行、隔離或拒收），並提供接收匯總報告的渠道。 | _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]" |
建議先以 p=none 僅進行監控，確認沒有問題後再逐步提升到 quarantine、reject，這是較為安全的部署方式。 |
| NS記錄 | 標明該域名（區域）的權威DNS伺服器是哪些，是整個域名解析的起點。 | example.com. 86400 IN NS ns1.example-dns.com. |
如果在註冊商處登記的域名伺服器與區域內的NS記錄不一致，會導致名稱解析不穩定（稱為“跛腳委派”，lame delegation）。 |
| SOA記錄 | 儲存區域的管理資訊（主伺服器、管理員郵箱、序列號、重試間隔等），每個區域必須且只能有一條。 | example.com. 86400 IN SOA ns1.example-dns.com. admin.example.com. (2026071200 3600 900 604800 86400) |
更新區域檔案後必須遞增序列號，否則從伺服器不會通過區域傳送獲取到變更內容。 |
| CAA記錄 | 限制哪些證書頒發機構（CA）可以為該域名簽發證書，防止非預期的CA簽發出惡意證書。 | example.com. 3600 IN CAA 0 issue "letsencrypt.org" |
如果域名沒有任何CAA記錄，則視為任何CA都可以簽發證書。萬用字元證書需要另外指定 issuewild 標籤。 |
| PTR記錄 | 通過IP地址反查主機名（與A記錄方向相反），配置在反向解析區域（in-addr.arpa / ip6.arpa）中。 | 1.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com. |
許多郵件伺服器會將反向PTR未設定或與A記錄不一致的來源郵件標記為垃圾郵件或直接拒收，因此這幾乎是發件伺服器的必備配置。 |
使用提示
- 如果對SPF、DKIM、DMARC的配置感到困惑，建議先用“SPF/DKIM/DMARC記錄檢測”工具診斷當前記錄，再與本頁的格式示例對照，效率更高。
- 普通記錄的TTL設為1小時（3600秒）左右較為穩妥；僅在DNS遷移前夕臨時縮短到300秒左右，切換後再恢復，可以讓生效更快。
- TXT記錄的值超過255個字元時可能會被自動拆分為多個字串，複製貼上時請確認引號數量是否正確。
- 如果還想檢查郵箱地址本身的格式是否正確，可以配合使用“郵箱地址格式驗證”工具，避免遺漏。
- 引入新的郵件傳送服務時，建議先以 p=none 執行DMARC並觀察1〜2周的報告，確認無異常後再切換到正式的執行策略，更為穩妥。
常見問題
SPF驗證的是“郵件是從哪臺伺服器發出的”，即發件IP地址的合法性；DKIM則通過數字簽名驗證“郵件內容是否被篡改”。只有兩者都通過，發件人認證才能發揮充分的效果。
雖然不是法律強制要求，但Gmail、Yahoo郵箱等主要收件服務商實際上已將DMARC設為大批次發件人的事實標準，未設定會顯著增加被判定為垃圾郵件或被拒收的風險。
常見原因包括MX指向的是CNAME而非擁有A記錄的主機名、優先順序數值設定錯誤，或郵件伺服器本身未配置為接收該域名的郵件。
如果IP地址固定且需要設定在域名根（@）上，應使用A/AAAA記錄；如果只是想讓該主機名作為其他主機名的別名（例如指向CDN地址），則應使用CNAME。
正常執行時通常設為1小時（3600秒）左右即可。僅在伺服器遷移或DNS切換前夕臨時縮短到300秒左右，切換後生效會更快。
閒話 ― DNS記錄與郵件認證的歷史
DNS通常被理解為將域名對映到IP地址的機制，但實際上除了A、AAAA記錄之外還定義了許多其他型別，各自承擔不同的角色。尤其在郵件傳輸領域，MX、TXT（承載SPF/DKIM/DMARC）、PTR等多條記錄必須協同工作，才能判定一封郵件是“未被偽造的合法郵件”，只要缺少其中一項，被歸入垃圾郵件資料夾或被拒收的風險就會顯著上升。
回顧發件人認證的歷史，SPF在21世紀初作為反垃圾郵件的對策被提出，隨後以檢測郵件內容是否被篡改為目的的DKIM於2007年前後被標準化。然而兩者各自都沒有規定“認證失敗後應如何處理”，為了填補這一空白，DMARC於2012年誕生。DMARC綜合評估SPF與DKIM的結果，提供失敗時的處理策略以及結果報告機制，可以說是認證體系的“指揮中樞”。
部分DNS記錄因歷史原因經歷過規格變化。例如專用於SPF的記錄型別（RRTYPE 99）曾在2006年的RFC中被定義過一次，但因引發實現上的混亂，已於2014年由RFC 7208正式廢棄，如今統一隻用TXT記錄來表示SPF。同樣，DKIM和DMARC也沒有專屬的記錄型別，全部以特定格式（以 v=DKIM1、v=DMARC1 開頭的字串）嵌入TXT記錄之中，這也體現了DNS極高的可擴充套件性。