用AI分析DMARC報告：Claude修復SPF與DKIM

一句話結論：當服務檯平台、開票工具或電子通訊服務以你的域名發信，卻沒有完成認證和對齊時，收件服務器可能把郵件放進垃圾箱甚至直接拒收，而你公司內部誰也看不到任何報錯。DMARC 聚合報告就是"誰在以你的域名發信、結果通過與否"的完整記錄。用 AI 做 DMARC 報告分析時，把這份 XML 連同當前的 SPF 和 DMARC 記錄一起貼給 Claude，它可以把每個發信來源歸入"我們的且通過""我們的但失敗""不認識的"三類，並起草 DNS 修改清單。Claude 只能看到你貼給它的內容，它也可能出錯，它給出的每一條記錄在發佈之前都應該用 DNS 查詢核對一遍。

設想一家 80 人的香港專業服務公司，由辦公室經理兼管 IT。公司使用 Microsoft 365 和 Exchange Online，域名（這裡稱為 example.com）多年來一直穩定。過去一個季度新增了三樣東西：一個以 support@example.com 回覆客戶的 Zendesk 服務檯，一批以財務團隊名義發出的 Xero 發票，以及由市場協調員負責的 Mailchimp 電子通訊。

然後投訴來了。一位客戶說她從沒收到工單的回覆。另一位說發票提醒"又進了垃圾郵件文件夾"。服務檯顯示每封郵件都已發送，Xero 顯示發票已送達，Mailchimp 顯示發送正常。沒有退信，所以從內部看不出任何問題。

Microsoft 365 遷移之後，上一位顧問為 example.com 發佈了一條採用隔離策略的 DMARC 記錄，並設定了 rua 地址，此後每天的 XML 報告一直堆在一個共享郵箱裡。沒人打開過，因為用文字編輯器根本讀不懂。

為什麼合法郵件會認證失敗（以及為什麼總是在新增發信工具之後）

收件服務器不會信任郵件上顯示的 From: 地址，因為任何人都可以隨便寫。它們檢查的是：發信服務器是否被允許代表該域名發信，以及郵件是否帶有能證明內容未被改動的簽名。新增的、以你域名發信的工具，只有在有人專門配置之後才能通過這些檢查，而供應商的預設配置往往是以供應商自己的域名，而不是你的域名來認證郵件。

這個預設配置就是常見的故障點。郵件是真的，發信人也是你的，但在收件方看來，它和陌生人冒用 example.com 發信沒有區別。如果你的 DMARC 策略要求收件方對失敗的郵件隔離或拒收，它們就會照做。發信方的後台顯示"已發送"，收件人卻永遠看不到。

用大白話講清 SPF、DKIM 和 DMARC 對齊

SPF 說明哪些服務器可以發信。它是一條 DNS 記錄，列出被允許代表某個域名發信的服務器，檢查對象是信封發件人（也叫 return-path 或退信地址），而不是人們看到的 From: 地址。它證明發信服務器被允許，但不能證明內容沒被改動，郵件被轉發時它還常常失效。

DKIM 說明郵件帶有簽名。發信系統會加上一個與 d= 標籤中所指域名綁定的加密簽名，收件方用該域名 DNS 裡的公鑰來驗證。它證明郵件在傳輸中沒有被改動，但簽名域名可以是發信方控制的任何域名，包括供應商自己的域名。

DMARC 要求 From: 域名必須對得上。只要 SPF 或 DKIM 通過，並且通過的那個域名與 From: 域名對齊，郵件就通過 DMARC。用 d=vendor.com 簽名的服務檯能通過 DKIM，但這個域名不是你的，所以不對齊，DMARC 也就不通過。DMARC 還會公佈你的策略以及接收報告的地址。

關於這三類記錄在香港環境下的通用入門，請看我們的香港企業 SPF、DKIM 和 DMARC 指南。

把 DMARC 聚合報告變成通俗易懂的診斷

聚合報告是收件方每天對"聲稱來自你域名的郵件"所做的統計。它是機器可讀的 XML，最初由 RFC 7489 定義，2026 年 DMARC 修訂後改由 RFC 9990 定義，所以一直沒人去讀。

XML 裡到底有什麼

每份報告都會寫明發送報告的機構（例如大型郵箱服務商）、覆蓋的日期範圍，以及它看到的已發佈的 DMARC 策略。接下來是按發信 IP 地址列出的一行行數據：郵件數量、收件方如何處理、DKIM 和 SPF 是否通過，以及這些檢查認證的是哪些域名。

裡面沒有郵件正文，也沒有主題行。你能拿到的是發信 IP 地址和你的域名，這屬於運營數據而不是通信內容，不過你仍應核對自己的隱私政策如何對待 IP 地址。取證報告（單獨的 ruf 類型）可能包含單封郵件的部分內容，那是另一回事。

把來源分為"我們的且通過""我們的但失敗""不認識的"三類的提示詞

在這個流程裡，Claude 不會查詢你實際生效的 DNS，也不會讀取你的郵箱，所以一切都要由你提供。貼上報告 XML 或表格導出，再加上當前的 SPF 和 DMARC TXT 值，然後問："這是 example.com 的 DMARC 聚合報告以及當前的 SPF 和 DMARC 記錄。請把每個發信 IP 分成三組：我們的且通過 DMARC、我們的但未通過 DMARC、不認識的。對每個失敗的來源，請說明是 SPF 還是 DKIM 失敗、通過的域名是否與 example.com 對齊，以及最可能的修復辦法。凡是這份數據看不出來的，請標為未知，不要猜測。"

實際案例——以你的域名發信、卻沒有 DKIM 密鑰的服務檯平台

1. 收集一週的報告和兩條記錄。從 rua 郵箱取出報告，並用 nslookup -type=txt 或 Resolve-DnsName 之類的工具查出 example.com 和 _dmarc.example.com 當前的 TXT 記錄，然後貼上這些值。切勿貼出註冊商或 DNS 的登入資訊。

2. 執行分組提示詞。模擬的結果如下（IP 地址用供示範文件使用的保留地址段代替真實地址）：192.0.2.10 發送了 1,140 封郵件，SPF 和 DKIM 均對齊並通過，這是 Exchange Online，狀態健康。198.51.100.61 發送了 205 封郵件，DKIM 對齊並通過，這是 Mailchimp 電子通訊，市場部最初發送時就配置正確了。

3. 讀懂失敗的那一行。198.51.100.24 發送了 312 封郵件，未通過 DMARC。SPF 通過了，但通過的是供應商的退信域名。DKIM 也通過了，但簽名是 d=helpdesk-vendor.example.net。兩者通過的都不是 example.com，所以都不對齊，隔離策略隨之生效。這就是服務檯，也解釋了為什麼回覆丟了。

4. 查看不認識的來源。203.0.113.77 發送了 38 封郵件，兩項檢查都失敗。Claude 把它標為不認識。不要為了讓它通過而把它加進 SPF。先問清楚誰可能以這個域名發信：被遺忘的 CRM、影印機的掃描發郵件功能，還是有人在冒用你的域名。弄清之後再決定。

5. 注意報告沒有解釋的部分。Xero 的發票提醒沒有作為失敗來源出現，所以"進了垃圾郵件"的投訴可能另有原因，例如郵件內容、收件人自己的過濾規則，或者某個不發送報告的收件方。

6. 修復服務檯。打開供應商關於認證自訂發信域名的文件。它會給你 DKIM 記錄（通常是 CNAME），往往還有自訂的 return-path 或退信域名，讓 SPF 也能對齊。發佈這些記錄，每一條都用查詢確認，然後在供應商後台打開驗證。Exchange Online 是另一回事：它的自訂域名 DKIM 是在 Microsoft Defender 入口網站中通過發佈兩條 CNAME 記錄（selector1 和 selector2）來啟用的，具體路徑請查閱 Microsoft 的最新文件。

7. 用下一批報告重新執行提示詞。報告通常每天到達，所以改動往往一兩天內就會體現，但各收件方不同，沒有任何保證。服務檯這個來源應該移到"我們的且通過"。如果沒有，就把新的那一行貼回去，問問還有什麼沒對齊。

修復時不要把別的東西弄壞

SPF 的 10 次 DNS 查詢上限，以及多加一個供應商如何悄悄弄壞記錄

RFC 7208 規定一次 SPF 檢查最多只能有 10 次 DNS 查詢。會觸發查詢的機制，即 include、a、mx、ptr、exists 和 redirect，都會計入，包括每個被引用供應商自己記錄裡的查詢。ip4、ip6 和 all 則不計入。一旦超過 10 次，收件方會返回永久錯誤，很多收件方會把它當作 SPF 失敗。

Microsoft 365 的 include 只佔一次查詢，但每個供應商的 include 至少再佔一次，有些供應商還在自己的記錄裡嵌套更多 include，所以服務檯和電子通訊服務加起來可能增加好幾次。昨天還正常的記錄，今天可能就失敗了，而表面上什麼都沒變。你可以讓 Claude 估算查詢次數，但要用專門的 SPF 檢查工具核實，因為 include 是層層嵌套的，語言模型可能數錯。

分階段把 DMARC 從 p=none 提升到隔離再到拒收

策略有三個檔位。p=none 只監控，不採取任何動作。p=quarantine 要求收件方把失敗的郵件視為可疑，通常放進垃圾箱。舊的指南會用 pct 標籤逐步推進，但 2026 年的 DMARC 修訂（RFC 9989）已刪除 pct，改為新增 t=y 測試標誌，所以在依賴其中任何一個之前，先確認收件方和你的工具是否支援。p=reject 要求收件方直接拒收失敗的郵件。往上提升是目標，因為只有強制執行才能擋住偽造郵件，但每一步都應該在報告乾淨之後再走。

每一步都要觀察：你自己的來源是否還有失敗的，"不認識的"清單是否在縮短。只要還有合法系統沒有對齊，就不要提升到拒收，因為發票就是這樣永久消失的。在本例中，公司已經處於隔離檔位，所以首要任務是修好失敗的來源，而不是收緊任何東西。

Claude 輔助診斷 vs 專用 DMARC 監控服務 vs 憑感覺改 DNS

Claude 輔助診斷。適合一次性的排查或少量報告：幾分鐘內把 XML 變成通俗的分組和修改清單，不需要新增訂閱。它不會收集報告，看不到你實際生效的 DNS，除非你再次貼上報告，否則不會保留你域名的歷史記錄，還可能數錯 SPF 查詢次數。正確用法：作為首次診斷，並向負責 DNS 的人做講解。
專用 DMARC 監控服務。為長期運維設計：替你接收報告，把眾多收件方合併成一個看板，持續追蹤各來源，並在有新來源開始發信時提醒你。它是持續的開支，仍然需要有人判斷每個來源是什麼。正確用法：強制執行之後，在發信方清單不斷變化時作為常設視圖。
憑感覺改 DNS。快、免費，也是這個領域大多數故障的起因：因為某篇博客這樣說就加一條 include，照抄別家公司的記錄，或者直接跳到拒收。正確用法：沒有。

把事情做對——不要貼上註冊商或 DNS 憑證，以及明年誰來負責這些記錄

永遠不要把憑證給 Claude。它只需要報告 XML 和兩條 TXT 字串，不需要別的。註冊商或 DNS 託管商的登入資訊、API 令牌或管理員密碼，都不應該出現在對話裡。DNS 的改動要自己動手，並讓第二個人一起核對。

發佈之前先核實。Claude 對供應商的記錄名稱、selector 格式或查詢次數，可能很有把握地給出錯誤答案。把它提出的每一條記錄對照供應商的最新文件檢查，改完之後再用查詢確認實際生效的內容。把舊記錄記在筆記裡，這樣幾分鐘內就能回退。

確定明年由誰來負責這些記錄。認證永遠沒有"完成"的一天，因為每個以你域名發信的新 SaaS 工具都會增加一個來源，記錄也會隨之漂移。要明確：誰來審閱報告，哪個團隊在註冊新的發信工具之前必須先通知誰，辦公室經理離職後誰掌握 DNS 權限。能修改 DNS 和郵件設定的管理員帳號，也應當啟用 MFA，因為帳號一旦被攻破，攻擊者就能自己發佈記錄。

決定 Claude 應當如何融入你的郵件診斷，並圍繞它寫好提示詞和複核步驟，屬於 AI+ Support 的工作。我們管理型IT外判服務的每個方案都包含 DMARC 監控；我們的管理型郵件安全服務提供針對冒用發件人和身份仿冒的防護，與強制執行的 DMARC 策略相輔相成；具體的 DNS 改動和郵件流修復由我們的 IT 支援團隊負責。同一問題的另一個方向，即收到可疑郵件，請看用 Claude 標記釣魚郵件；同一個租戶內的更多 Claude 應用，請看 Claude 與 Microsoft 365 郵件自動化。

常見問題

Google 和 Microsoft 現在要求批量發信方必須有 DMARC 嗎？

對大型發信方來說是的。Google 和 Yahoo 的批量發信方要求從 2024 年 2 月開始實施；Google 的門檻是每天向個人 Gmail 帳戶發送 5,000 封或更多郵件。要求內容包括 SPF、DKIM、至少為 p=none 的 DMARC 策略、對齊，以及營銷郵件的一鍵退訂，Google 後來又轉向更嚴格的執行，包括拒收。Microsoft 從 2025 年 5 月起，對超過該發信量的發信方向 Outlook.com、Hotmail 和 Live 應用了類似規則。具體的門檻和日期請查閱這兩家公司的最新頁面。很多中小企業每天發送不到 5,000 封，但認證仍然會影響郵件的落點。

可以直接上 p=reject 嗎？

可以發佈，但沒有證據就很冒險。如果任何合法系統，例如服務檯、開票工具或被遺忘的掃描器，尚未對齊，reject 會讓收件方丟棄它的郵件。先停留在 p=none 或隔離檔位，直到報告顯示你自己的每個來源都已通過，等這種狀態保持一段時間之後，再提升到拒收。

DMARC 報告包含個人數據嗎？

聚合報告包含發信 IP 地址、郵件數量、通過或失敗的結果和你的域名，沒有郵件正文和主題行。這在很大程度上是運營數據，但在某些法域裡 IP 地址可能屬於個人數據，所以應當像對待其他日誌一樣對待它們。

為什麼加了 SPF include 之後郵件還是失敗？

通常是因為問題根本不在 SPF。只要 SPF 或 DKIM 通過並且對齊，DMARC 就通過。只有當供應商的 return-path 域名同樣是你的域名時，include 才有用，這往往需要供應商的自訂退信域名設定。另一個原因是超過了 10 次查詢上限，這會讓整條記錄變成錯誤，所以每次新增之後都要重新計數。