DMARC 報告分析器
把收件方寄給你的聚合報告檔案拖進來——.xml、.xml.gz，或裝了多個報告的 .zip——就能看到 XML 埋藏的資訊：哪些來源以你的網域寄信、其中多少通過了 SPF 和 DKIM 對齊、哪些兩者都失敗了，以及先修什麼，全都用通俗語言寫明。一切解壓和解析都在你的瀏覽器中完成；檔案絕不會離開你的瀏覽器，因為一份 DMARC 報告就是一張地圖，畫著誰在替你寄信——以及誰在冒充你。
或者把檔案拖到這個框裡的任何位置。不同收件方、不同日期的報告會合併成一張表，按來源分組。
已讀取的報告
需要修復的問題
來源
| 來源 IP | 寄件人網域 | 郵件數 | 處置方式 | SPF 對齊 | DKIM 對齊 | DMARC |
|---|
當某一列有任意一種對齊通過時，該列即通過 DMARC——這正是收件方採用的定義。兩者都失敗的列會被醒目標示。要檢查記錄本身、而不是它們產生的報告，請使用電子郵件送達能力檢查。
聚合報告到底是什麼
DMARC 有兩半。第一半是你發布的記錄——策略、對齊模式、報告地址——也是包括本站電子郵件送達能力檢查在內的每個檢查工具都能讀到的那一半。第二半是回饋迴路：每個看到聲稱來自你的網域的郵件的大型收件方，都會把所見情況彙總，並通常每天一次、以 XML 形式把彙總寄到你的 rua 地址。那份檔案是還有誰以你的名義寄信的唯一證據。欺騙活動、同事兩年前接入的行銷平台、還在使用一台已停用伺服器的監控服務——這一切都會先出現在聚合報告裡，比出現在其他任何地方早幾週，前提是有人讀它們。幾乎沒人讀，因為帶有巢狀 policy_evaluated 元素的原始 XML 近乎無法閱讀，而檔案就那樣壓縮著堆在信箱裡。這個分析器填補的正是這個空白：同一份檔案，轉化成一張來源與判定表，並把每個失敗翻譯成它需要的修復方法。配套指南讀懂你的 DMARC 報告用一個完整的實例，講解了這種格式的術語——處置、對齊，以及驗證結果與對齊結果的區別。
兩個習慣能讓報告更有價值。第一，在強制執行之前先閱讀報告：帶報告的 p=none 策略是一套監控系統，它運行的那幾週正是你摸清每一個合法寄件方的時間，這樣之後轉向隔離和拒絕時就不會誤傷真實郵件。第二，把每一個未知來源都當作一張工單，而不是一件稀奇事——識別它、對齊它，或者看著強制執行切斷它，但絕不要讓一個無法識別的寄信流躺在「大概沒問題」那一堆裡，因為欺騙恰恰就藏在那一堆裡。注意聚合報告刻意不包含的內容：沒有郵件正文、沒有主旨行、沒有收件人地址。它們是按來源統計的計數和判定，因此可以分享給服務商的支援團隊——是以你主動交出檔案的形式，而不是上傳給某個工具。本頁保持了這一特性：分析就在檔案已經所在的地方進行，在你的機器上。
常見問題
什麼是 DMARC 聚合報告？
它是收件方（Google、Microsoft、Yahoo 等）每天傳送到你的 DMARC 記錄中 rua 標籤所指地址的回饋檔案。對於每一個聲稱來自你的網域寄信的來源，報告都會列出來源 IP、郵件數量、收件方採取的處置方式，以及 SPF 和 DKIM 是否與你的寄件人網域對齊。它是你的網域被冒用能以資料形式顯現的唯一地方，而不是等到一位困惑的客戶來投訴。配套指南讀懂你的 DMARC 報告逐行剖析了一份真實報告。
怎樣才能收到我自己網域的這些報告？
發布一條帶有報告地址的 DMARC 記錄——v=DMARC1; p=none; rua=mailto:[email protected]——收件方在一兩天內就會開始傳送。如果你還沒有記錄，或者想檢查現有的記錄，先運行電子郵件送達能力檢查：它會讀取記錄、策略，以及是否發布了報告地址。報告以小型 XML 檔案的形式到達，通常經過 gzip 壓縮或打包在 zip 裡，而這正是本分析器能開啟的格式。
在這裡開啟報告安全嗎？檔案會去哪裡？
哪裡也不去。檔案在本頁中、你的瀏覽器裡解壓和解析；不會上傳、傳輸或儲存。這是有意為之的設計，因為聚合報告是你郵件基礎設施的一張地圖——你使用的每一個寄信服務、每一個 IP，以及針對你的任何冒用行為。把這張地圖上傳到陌生人的伺服器，或者貼到一個會保留記錄的 AI 聊天中，就是把地圖交到它本不該去的人手裡。
一個我不認識的來源 SPF 和 DKIM 都失敗了。這是冒用嗎？
要麼是冒用，要麼是一個沒人告訴過你的寄件方——而僅憑報告無法區分這兩者，這也是為什麼分析器把它表述成一個需要追查的問題，而不是一個結論。按順序排查：這個 IP 是否屬於你的組織付費的服務商（CRM、客服系統、舊的行銷工具、被遺忘的監控服務）？流量是穩定而少量（設定錯誤的內部系統）還是突發而大量（一次群發活動）？只要你的策略是 p=none，這類郵件無論如何都會被投遞；一旦每個合法來源都完成對齊、你開始強制隔離或拒絕，這個無法識別的寄信流無論屬於哪一種都會被拒收。
我自己的合法郵件失敗了。先修什麼？
修對齊，而且幾乎總是在服務商那邊。SPF 無法對齊，是因為服務商用自己的退信網域寄信——用一個自訂的回信路徑子網域來修復，讓信封網域變成你的。DKIM 無法對齊，是因為服務商用自己的網域簽章或者根本不簽章——在服務商的設定裡開啟用你的網域進行 DKIM 簽章即可修復。只要有一種機制對齊就足以通過 DMARC，但 DKIM 是兩者中更穩固的，因為它能在轉寄後存活。按流量順序逐個修復寄件方，看著後續報告變乾淨，然後再提升策略。