Defaults.Exposed › 修復 › Guides
DMARC 失敗但 SPF 和 DKIM 都通過？對齊修復指南（2026）
發布於 2026-07-08
資料截至 2026-06-29 · 方法論 v7。 基於 261 百萬個已評分網域的彙總普查資料。參見我們如何評分。
DMARC 要的不只是”通過”——通過 SPF 或 DKIM 的那個網域必須與你的 From 網域匹配。大多數 “SPF 通過、DMARC 失敗” 的郵件，是在供應商的退信網域上通過了 SPF，不是在你的網域上。根據 Defaults.Exposed 普查（2026-06-29），在 261,086,232 個已評分網域中，只有 7.4% 在強制執行的 DMARC 政策下以對齊方式通過 SPF。
修復比這團困惑看上去要快。讀一讀 Authentication-Results 標头，看是哪條腿——SPF 還是 DKIM——在錯誤的網域上通過；然後要麼開啟發送服務的自定義網域 DKIM 簽名（通常就是几條 CNAME，而且是能挺過轉發的修復），要麼設定它的自定義回信路径讓 SPF 在你的網域上通過。DMARC 只需要一條對齊的腿。
SPF 和 DKIM 都通過，DMARC 怎麼還會失敗？
因為 DMARC 從來不問”SPF 通過了嗎？“它問的是：SPF 或 DKIM 是否為一個與收件人看到的 From 位址匹配的網域通過了？這個附加條件叫對齊，也是 DMARC 的全部意義——沒有它，任何人都可以在自己擁有的網域上通過 SPF，同時在 From 標头裡顯示你的網域。
每項檢查驗證的是不同的網域：
| 檢查 | 它實際評估的網域 | 在哪裡看 |
|---|---|---|
| SPF | Return-Path（RFC5321.MailFrom，即退信/信封發件位址）——不是 From 標头 | Authentication-Results 裡的 smtp.mailfrom= |
| DKIM | 簽名 d= 標簽裡的網域——簽名方選什麼就是什麼 | Authentication-Results 裡的 header.d= |
| DMARC | 你 From 標头裡的網域——並且要求 SPF 的網域或 DKIM 的 d= 與之匹配 | Authentication-Results 裡的 header.from= |
各個环節通常是這樣出錯的：你的郵件通讯平台或 CRM 用類似 [email protected] 的 Return-Path 發信，SPF 是對 vendor.com 檢查的且通過了，DKIM 以 d=vendor.com 通過了——而 DMARC 失敗，因為兩個通過的網域都不匹配 yourcompany.com。每項檢查都說了實話；但沒有一項驗證的是你。改你自己的 SPF 記錄救不了這個——它根本沒被查詢過。這和 SaaS 工具的 SPF 失敗裡讲的是同一個陷阱。
普查資料顯示走完這最後一步的發件方有多稀少：261,086,232 個已評分網域中只有 27,640,987 個（10.59%）有強制執行的 DMARC 政策，而在強制政策下以對齊方式通過 SPF 的只有 7.4%。在 SPF 以軟失敗（~all）結尾的 77.5 百萬個網域中，只有 9.2% 處於強制執行的 DMARC 政策之下；在硬失敗（-all）發布者中，12,142,351 個被強制執行，42,514,532 個沒有。大多數網域止步於 “SPF 通過”——而沒有 DMARC 落實它，這几乎保護不了什麼。
如何讀 Authentication-Results，看出哪條腿沒對齊？
通過出問題的服務給自己發一封郵件，打開原始源碼，找到 Authentication-Results 標头。典型的未對齊結果長這樣：
Authentication-Results: mx.google.com;
spf=pass smtp.mailfrom=bounces.espmail.net;
dkim=pass header.d=espmail.net;
dmarc=fail (p=NONE) header.from=yourcompany.com
按三個對比來讀：
- SPF 腿：
smtp.mailfrom=以你的網域結尾嗎？這裡是bounces.espmail.net——未對齊。 - DKIM 腿：
header.d=以你的網域結尾嗎？這裡是espmail.net——未對齊。 - DMARC 判定：
header.from=是 DMARC 在守護的網域。兩條腿都沒匹配上它，所以dmarc=fail——尽管兩項單獨檢查都寫著pass。
哪條腿已經涉及你自己的網域（或能被改成涉及），就修哪條。你只需要一條。
寬松對齊和嚴格對齊有什麼區別？
DMARC 提供兩種匹配模式，由 DMARC 記錄裡的 aspf（SPF）和 adkim（DKIM）標簽設定：
- 寬松（
r，默認值）：兩個網域只需共享同一個組織網域——按公共後缀列表（Public Suffix List）判定的可註冊網域。bounce.yourcompany.com與yourcompany.com對齊；DKIM 的d=mail.yourcompany.com也一樣。這正是供應商的自定義回信路径和自定義 DKIM（都放在子網域上）能起作用的原因。 - **嚴格（
s）：**兩個網域必須逐字元完全一致。bounce.yourcompany.com就不再與yourcompany.com對齊了。
如果你的記錄沒提到 aspf 或 adkim，你就處於寬松模式——而且你几乎肯定應該留在那裡。對大多數發件方而言，嚴格模式不帶來任何有意義的安全增益，却會悄无聲息地弄壞你設定的每一個合法子網域發送源。如果 DMARC 在失敗而你的記錄裡有 aspf=s 或 adkim=s，光這一點就可能是病根。
DMARC 對齊怎麼修？
- 動 DNS 之前，先在 defaults.exposed 執行免費掃描。 它會顯示你的 DMARC 記錄和政策、你的 SPF 和 DKIM 是否設定成可對齊，以及還有什麼壞掉了——這樣你先修對的那條腿。
- 測試每個發送服務並讀取它的 Authentication-Results（如上）。列出所有來源——郵箱服務商、郵件通讯工具、CRM、開票應用——並逐個記下
smtp.mailfrom和header.d是你的網域還是供應商的。 - 給每個供應商啟用自定義網域 DKIM 簽名——能長久的修復。 每個正經的發送服務都提供”網域驗證”：几條 CNAME 記錄，讓它以
d=yourcompany.com（或某個子網域，在寬松模式下同樣對齊）簽名。對齊的 DKIM 通常是更容易的修復，也是唯一能挺過轉發的修復，因為轉發從設計上就會弄壞 SPF。 - 要對齊 SPF，就啟用供應商的自定義回信路径（常叫自定義退信網域）——通常是一條 CNAME，比如
bounce.yourcompany.com指向供應商。這樣 SPF 就在你的組織網域上通過並對齊。有這個功能就做，但把它當第二條腿，不是對齊 DKIM 的替代品。 - 讓對齊保持寬松模式，除非你有明確且理解透彻的理由需要
aspf=s/adkim=s。 - 重新掃描確認兩條腿，然後走向強制執行。
p=none的 DMARC 政策只報告、不拦截；等你的真實發送源都對齊之後，通往一條真正保護你的政策的完整路径在修復 DMARC 頁面，而 IONOS 上的 DMARC 這類服務商教程涵蓋了 DNS 面板裡的具體點法。
我該修 SPF 對齊還是 DKIM 對齊？
每個發送來源需要一條對齊的腿。如果只能做一個，這個選擇毫无懸念：
| 修復 | 涉及什麼 | 能挺過轉發嗎？ |
|---|---|---|
| 對齊的 DKIM（自定義網域簽名） | 在供應商”網域驗證”面板裡加几條 CNAME | 能——簽名隨郵件一起旅行 |
| 對齊的 SPF（自定義回信路径/退信網域） | 一條 CNAME，前提是供應商提供 | 不能——任何轉發方的 IP 都會顶替供應商的 |
值得知道的特例：Google Workspace 和 Microsoft 365 會默認用它們自己的兜底網域（gappssmtp.com、onmicrosoft.com）給你的郵件做 DKIM 簽名——於是 DKIM 顯示 pass 而 DMARC 依然失敗。這是整個問題最常見的具體形態，它有自己的專門指南：DKIM 通過但 DMARC 依然失敗：默認簽名陷阱。
常見問題
SPF 和 DKIM 都需要對齊 DMARC 才能通過嗎？ 不需要——一條對齊的通過就足夠。最佳實践是兩條都對齊，這樣轉發弄壞 SPF 那條腿時，DKIM 那條腿仍然扛著 DMARC 的通過。在 2026-06-29 普查評分的 261,086,232 個網域中，只有 3.87% 完成了 SPF + DMARC + DKIM 的完整三件套。
我的 ESP 後台說 SPF 和 DKIM 已”驗證”——為什麼 DMARC 還是失敗？ “已驗證”通常意味著供應商自己的發送在供應商的網域上通過。除非你完成了他們的自定義網域步驟（DKIM CNAME、自定義回信路径），郵件驗證的身份是供應商，不是你——而 DMARC 對比的是你的 From 網域。
不做對齊，一條嚴格的 -all SPF 記錄夠嗎？
不夠。嚴格限定符只是強化了 SPF 對 Return-Path 網域的判定，但 DMARC 仍然要求那個網域是你的。截至 2026-06-29 普查，發布 -all 的網域中只有 12,142,351 個處於強制執行的 DMARC 政策之下——另外 42,514,532 個的嚴格記錄沒有任何政策在落實。
為了更安全，我該切到嚴格對齊（aspf=s/adkim=s）嗎？
几乎從來不該。寬松對齊已經要求同一個可註冊網域，而冒充者控制不了它。嚴格模式主要的作用是弄壞你自己的子網域發送源——每當對齊莫名其妙地失敗，就查一查它。
DMARC 只在收件人轉發的郵件上失敗——同樣的修法嗎？ 那是 SPF 那條腿在傳輸途中死掉了：轉發方的伺服器不在任何人為你的回信路径設定的 SPF 記錄裡。轉發郵件的 SPF 修不了；答案是對齊的 DKIM，因為簽名能完好无損地挺過轉發。详見轉發郵件 SPF 失敗。
把報告發給負責人
如果你是在替客戶或雇主修這個問題，用證據來收尾。CNAME 生效後重新執行免費掃描，把評分報告轉發給企業負責人：有日期、說人話、顯示 SPF、DKIM 和 DMARC 已對齊並通過。這正是網路保險續保和下一份供應商安全問卷需要的材料——一套有效設定的證明，而不只是”我加了几條 DNS 記錄”。
檢查你的網域 → · DKIM 通過但 DMARC 依然失敗 → · 修復 DMARC → · 我們如何評分 → · 僅使用彙總資料。資料在歐盟境內儲存和處理。