SPF/DKIM/DMARC 記錄檢測工具
只需輸入域名，即可即時查詢 SPF、DMARC、DKIM 記錄，診斷反仿冒郵件認證的配置狀況。
使用提示
- 建議按照 SPF、DKIM、DMARC 的順序進行配置：先完善 SPF 和 DKIM，最後再用 DMARC 向接收方明確處理指示。
- DMARC 不要一開始就設為 p=reject，應先用 p=none 收集報告，確認所有合法發信渠道後再逐步收緊策略，以避免誤傷。
- include 數量過多的域名可能觸及"10 次 DNS 查詢 / 255 字元"的限制而導致查詢失敗，建議定期清理不必要的 include。
- 本工具僅嘗試常見的 DKIM 選擇器，因此即使顯示"未找到"，也可能只是實際使用的選擇器名稱不同。
- Gmail、Outlook 等主要郵件服務商自 2024 年起已要求大量發信者配置 SPF、DKIM、DMARC，傳送郵件通訊的域名應優先確認此項設定。
常見問題
並非絕對必須，但只有三者齊備，才能形成"證明發件方合法性（SPF/DKIM）+ 指示接收方如何處理失敗情況（DMARC）"的完整防護鏈條。僅配置其中一項效果有限，建議按順序逐步完善。
不一定。DKIM 選擇器名稱可由各發件服務自由設定，若域名未使用本工具嘗試的常見名稱（default、google 等），就會顯示"未找到"。如需準確確認，請檢視發件郵件服務的管理後臺或郵件頭中的 DKIM-Signature 一行。
不建議這樣做。如果尚未完全掌握所有合法發信渠道（如郵件通訊服務或業務系統），直接設為 reject 可能導致正常郵件也被拒收。更安全的做法是先用 p=none 收集數週報告，確認無誤後再逐步升級為 quarantine、reject。
最終推薦使用 -all（Fail，明確拒絕），但在對 SPF 配置尚不完全確信的過渡期，可先使用 ~all（SoftFail，視為可疑），確認正常郵件不會被誤攔後再切換為 -all。
不會。對所輸入域名的 DNS 查詢僅為即時查詢，獲取到的記錄資訊不會儲存在伺服器端。
閒話 ― 反仿冒郵件三大支柱的誕生歷程
SPF、DKIM、DMARC 分別在不同時期因不同背景而誕生。最早出現的 SPF（約 2003 年）用於宣告"哪些 IP 地址可以使用該域名傳送郵件"，作為對抗垃圾郵件傳送者偽造發件地址的手段而普及開來。但 SPF 在郵件轉發方面存在弱點：轉發後發件 IP 會發生變化，導致認證失敗。
彌補這一弱點的是約 2007 年標準化的 DKIM。它不像 SPF 那樣依據 IP 地址判斷，而是對郵件正文和部分郵件頭附加數字簽名，接收方使用 DNS 中公開的公鑰驗證簽名，因此只要簽名本身未被破壞，即使經過轉發也能通過認證。
不過 SPF 和 DKIM 只能檢測出"認證失敗"，至於失敗郵件該如何處理（投遞、標記為垃圾郵件或拒收）完全取決於接收伺服器自身判斷。為統一這種"對接收方的指示"，2012 年制定了 DMARC。DMARC 還具備將認證結果以報告形式（rua=）回傳給發件域名管理者的機制，使管理者能夠持續監控自己的域名是否被濫用。
2024 年 Google 和 Yahoo 將 SPF、DKIM、DMARC 事實上列為大量發信者（每日 5000 封以上）的必備要求，這三大支柱也因此從少數大企業的專屬知識，變成了傳送郵件通訊或系統通知郵件的所有機構都無法忽視的基礎常識。