SPF、DKIM 與 DMARC 檢查器

設定

查看一個網域如何保護其郵件：包含所有 include 和 DNS 查詢次數的 SPF 記錄、DKIM 金鑰及其長度、DMARC 政策、MX 伺服器，以及 MTA-STS、TLS-RPT 與 BIMI 記錄。每項發現都附有說明，讓你知道該修正什麼。

此工具在伺服器上執行

運作方式

郵件協定並不驗證寄件人：任何伺服器都可以把你的網域寫成寄件人。三筆 DNS 記錄能堵住這個漏洞。SPF 列出哪些伺服器可以代表該網域寄信。DKIM 用私鑰為每封郵件簽章，其公鑰發布在 DNS 中。DMARC 把兩者結合起來：要求至少一項通過並與可見的寄件人網域一致，告訴收件方如何處理未通過的郵件，並要求提交所有以你名義寄出的郵件的報告。

自 2024 年 2 月起，Gmail 和 Yahoo 要求每天向其使用者寄送超過 5000 封郵件的寄件人必須設定 SPF、DKIM 和 DMARC，缺少任何一項都會導致郵件被拒或進入垃圾郵件。因此最好三者一起檢查：沒有 DMARC，再完美的 SPF 也作用有限；而 DKIM 發布有誤時把 DMARC 設為 reject，會把你自己的郵件也擋在門外。

檢查從我們的伺服器透過公共 DNS 查詢完成，與任何郵件伺服器的做法相同。SPF 會被完整評估，逐一跟隨每個 include 和 redirect 來統計 DNS 查詢次數，因為超過 10 次的上限會使整筆記錄失效。此外還會查詢 MX 記錄以及選用的 MTA-STS、TLS-RPT 與 BIMI 記錄。

範例

github.comSPF · 10 / 10八個服務商的 include（Microsoft、Google、Zendesk、Salesforce、Mailchimp、SendGrid…）及其再次 include 的記錄，使評估正好達到 10 次 DNS 查詢的上限。再加一個服務商，整個 SPF 就會回傳永久錯誤。

example.comMX 0 . · v=spf1 -all · v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s適用於既不寄信也不收信的網域的正確設定：空 MX、不授權任何人的 SPF，以及設為 reject 的 DMARC。它能保護常被冒用的停放網域。

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.comquarantine · 25 %逐步部署：未通過的郵件中只有四分之一會進入垃圾郵件，報告會寄到 rua 指定的信箱，便於發現尚未完成驗證的合法寄件方。

使用情境

診斷該網域的郵件為何進入垃圾郵件或被 Gmail、Outlook、Yahoo 拒收。
在加入新的寄信服務商（如 CRM 或電子報平台）之前，確認 SPF 不會超過 10 次 DNS 查詢。
設定完成後，確認服務商的 DKIM 金鑰已正確發布。
規劃在不阻斷合法郵件的前提下，把 DMARC 從 none 逐步切換到 quarantine 和 reject。
稽核客戶或被收購公司的網域，包括不應寄信的停放網域。
分析網路釣魚時，檢查可疑寄件人的設定。

常見問題

我的網域明明對郵件簽章了，為什麼顯示找不到 DKIM？

因為 DKIM 無法列出一個網域的所有金鑰：每個金鑰位於 <selector>._domainkey.<domain>，必須知道選擇器才能查詢。本工具會嘗試最常用的選擇器，但許多服務商使用自訂名稱或帶日期的名稱。開啟一封從該網域寄出的郵件，找到 DKIM-Signature 標頭並複製 s= 的值；用這個選擇器檢查就會準確無誤。

如果 SPF 超過 10 次 DNS 查詢會怎樣？

RFC 7208 要求收件方回傳永久錯誤（permerror），對 DMARC 而言這等同於 SPF 失敗。消耗查詢次數的是 include、a、mx、ptr、exists 機制和 redirect 修飾符，包括每個 include 內部的這些項目；ip4 和 ip6 不消耗。要減少次數，可以刪除不再使用的服務商、用 ip4 網段取代 include，或改從擁有獨立 SPF 的子網域寄信。

用 ~all 還是 -all？

啟用 DMARC 後差別不大：收件方執行的是 DMARC 政策，而不是 SPF 限定詞。~all 較常見，因為有些收件方看到 -all 會在評估 DKIM 之前直接拒收，可能導致本可由 DKIM 挽救的轉寄郵件遺失。沒有 DMARC 時，-all 是要求拒收未授權郵件的唯一方式。

如何在不遺失郵件的情況下把 DMARC 從 none 改為 reject？

先設定 p=none 並在 rua 中填寫位址，閱讀幾週的彙總報告：報告會列出所有用你的網域寄信的伺服器，以及它們是否通過 SPF 或 DKIM。為缺少的合法寄件方完成驗證，再以較低的 pct 切換到 quarantine，逐步提高 pct，最後改為 reject。直接跳到 reject 往往會把計費系統、CRM 或沒人記得的內部系統擋在外面。

1024 位元的 DKIM 金鑰夠用嗎？

可以用，因為 RFC 8301 要求收件方接受 1024 到 4096 位元的金鑰，但同一標準建議簽章方至少使用 2048 位元。低於 1024 位元的金鑰被視為無效。換成 2048 位元很簡單：用另一個選擇器發布新金鑰，切換簽章，然後把舊金鑰的 p 留空以撤銷它。

MTA-STS、TLS-RPT 與 BIMI 有什麼用？

MTA-STS（RFC 8461）要求寄信伺服器在投遞到你的 MX 時必須使用 TLS，從而防止把連線降級為明文的攻擊。TLS-RPT（RFC 8460）會在這些投遞失敗時寄報告給你。BIMI 會在支援它的用戶端中於寄件人旁顯示品牌標誌，且僅在 DMARC 為 quarantine 或 reject 時有效。三者都不是必要的，但都有好處。