DNS記錄型別參考指南
彙總執行郵件和網站所需的DNS記錄型別——A、MX、TXT、SPF、DKIM、DMARC等——並說明每種記錄的用途、格式示例與注意事項。
| 型別 | 用途 | 格式示例 | 注意事項 |
|---|---|---|---|
| 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 標籤是選用的：不指定時，issue 的設定同樣適用於萬用字元證書。只有在需要讓萬用字元證書由其他CA簽發或禁止簽發時才使用它。 |
| PTR記錄 | 通過IP地址反查主機名（與A記錄方向相反），配置在反向解析區域（in-addr.arpa / ip6.arpa）中。 | 1.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com. |
許多郵件伺服器會將反向PTR未設定或與A記錄不一致的來源郵件標記為垃圾郵件或直接拒收，因此這幾乎是發件伺服器的必備配置。 |
DNS 記錄的種類與各自的用處一覽
這是一份參考清單，把網站營運與郵件投遞所需的 DNS 記錄——A、AAAA、CNAME、MX、TXT、SPF、DKIM、DMARC——連同各自的用處、格式範例與當心之處一併羅列。拿不準該寫哪條記錄、寫在何處時，來此一查便是。
此處最不為人知的陷阱，是 CNAME 不能置於區域的頂點，也就是 example.com 本身。 CNAME 宣告某個名稱是別名，故同一名稱之下再容不下別的記錄。可頂點又非有 NS 與 SOA 不可，於是想用 CNAME 把 example.com 指向 CDN，按規格便是辦不到的。 許多服務商以 ALIAS 或 ANAME 這類自有記錄繞開此事。另一件要弄明白的是 TTL，它言明各解析器可將一個答案快取多少秒。 若有遷移在即，通行的做法是在動手數日之前先把 TTL 調短。
使用方法
- 找到您所需的記錄種類 各條按類型歸攏：A、MX、TXT 等等。
- 查看格式的範例 最容易寫錯之處——主機名怎麼寫、末尾該不該帶點——都可在此核對。
- 閱讀當心之處 其中列出了實務中真正會絆人的地方：CNAME 的限制、TTL 的處置等等。
- 用相關工具去驗證 設好之後，便可去查散布情況，或診斷認證類記錄。
用好本工具的小技巧
- 如果對SPF、DKIM、DMARC的配置感到困惑，建議先用“SPF/DKIM/DMARC記錄檢測”工具診斷當前記錄，再與本頁的格式示例對照，效率更高。
- 普通記錄的TTL設為1小時（3600秒）左右較為穩妥；僅在DNS遷移前夕臨時縮短到300秒左右，切換後再恢復，可以讓生效更快。
- TXT記錄的值超過255個字元時可能會被自動拆分為多個字串，複製貼上時請確認引號數量是否正確。
- 如果還想檢查郵箱地址本身的格式是否正確，可以配合使用“郵箱地址格式驗證”工具，避免遺漏。
- 引入新的郵件傳送服務時，建議先以 p=none 執行DMARC並觀察1〜2周的報告，確認無異常後再切換到正式的執行策略，更為穩妥。
這些情境會用到
新設一個網域
可弄清最起碼需要哪幾條記錄。
添一處發信來源
需要補寫 SPF 或 DKIM 時，可在此核對格式。
遷移伺服器
可以明白為何應在遷移之前先把 TTL 調低。
查一個術語的意思
設定介面上那些欄位名的含義，當場便查得到。
DNS 記錄的術語
- A 記錄
- 把主機名對應到 IPv4 位址。AAAA 記錄則是它的 IPv6 對應物。
- CNAME 記錄
- 使某個名稱成為另一名稱的別名。因同名之下不容別的記錄，故不可用於區域的頂點。
- MX 記錄
- 指明由哪台伺服器接收該網域的郵件。優先順序的數字越小，越先被嘗試。
- TXT 記錄
- 可容納任意文字的記錄。SPF、DKIM 與 DMARC 皆以此形寫就。
- TTL
- 各解析器可將一個答案快取的秒數。遷移之前把它調短，變更便能迅速散開。
- 區域的頂點
- 不帶
www之類前綴的網域本身，即example.com。此處放不得 CNAME。
常見問題
閒話 ― 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極高的可擴充套件性。