Defaults.Exposed › 修復 › Guides
Mailchimp、Brevo 或 Klaviyo 郵件 DMARC 失敗？開啟真正的網域驗證（2026）
發布於 2026-07-08
資料截至 2026-06-29 · 方法論 v7。 基於 261 百萬個已評分網域的彙總普查資料。參見我們如何評分。
通讯平台以“來自”你網域的身份發信，却沒有以你的網域完成驗證，DMARC 就會失敗。修法是啟用平台的自定義網域驗證——它的 DKIM CNAME，再加上（如果提供的話）一個自定義退信網域。這種缺口很常見：根據 Defaults.Exposed 對 261,086,232 個網域的普查（2026-06-29），在授權 SendGrid 的 740,321 個網域中，只有 18.0% 強制執行 DMARC。
修法是几條 DNS 記錄，加上在平台設定裡花十分鐘。以下內容：為什麼平台的共享驗證在 2024 年 2 月之後就不夠用了、在 Mailchimp、Brevo、Klaviyo 和 SendGrid 裡該打開哪個開關，以及按順序排列的修復步驟——包括從免費郵箱 From 位址遷移出來，這一步沒有任何 DNS 記錄能替你補救。
為什麼平台明明說一切都已驗證，通讯郵件却還是 DMARC 失敗？
因為通過驗證的是平台自己，不是你。開箱即用狀態下，ESP 會用它自己的退信網域替你的活動郵件設定 Return-Path，往往也用它自己的網域做 DKIM 簽名。接收方是對照 Return-Path（RFC5321.MailFrom）網域，而不是 From 標头來評估 SPF 的，所以 SPF 干干淨淨地通過了……只不過通過的是平台的網域。
DMARC 並不關心 SPF 或 DKIM 是否抽象意義上“通過”了。它問的是有沒有任何一項是針對你 From 位址裡的那個網域通過的——這種匹配叫對齊。ESP 的 SPF 通過項在它自己的退信網域上，不是你的；沒有自定義網域 DKIM 的話，它的簽名也在它自己的網域上，不是你的。什麼都對不上齊，所以你的 From 網域 DMARC 失敗——與此同時平台的儀表盘却顯示一片綠勾，因為從它的角度看，驗證工作正常。開啟自定義網域驗證（讓 DKIM 以你的網域簽名）就是全部的修法。完整的對齊機制見 DMARC 失敗但 SPF 和 DKIM 都通過。
2024 年 2 月發生了什麼變化？
Google 和 Yahoo 開始強制執行大宗發件方要求：針對 From 網域的對齊驗證、已發布的 DMARC 政策、一鍵退訂，以及垃圾郵件率限制。“搭 ESP 驗證的便车、隨便用什麼身份發信”這條共享基礎設施的捷径行不通了。對通讯郵件發件方來說，這帶來了兩個後果：
- 現在每個正經的 ESP 都在推自定義網域驗證，因為沒配它的活動郵件開始大量進垃圾箱或直接被拒收（Gmail 的版本是 550-5.7.26）。
- 免費郵箱的 From 位址在批量發信場景下已經死路一條。 你沒法再通過 ESP 從
[email protected]發活動郵件了：免費郵箱網域會發布嚴格的 DMARC 政策，你的 ESP 永遠沒法和它們對齊，接收方會大批量拒收或丢進垃圾箱。你需要在 From 位址上用自己的網域——沒有變通辦法。
完整的要求清單見我們的 Google 與 Yahoo 發件方要求 資料文章。
這個開關在 Mailchimp、Brevo、Klaviyo 和 SendGrid 裡分別叫什麼？
每個平台都有同一個功能，只是名字不同。它產出的東西永遠是一小組要加進你 DNS 的 CNAME 記錄——不管菜單上怎麼寫，你都能靠這一點認出它。
| 平台 | 功能名稱（大致） | 你要加進 DNS 的內容 | 備注 |
|---|---|---|---|
| Mailchimp | Domain authentication | DKIM CNAME（k2._domainkey、k3._domainkey） | 只靠 DKIM 對齊——Mailchimp 已不再用 SPF include，不要加 |
| Brevo | Authenticate your domain | DKIM CNAME 組 + 驗證記錄 | 設定時以 Brevo 文件裡當前的記錄組為準 |
| Klaviyo | Dedicated sending domain | DKIM CNAME + 退信（Return-Path）子網域 | 專屬網域同時也給你帶來 SPF 對齊 |
| SendGrid | Domain authentication（automated security） | CNAME 組（DKIM + return-path） | 不需要 SPF include——CNAME 已經覆蓋了 |
有兩個規律值得注意。第一，這些平台沒有一個想要你在 SPF 記錄裡加 include:——現代 ESP 驗證都是靠 CNAME 委托實作的，留著一個舊 include 只會白白消耗 DNS 查詢預算。第二，CNAME 委托本身就是個优點：平台可以在委托的名字背後轮換它的 DKIM 金鑰，而你完全不用再動 DNS。
怎麼一步步修復通讯郵件的 DMARC 失敗？
- 動 DNS 之前，先在 defaults.exposed 執行免費掃描。 它會顯示你網域當前的 SPF、DKIM 和 DMARC 狀態，讓你看清楚即將要補上的對齊缺口。
- 在平台裡開啟自定義網域驗證（見上表）。它會生成專屬於你帳號的 CNAME 記錄。
- 把 CNAME 原樣加進你的 DNS。 一個經典的錯誤：會自動給主機名補上你區域後缀的 DNS 面板，會把
k2._domainkey.yourdomain.com變成k2._domainkey.yourdomain.com.yourdomain.com。如果你的面板會自動追加網域，就只粘贴主機名部分。如果之後平台報告“no key for signature”，說明選擇器記錄沒生效——見 DKIM “no key for signature”。 - 在平台有提供的地方，設定自定義退信網域（Return-Path）。 這也能讓 SPF 這條腿對齊，給 DMARC 兩條通過的路。在沒有提供這個選項的地方（比如 Mailchimp），單靠對齊的 DKIM 就足以完全通過 DMARC——DMARC 只需要一條腿對齊。
- 如果 From 位址還在用免費郵箱，把它換成自己的網域。 是
[email protected]，不是[email protected]。這是硬性要求，不是可選項。 - 在平台裡驗證，然後重新掃描。 等平台的檢查變綠（DNS 生效可能要几分鐘到几小時），給自己發一封活動郵件，確認標头顯示 DKIM 是用你的網域簽名的。然後處理 修復 DMARC 頁面標出的其他問題——如果你的網域根本沒有 DMARC 記錄，那就是接下來十分鐘要做的事。
有多少通讯郵件發件方真正把這件事做對了？
普查是從 DNS 一側讀出來的：對每個平台，有多少網域授權了它——其中又有多少保護了正在發信的這個網域，資料來自 Defaults.Exposed 對 261,086,232 個網域的普查（2026-06-29）。
| 平台（SPF 目標） | 授權它的網域數 | 強制執行 DMARC 的比例 |
|---|---|---|
SendGrid（sendgrid.net） | 740,321 | 18.0% |
Mailgun（mailgun.org） | 1,306,692 | 35.9% |
Amazon SES（amazonses.com） | 551,446 | 41.9% |
資料截至 2026-06-29 的普查。“強制執行 DMARC”指授權網域發布了 p=quarantine 或 p=reject。
即便是在表格顶端，專業平台上的大多數發件方依然沒有保護好網域：在授權 Amazon SES 的 551,446 個網域中，只有 41.9% 強制執行 DMARC，Mailgun 的 1,306,692 個中只有 35.9%——SendGrid 的 740,321 個中更是只有 18.0%。基礎設施很專業，網域保護大多沒跟上。包含郵箱托管商在內的完整服務商排行見哪家郵件服務商的 SPF 最強。
常見問題
我需要把 Mailchimp 加進我的 SPF 記錄嗎？
不需要——而且不要加。Mailchimp 通過它的 k2/k3 CNAME 只靠 DKIM 對齊，已經不再為客戶發布 SPF include。一個殘留的舊 include:servers.mcsv.net 對 DMARC 毫无作用，只會白白浪費 DNS 查詢預算；這裡對齊的那條腿是 DKIM。
開啟網域驗證能讓我的通讯郵件走出垃圾箱嗎？ 它去掉了最大的一個原因——在一個有 DMARC 政策的網域上發送未對齊的郵件——而且這是 Google/Yahoo 規則的硬性要求。但它修不了名單質量問題：即使驗證完美无缺，高投訴率和缺失一鍵退訂依然會讓郵件留在垃圾箱裡。先把驗證修好；這是有明確答案的那部分。
我能不能繼續用 @gmail.com 位址發活動郵件？ 不能。免費郵箱服務商正是為了不讓別人以它們的身份發信，才發布嚴格的 DMARC 政策，而你的 ESP 永遠沒法和 gmail.com 對齊。自 2024 年 2 月起，這類郵件會被大規模拒收或丢進垃圾箱。在 From 位址上用自己的網域，是唯一的出路。
我已經開了網域驗證——為什麼 DMARC 還是失敗？ 通常是三件事之一：CNAME 被會自動追加區域後缀的 DNS 面板搞乱了（第 3 步）、活動郵件的 From 網域和你驗證的網域不一致，或者除了通讯郵件之外還有別的發信來源在失敗。在 2026-06-29 普查覆蓋的全部 261,086,232 個網域中，只有 10.59% 強制執行了 DMARC——如果你的網域做到了，說明已經很接近了；重新掃描，看看是哪條腿沒對齊。
每天發信量不到 5000 封的小名單也適用嗎？ 最嚴格的門槛正式來說只針對大宗發件方，但接收方會把驗證的基本要求套用在所有人身上，而且現在的 ESP 不論發信量大小都要求網域驗證。把它當成硬性要求就好：只是几條 DNS 記錄，能在你的名單增長的那一天挡住活動郵件崩掉的風險。
把報告發給老板
如果你是在替客戶修這個問題——或者你擁有這份通讯郵件但不掌握 DNS——用證據來收尾。CNAME 生效後重新執行免費掃描，把評分報告轉發給企業負責人：語言直白、帶日期、DMARC 對齊已修好。這份凭證能回答網路保險續保和下一份客戶安全問卷裡的問題——一份記錄在案的前後對比，而不是一句“我在 Mailchimp 裡點了几下按钮”。
檢查你的網域 → · DMARC 失敗但 SPF 和 DKIM 都通過 → · 修復 DMARC → · 修復 DKIM → · 我們如何評分 → · 僅使用彙總資料。資料在歐盟境內儲存和處理。