SPF/DKIM/DMARC 記錄檢測工具

只需輸入域名,即可即時查詢 SPF、DMARC、DKIM 記錄,診斷反仿冒郵件認證的配置狀況。

診斷防冒名的 DNS 設定

輸入一個網域,本工具便當場查詢其 SPF、DKIM 與 DMARC 記錄,報出防冒名郵件的設定做到了哪一步。您可藉此弄清自家網域是否易被第三方冒用,以及自己發出的信是否為對方所信任。

這三者各司其職,單靠其中任何一個都不夠。 SPF 宣告何等伺服器可代該網域發信,DKIM 則以簽章擔保信件不曾被改動。而 DMARC 的職責,是指示收信一方如何處置那些未通過前兩項檢查的郵件。 關竅正在於此:縱有 SPF 與 DKIM,若無 DMARC,一封檢查未過的冒名信究竟作何處置,便全憑收信方自行裁奪。 許多網域把 DMARC 留在 p=none,那意思是「報告儘管送來,卻什麼也不拒」——這是途中的一站,而非已然立起的防線。

使用方法

  1. 輸入待查的網域 只給網域即可,形如 example.com。
  2. 查看 SPF 的內容 請看所許可的發信方清單,以及末尾的限定符是 ~all 還是 -all。
  3. 閱讀 DMARC 的政策 停在 p=none 時,尚無任何拒絕之舉。
  4. 補上所缺的記錄 診斷的結果,便是您決定往 DNS 裡添些什麼的依據。

用好本工具的小技巧

  • 建議按照 SPF、DKIM、DMARC 的順序進行配置:先完善 SPF 和 DKIM,最後再用 DMARC 向接收方明確處理指示。
  • DMARC 不要一開始就設為 p=reject,應先用 p=none 收集報告,確認所有合法發信渠道後再逐步收緊策略,以避免誤傷。
  • SPF 中 include、a、mx、redirect= 等需要查詢 DNS 的項目,連同巢狀的 include 在內合計最多 10 次,超過後評估結果會變為錯誤(permerror)(RFC 7208 §4.6.4),建議定期清理不必要的 include。另外,每個 TXT 字串最多 255 個字元是另一項限制,較長的記錄只要拆分為多個字串即可登錄。
  • 本工具僅嘗試常見的 DKIM 選擇器,因此即使顯示"未找到",也可能只是實際使用的選擇器名稱不同。
  • Gmail、Outlook 等主要郵件服務商自 2024 年起已要求大量發信者配置 SPF、DKIM、DMARC,傳送郵件通訊的域名應優先確認此項設定。

這些情境會用到

查一查自家網域的防線

冒名之害,最先落在那些全無防備的網域頭上。

查究自己的信為何被當作垃圾

信件到不了時,頭一個該疑的便是 SPF 或 DKIM 有缺。

添了發信服務之後確認一遍

一旦用上新的投遞服務,便該查一查是否忘了把它添進 SPF。

查一查往來對象的網域

這為判斷所收之信是否真出其手,提供了依據。

郵件驗證的術語

SPF
羅列可代該網域發信之伺服器的 DNS 記錄。末尾的 -all 意為凡未列者一概拒收。
DKIM
發信時附上的數位簽章。收信方可憑公鑰確認:信件的正文與標頭在途中不曾被改寫。
DMARC
指示收信一方如何處置未通過 SPF 與 DKIM 檢查之郵件的記錄。
p=none
DMARC 的一種政策,意為要報告,但既不拒絕也不隔離。 那是剛開始採用時的設定。
p=quarantine 與 p=reject
分別指示收信方「當作垃圾另置一旁」與「逕直拒收」。做到這一步,才是此事的目標。
選擇器
言明 DKIM 公鑰安放在 DNS 何處的名稱,以 selector._domainkey.example.com 的形式被引用。

常見問題

並非絕對必須,但只有三者齊備,才能形成"證明發件方合法性(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 封以上)的必備要求,這三大支柱也因此從少數大企業的專屬知識,變成了傳送郵件通訊或系統通知郵件的所有機構都無法忽視的基礎常識。