別再猜你的 DNS：給開發者看的 MX、SPF、DKIM 與 DMARC 導覽

為什麼電子郵件 DNS 記錄現在很重要

電子郵件驗證過去是可選項目。到了 2026 年，它已是基本門檻。Gmail 和 Outlook 都會對大量寄件者強制執行 SPF 與 DKIM，而 DMARC 也正快速成為任何寄送交易型電子郵件的網域所必備的項目。如果你的 DNS 記錄錯了，你的電子郵件就不會送達——沒有退信、沒有警告，只有沉默。

問題在於，這些記錄的文件寫得像 RFC，而不像工具說明。多數開發者會從電子郵件服務商的設定指南複製貼上範例，然後祈禱一切順利。這在你需要疑難排解、加入第二個寄送服務，或向客戶解釋為什麼他們的聯絡表單郵件落入垃圾郵件之前，通常都還行。

本指南會依照你實際遇到它們的順序說明 MX、SPF、DKIM 與 DMARC，提供足夠細節讓你正確設定，也提供足夠脈絡讓你在它們出問題時能夠除錯。

MX 記錄：入站電子郵件要送到哪裡

MX 記錄告訴網際網路，哪些郵件伺服器會接收寄給你網域的電子郵件。它們是四者之中最簡單的，但也最容易設定錯誤。

一筆 MX 記錄有兩個部分：優先順序數字與主機名稱。優先順序數字越低，越先嘗試。如果你使用 Google Workspace，你的 MX 記錄可能會像這樣：

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

結尾的點很重要——它們表示該主機名稱是完整限定名稱。多數 DNS 提供者會自動加上它們，但不是全部都會。

常見錯誤包括：把 MX 記錄指向 A 記錄而不是主機名稱、把所有優先順序設成相同數字（這會失去備援的意義），或在遷移服務商時忘了移除舊的 MX 記錄。過期的 MX 記錄不只是無害地待在那裡——它們可能造成郵件迴圈，或讓郵件被分送到兩個收件匣。

如果你正在執行自己的聯絡表單，並希望在不依賴第三方服務的情況下避免垃圾郵件，了解表單如何變成垃圾郵件攻擊媒介會是一個有用的起點。

SPF：哪些伺服器被允許以你的名義寄信

SPF (Sender Policy Framework) 是一筆 TXT 記錄，列出哪些 IP 位址與網域被授權代表你的網域寄送電子郵件。多數郵件伺服器收到聲稱來自你的訊息時，第一個檢查的通常就是它。

基本的 SPF 記錄看起來像這樣：

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

拆解來看：

• v=spf1 宣告 SPF 版本
• include:_spf.google.com 委派給 Google 的 SPF 記錄
• ~all 是軟性失敗——對未列出的來源不要太嚴格，但將其視為可疑

你也可以使用 ip4: 或 ip6: 將特定位址加入白名單，或使用 a 與 mx 參照你網域的 A 與 MX 記錄。結尾的 all 機制控制來自未列出來源的郵件會如何處理：-all 是硬性失敗（拒收）、~all 是軟性失敗（標記為可疑）、?all 是中立（不表態），而 +all 則是全面放行（不要使用）。

SPF 有兩個尖銳邊角。第一，電子郵件轉寄時它會失效，因為轉寄伺服器不在你的 SPF 記錄中。第二，SPF 記錄有十次 DNS 查詢的限制。如果你 include 太多第三方服務，就會超過限制，SPF 也會停止正常運作。解法是扁平化你的 SPF 記錄——用實際 IP 範圍取代 include: 指令——但當服務商變更 IP 時，這需要維護。

DKIM：寄件者身分的密碼學證明

DKIM (DomainKeys Identified Mail) 會在你的外寄電子郵件加上一個數位簽章。接收伺服器會用你發布在 DNS 中的公開金鑰檢查該簽章。如果簽章有效，而且訊息沒有被竄改，DKIM 就會通過。

與 SPF 不同，DKIM 可以撐過轉寄，因為簽章會隨訊息一起傳送。它也更有彈性——你可以為不同寄送服務設定多把 DKIM 金鑰，每一把都有自己的 selector。

DKIM DNS 記錄看起來像這樣：

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

selector（此範例中的 default）是任意的——由你的電子郵件服務商選擇。p= 值是公開金鑰，通常是一串很長的 base64 編碼字串。你的電子郵件服務商會產生私密金鑰，並用它簽署外寄訊息。

DKIM 設定幾乎總是由你的電子郵件服務商處理。你的工作是複製他們提供的 TXT 記錄，並貼到你的 DNS。棘手之處在於，有些 DNS 提供者不太能處理很長的 TXT 記錄——它們可能會截斷，或要求你把值拆成多個加引號的字串。

要驗證 DKIM 是否正常運作，請寄一封測試信到 Gmail 位址並檢查標頭。在 Authentication-Results 標頭中尋找 dkim=pass。

DMARC：政策執行與報告

DMARC (Domain-based Message Authentication, Reporting and Conformance) 會把 SPF 與 DKIM 串在一起，並告訴接收伺服器驗證失敗時該怎麼做。它也會啟用報告功能，讓你看到誰正在以你的網域寄信——包含合法寄件者與偽冒者。

最小化的 DMARC 記錄看起來像這樣：

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none 表示只監控——不要拒收或隔離失敗訊息
• rua=mailto:[email protected] 指定彙總報告要寄到哪裡

一旦你確定 SPF 與 DKIM 都正常運作，就可以把政策收緊為 p=quarantine（將失敗訊息送到垃圾郵件）或 p=reject（直接退信）。你也可以用 sp= 設定子網域政策，並用 pct= 指定套用政策的訊息百分比。

DMARC 報告是主要接收方每天寄出的 XML 檔案。原始內容冗長且難讀，但它們會精確告訴你哪些訊息通過或未通過驗證，以及原因。如果你看到合法郵件被拒收，報告會顯示是哪一項 SPF 或 DKIM 檢查失敗。

有一個陷阱：DMARC 要求對齊。對 SPF 來說，Return-Path 標頭中的網域必須與 From 標頭中的網域相符（或是其子網域）。對 DKIM 來說，DKIM 簽章中的 d= 網域必須與 From 網域相符。如果你使用第三方寄送服務，他們需要支援自訂 return path，或使用你的網域而不是他們的網域進行 DKIM 簽署。

如何稽核你目前的設定

多數 DNS 問題在造成狀況之前都是隱形的。以下是在事情壞掉前檢查記錄的方法：

1. 查詢你的 MX 記錄：dig MX example.com 應該回傳你的郵件伺服器主機名稱與優先順序。確認它們符合你的電子郵件服務商文件。

1. 檢查 SPF 語法：dig TXT example.com 並尋找 v=spf1 記錄。把它丟進 SPF 驗證器，抓出語法錯誤與查詢限制違規。

1. 驗證 DKIM 金鑰：寄一封測試信並檢查 DKIM-Signature 標頭。擷取 selector 與網域，接著查詢 dig TXT selector._domainkey.example.com，確認公開金鑰存在。

1. 驗證 DMARC 政策：dig TXT _dmarc.example.com 應該回傳你的 DMARC 記錄。確認 rua= 指向你真的有監看的位址。

1. 端到端測試：使用像 mail-tester.com 這樣的服務，或寄到 Gmail 位址並檢查完整標頭。在 Authentication-Results 標頭中尋找 spf=pass、dkim=pass 與 dmarc=pass。

如果你正在除錯為什麼電子郵件沒有送達，標頭是你最好的工具。多數郵件用戶端都能查看原始標頭——在 Gmail 中，開啟訊息、點選三個點，然後選擇「顯示原始郵件」。Authentication-Results 標頭會精確告訴你哪一項檢查失敗，以及原因。

何時使用子網域政策

如果你從多個子網域寄送電子郵件——例如用 newsletter.example.com 寄行銷信、用 app.example.com 寄交易型郵件——你可以設定每個子網域各自的 DMARC 政策。這讓你能在自己掌控的子網域上執行嚴格政策，同時在主網域上維持較寬鬆的政策。

取捨在於複雜度。每個子網域都需要自己的 SPF、DKIM 與 DMARC 記錄，而且你需要追蹤哪些寄送服務被授權用哪些子網域。對多數小團隊來說，單一且設定良好的網域更簡單，也同樣安全。

驗證壞掉時該怎麼辦

最常見的失敗模式，是新增寄送服務卻沒有更新 DNS。如果你開始使用新的交易型電子郵件服務商，就需要加入他們的 SPF include 或 IP 範圍、設定使用你網域的 DKIM 簽署，並驗證 DMARC 對齊。

第二常見的問題是轉寄。如果使用者把你的電子郵件轉寄到另一個位址，SPF 會失敗，因為轉寄伺服器不在你的 SPF 記錄中。DKIM 通常能撐過轉寄，所以只要 DKIM 通過，而且你的 DMARC 政策允許部分對齊，訊息應該仍會被投遞。如果你看到轉寄郵件被拒收，請檢查你的 DMARC 政策——採用嚴格對齊的 p=reject 會破壞轉寄。

第三個問題是 DNS 傳播。DNS 記錄變更可能需要數小時才會傳播，而且不同郵件伺服器會以不同時間長度快取記錄。如果你剛更新記錄而它還沒生效，請等幾個小時後再測試。你可以用 whatsmydns.net 這類工具檢查傳播狀態。

重點整理

• MX 記錄路由入站郵件；SPF、DKIM 與 DMARC 驗證外寄郵件。它們解決不同問題，而你四者都需要。
• SPF 會在轉寄時失效，且有十次查詢限制。DKIM 可以撐過轉寄，但需要針對每個服務設定。DMARC 將它們串在一起並啟用報告。
• 在 DMARC 中先從 p=none 開始，監控報告數週，等你確定合法郵件都能通過後，再收緊為 p=quarantine 或 p=reject。
• DNS 錯誤是沉默的。用真實電子郵件測試你的設定，並檢查標頭以確認 SPF、DKIM 與 DMARC 都通過。
• 如果新增寄送服務後驗證壞掉，請檢查 SPF includes、DKIM selectors 與 DMARC 對齊。標頭會告訴你哪一項檢查失敗。

FAQ

Q: 我可以有多筆 SPF 記錄嗎？

A: 不行。多筆 SPF 記錄會導致它們全部被忽略。如果你需要授權多個服務，請在單一 SPF 記錄中使用 include: 指令，或直接列出 IP 範圍。注意十次查詢限制。

Q: 如果我一天只寄幾封電子郵件，也需要 DMARC 嗎？

A: 需要。DMARC 不是關於數量——它是關於證明你就是你所聲稱的身分。即使是小型網域也能從 DMARC 受益，因為它能防止偽冒，並讓你看見投遞問題。從 p=none 與一個報告位址開始。

Q: 如果 DKIM 和 SPF 都失敗，但電子郵件看起來合法，會發生什麼事？

A: 這取決於你的 DMARC 政策。如果是 p=none，郵件會帶著警告被投遞。如果是 p=quarantine，它會進入垃圾郵件。如果是 p=reject，它會被退回。這就是為什麼你應該在執行嚴格政策前先監控 DMARC 報告——你可能有自己不知道的合法寄件者。

Q: 我可以讓多個網域使用同一把 DKIM 金鑰嗎？

A: 技術上可以，但不要這麼做。每個網域都應該有自己的 DKIM 金鑰組。共用金鑰會讓輪替更困難，也會在私密金鑰外洩時擴大影響範圍。

Q: 我應該多久輪替一次 DKIM 金鑰？

A: 沒有通用規則，但對多數網域來說，一年一次是合理的。如果你懷疑金鑰已被外洩，請立即輪替。開始用新的私密金鑰簽署之前，務必先在 DNS 中發布新的公開金鑰，並在輪替後把舊金鑰留在 DNS 中幾天，以處理延遲送達的郵件。

<!-- tool-cta:start -->

💡 試試這個： 使用 DMARC Lookup 檢查任意網域已發布的政策，了解 MX、SPF 和 DMARC 記錄在實務上如何相互配合。

<!-- tool-cta:end -->

Sources

• RFC 7208: Sender Policy Framework (SPF) — SPF 規格，包含語法規則與十次查詢限制。
• RFC 6376: DomainKeys Identified Mail (DKIM) — DKIM 規格，涵蓋簽章產生與驗證。
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — DMARC 規格，包含政策語法與彙總報告格式。
• Google Workspace: Prevent spoofing and spam — Google Workspace 網域設定 SPF、DKIM 與 DMARC 的實務指南。