SPF、DKIM、DMARC 是什麼？一次搞懂郵件驗證三兄弟
很多人來找我的原因都一樣：「信件一直進垃圾信件夾，我不知道為什麼。」
我問的第一個問題永遠是：「你的 SPF、DKIM、DMARC 有設嗎？」
八成的人回答：「什麼？」
所以這篇就是專門為你寫的。除了 DNS 設定，影響信件抵達率的原因其實還有很多——但 SPF/DKIM/DMARC 是最基礎、最先要確認的三件事。
先說為什麼這三個東西這麼重要
收件匣的守門員（Gmail、Outlook、Yahoo Mail 這些信箱服務）每天要處理幾十億封信，其中大量是詐騙信、釣魚信、垃圾信。它們必須快速判斷：這封信是真的嗎？這個寄件人是它自稱的那個人嗎？
SPF、DKIM、DMARC 就是幫你證明身份用的。
沒有這三個設定，你寄出去的信對收件方來說就是一個陌生人敲門，不知道你是誰，也不知道你是不是壞人。被擋在門外很正常。
這三個設定都是放在 DNS 裡的記錄。你不需要改動你的寄信伺服器或 ESP 的任何程式邏輯——你只需要在你的域名管理後台加幾筆 TXT 記錄。但加錯了也會出問題，所以這篇我會講清楚每個設定的邏輯和常見錯誤。
SPF：你告訴世界「哪些伺服器可以代表我寄信」
SPF 是 Sender Policy Framework 的縮寫。
白話翻譯：你在自己的網域 DNS 裡放一筆記錄，告訴全世界「只有這些 IP 位址有資格用我的名字寄信」。
舉個例子：你用 Mailchimp 寄電子報，Mailchimp 的伺服器代替你發信。如果你沒設 SPF，收件方看到「這封信聲稱來自 yourcompany.com，但寄件的 IP 不在授權清單上」，就會起疑。
SPF 的樣子長這樣：
v=spf1 include:mailchimp.com ~all
意思是：「我授權 Mailchimp 的伺服器替我寄信，其他來源的信請放寬處理（~all）。」
幾個常踩的地雷：
DNS 查詢次數超過 10 次
SPF 有個很多人不知道的限制：include: 這種需要查詢 DNS 的機制最多只能用 10 次。很多公司同時在用 Mailchimp、HubSpot、Salesforce、Zendesk……每個工具都要加一個 include:，很容易超過 10 次。
超過限制之後，你的 SPF 記錄會回傳 permerror（永久性錯誤），等於整個 SPF 完全失效——就像根本沒有設一樣。
如果你用的工具很多，可以考慮使用 SPF Flattening 服務，把多個 include: 轉成直接列出 IP 的方式，減少查詢次數。
-all vs ~all
-all 是硬拒絕（不在清單的一律擋）。
~all 是軟拒絕（標記但不一定擋）。
大多數情況用 ~all 就好。用 -all 要絕對確定你的授權清單是完整的，否則一個漏掉的合法 ESP，你的信就被你自己的 SPF 擋掉了。
SPF 驗證的是信封上的寄件人，不是你看到的 From
這點很多人不知道，是後面理解 DMARC Alignment 的關鍵。SPF 驗證的是 MAIL FROM（SMTP 層的發件人，又叫 Envelope Sender 或 Return-Path），不是你在信件裡看到的 From 欄位。這兩個可以不一樣，而 DMARC 會要求它們對齊。
DKIM：你在每封信上蓋一個防偽印章
DKIM 是 DomainKeys Identified Mail 的縮寫。
白話翻譯：郵件伺服器在寄出去的每封信上加一個數位簽章，收件方可以拿你公開在 DNS 的公鑰來驗證「這封信確實是從你的系統發出去的，而且中途沒有被人改過」。
SPF 驗證的是誰寄的，DKIM 驗證的是信有沒有被動過手腳。兩個從不同角度保護你的信件。
DKIM 的設定邏輯：
- 你的 ESP（或自己的郵件伺服器）生成一對金鑰：私鑰留在伺服器，公鑰放到 DNS
- 每封信寄出時，伺服器用私鑰對信件內容（信頭和信體的特定部分）產生簽章
- 收件方拿 DNS 上的公鑰解密簽章，驗證是否一致
如果簽章一致，代表：這封信是從持有私鑰的伺服器發出的，而且內容從那時候到現在沒有被修改過。
DNS 裡的 DKIM 記錄長這樣：
selector1._domainkey.yourcompany.com TXT "v=DKIM1; k=rsa; p=MIGfMA0..."
selector1 是選擇器（Selector），你可以有多個 DKIM 金鑰對應不同的 ESP，靠這個區分。比如 Mailchimp 用 k1._domainkey，HubSpot 用 hs1._domainkey，各自不干擾。
常見問題：
我不知道我的 DKIM Selector 是什麼
收一封你自己寄出的信，查看原始碼（Gmail 右上角三個點 → 「顯示原始郵件」），找 DKIM-Signature 那一行，s= 後面的值就是 Selector。
金鑰長度用 RSA 2048 位
RSA 1024 早就被認為不夠安全了，現在的標準是 2048 位。如果你的 ESP 或伺服器還在用 1024 位，要更新。
DKIM 金鑰要定期輪換
很多人設好之後就放著不管。安全最佳實踐是每 6-12 個月輪換一次 DKIM 金鑰，降低私鑰外洩的風險。輪換的時候要先把新的公鑰加到 DNS，確認傳播完成後再把伺服器切換到新的私鑰，這樣中間不會有空窗期。
DMARC：你告訴收件方「驗不過的信要怎麼處理」
DMARC 是 Domain-based Message Authentication, Reporting & Conformance 的縮寫，名字很長，但概念不難。
DMARC 做兩件事：
- 定義政策：SPF 或 DKIM 驗不過的信，你要求收件方怎麼處理？不管（none）、放進垃圾信件夾（quarantine）、直接拒絕（reject）？
- 回傳報告：讓你知道有哪些 IP 在用你的名字寄信，以及驗證通過的比例。
DMARC 的樣子：
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com; pct=100
p=quarantine：驗不過就丟進垃圾信件夾rua=：把彙整報告寄到這個信箱（Aggregate Report，每天一次）pct=100：對 100% 的信件套用這個政策
你也可以設 ruf= 接收 Forensic Report（個別失敗信件的報告），但這個有隱私爭議，很多 ISP 不再傳送了。
DMARC 有個很多人搞混的地方：Alignment（對齊）
DMARC 不只看 SPF 和 DKIM 有沒有通過，還要看驗證的網域跟 From 信頭的網域是不是同一個。
這叫做 Alignment（對齊）。
簡單說：你的 From 是 @yourcompany.com，SPF 或 DKIM 驗的也要是 yourcompany.com，不是其他網域。
很多人 SPF 通過了，但因為 ESP 用自己的網域做 Envelope Sender（Return-Path 是 bounce.mailchimp.com），而不是你的網域，DMARC 的 SPF Alignment 就過不了。
解法是：讓你的 ESP 用你自己的子域名做 Return-Path（有些 ESP 叫做「Custom Bounce Domain」或「Custom Return-Path」），或者確保 DKIM 簽章使用你自己的網域，用 DKIM Alignment 來通過 DMARC。
如何讀 DMARC 報告
DMARC 報告是 XML 格式，直接看很痛苦。建議用免費的工具把報告視覺化：
- Google Postmaster Tools：Gmail 的角度，免費
- dmarcian：免費版有基礎功能，可以看報告摘要
- MXToolbox DMARC Report：另一個免費選項
報告裡最重要的資訊：有哪些 IP 在用你的網域寄信，以及每個 IP 的驗證通過率。這可以幫你：
- 找到你不知道的合法寄件來源（例如某個第三方服務在代表你發信，但你忘了設定）
- 發現有人在偽造你的網域（Phishing 攻擊）
DMARC 要怎麼部署？循序漸進，不要一開始就 reject
- 先設
p=none，只收報告，觀察有哪些來源在寄信 - 分析報告 2-4 週，確認所有合法來源（ESP、工具）都通過驗證
- 把所有合法來源都設好 SPF 或 DKIM 之後，改成
p=quarantine，先從pct=25開始，觀察一週 - 慢慢把
pct拉到 100，確認沒有正常信件被誤擋 - 穩定之後，再升到
p=reject
很多人急著設 p=reject 結果把自己的正常信也擋掉了。不要急，部署 DMARC 是需要過程的。
（想進一步看懂 rua 收到的那包報告怎麼讀，我另外寫了一篇DMARC 聚合報告逐欄拆解。）
DMARC 正在改版：DMARCbis 是什麼，對你有什麼影響
現在大家在用的 DMARC 是 2015 年的 RFC 7489。IETF 的工作小組這幾年在修訂新版，業界習慣叫它 DMARCbis（bis 就是「第二版」的意思）。它不是要你打掉重練，多數現有設定照樣有效，但有幾個改變值得先知道，尤其你如果正要重新規劃 DMARC 策略。
1. 不再靠「公共後綴清單」判斷主網域，改用 DNS Tree Walk
舊版 DMARC 要判斷 mail.shop.yourcompany.com 的「組織網域」是不是 yourcompany.com，靠的是一份公開維護的清單（Public Suffix List）。這份清單更新慢、又不是為 email 設計的。DMARCbis 改成直接沿著 DNS 一層一層往上查（Tree Walk），找到 DMARC 記錄為止。實務上你幾乎無感，但 Alignment 的判定會更準、更即時。
2. 新增 np 標籤：管「根本不存在的子網域」
舊版有 p（主網域政策）和 sp（子網域政策）。DMARCbis 多了一個 np，專門規範「不存在的子網域」該怎麼處理。這是防冒名的重要補強——攻擊者很愛用你從沒開過的子網域（例如 invoice.yourcompany.com）寄釣魚信，設 np=reject 可以直接把這條路堵死。
3. pct 標籤被拿掉，改用 t=y 測試模式
舊版可以用 pct=25 只對 25% 的信套用政策，做漸進式部署。這個機制實作上常出問題，DMARCbis 直接移除 pct，改用 t=y（testing）：意思是「我政策雖然設了 reject，但還在測試，收件方請先別真的照做，把結果回報給我就好」。部署的意圖更清楚，不會因為百分比抽樣造成混亂。
4. 失敗報告（ruf）拆到另一份文件
那種逐封失敗信件的鑑識報告（Forensic / Failure Report）因為隱私爭議，本來就越來越少 ISP 願意送。DMARCbis 把它獨立到另一份規格，聚合報告（rua）仍然是主力，也是你最該顧好的那一個。
那你現在該做什麼？
老實說，多數人「幾乎什麼都不用改」——把 SPF、DKIM、DMARC 三個先設對、rua 收好報告、政策從 p=none 循序收緊，這些原則在 DMARCbis 一樣成立。真正建議提早動手的只有一件事：把 np=reject 加上去，順手把不存在子網域這個冒名破口補起來。其他等新版正式落地，你的 ESP 和 DNS 供應商多半會自動跟上。
三個設定的關係，一張圖說清楚
你寄一封信
│
├── SPF 檢查：這個 IP 被授權了嗎？（驗 Envelope Sender）
│
├── DKIM 檢查：這個簽章是真的嗎？（驗信件完整性）
│
└── DMARC 檢查：
├── SPF 通過，且 SPF 網域 = From 網域？（SPF Alignment）
├── DKIM 通過，且 DKIM 網域 = From 網域？（DKIM Alignment）
├── 至少一個 Alignment 通過 → DMARC Pass
└── 都失敗 → 按 p= 政策處理（none / quarantine / reject）
常見的診斷工具
自己設定完，怎麼確認有沒有設對？
- MXToolbox：查 SPF、DKIM、DMARC 記錄是否正確、IP 是否在黑名單
- Mail Tester（mail-tester.com）：寄一封測試信，會評分並列出問題
- Google Postmaster Tools：查 Domain Reputation、IP Reputation、DMARC 通過率
- DMARC Analyzer：把 DMARC 報告轉成人看得懂的格式
這些工具大部分都有免費版，設定完後跑一遍是個好習慣。
最後，幫你整理一個行動清單
- 確認你寄信用的每個 ESP 都加進 SPF
- 檢查 SPF DNS 查詢次數沒有超過 10 次（用 MXToolbox 的 SPF Check 可以驗）
- 在每個 ESP 設定 DKIM，並把公鑰加到 DNS
- 確認 DKIM 金鑰長度是 RSA 2048 位
- 設定 DMARC，先從
p=none開始 - 設
rua=開始收報告，看看有誰在用你的網域 - 分析 DMARC 報告 2-4 週，確認所有合法來源都通過 Alignment
- 觀察穩定後，視情況升級到
quarantine，再到reject - 迎接 DMARCbis：把
np=reject加上去，堵住不存在子網域的冒名破口
