Defaults.Exposed › 修復 › Guides
你的 SaaS 工具 SPF 一直失敗？原因和修復順序——歐洲版（2026）
發布於 2026-07-08
資料截至 2026-06-29 · 方法論 v7。 基於 261 百萬個已評分網域的彙總普查資料。參見我們如何評分。
當一個 SaaS 工具“SPF 失敗”時，問題通常不在你的記錄本身：要麼是郵件沒通過 DMARC 對齊，要麼是你的 include 鏈已經超出了 SPF 10 次 DNS 查詢的上限。根據 Defaults.Exposed 對 261,086,232 個網域的普查，在 138,927,207 個發布 SPF 的網域中，有 2,119,539 個正處在 9–10 次查詢——只差一個 SaaS include 就會跌下懸崖。
以下內容：怎麼判斷你到底是這兩個問題中的哪一個，然後是修復順序——先掃描，找出這個工具真正的發信網域，把服務商切換到自定義網域 DKIM，只在真正有幫助的地方才新增 SPF include——外加針對 HubSpot、Salesforce、Mailchimp 和 SendGrid 的具體做法。
為什麼來自 SaaS 工具的郵件會 SPF 失敗？
几乎所有情况都屬於這三種模式之一：
| 報告或退信說了什麼 | 真正的問題是什麼 | 修法 |
|---|---|---|
| SPF 通過，DMARC 仍然失敗 | 對齊問題：這個工具在它自己的退信網域上通過了 SPF，不是你的網域 | 開啟服務商的自定義網域 DKIM（CNAME） |
SPF permerror | 你的 include 鏈超出了 SPF 10 次 DNS 查詢的上限 | 精簡 include；見查詢次數過多的修法 |
SPF fail / softfail | 這個工具確實在用你的退信路径發信，但沒有出現在你的記錄裡 | 新增該服務商的 include，或啟用它的自定義退信網域 |
資料截至 2026-06-29。
加粗的那一行是大多數人所處的位置。給每個工具都加一行 include: 解決不了這個問題——而且每加一行都讓你离第二行更近一步：至少已有 797,263 個網域已經越過了 10 次查詢的上限，它們的 SPF 現在返回 PermError，起不到任何保護作用。完整資料見 SPF PermError 報告。
SPF 實際檢查的是哪個網域？
不是你 From 標头裡的那個。接收方是對照 Return-Path 網域（RFC5321.MailFrom，也叫退信位址或信封發信人）來評估 SPF 的——收件人看到的 From 標头在 SPF 檢查本身中完全不起作用。
這一個事實就能解釋大多數“SaaS SPF 失敗”。你的營銷平台發信時用的 Return-Path 類似 [email protected]；SPF 檢查的是 vendor.com，而且干干淨淨地通過了。然後 DMARC 會問：這個通過了 SPF 檢查的網域，和你的 From 網域一致嗎？不一致，所以 DMARC 裡的 SPF 這條腿失敗了，你的儀表盘上就顯示“SPF 失敗”。編輯你自己的 SPF 記錄解決不了這個問題——你的記錄根本沒被查詢過。
修復順序是什麼？
- 先執行免費掃描。 它會一次性告訴你 SPF 是缺失、重復、超出查詢上限還是正常，以及 DMARC 現狀如何——在你動 DNS 之前。
- 找出這個工具實際使用的 Return-Path。 從這個工具給自己發一封測試郵件，讀取原始郵件裡的 Return-Path 標头（以及 Authentication-Results）。這能告訴你自己處在上表的哪一行。
- 開啟服務商的自定義網域 DKIM。 每個正經的 SaaS 工具都提供“網域驗證”功能：几條 CNAME 記錄，讓它能以你的網域做 DKIM 簽名。這個簽名和你的 From 網域對齊，所以 DMARC 能通過 DKIM 這條腿——而且是持久的，即便郵件被轉發也一樣。這才是能長久生效的修法。
- 只有當服務商真正用你的退信路径時，才新增它的 SPF include——也就是你已經啟用了它的自定義退信網域，或者它確實在信封裡用了你的網域發信。給一個用自己網域退信的服務商新增 include，什麼都換不到，只會消耗你的查詢預算。
- 保存之前先數一數你的 DNS 查詢次數。 上限是 10 次已解析的查詢，include 會遞歸計數，而 2,119,539 個網域已經處在 9–10 次——普查的第 99 百分位是 9 次。快到邊緣了？先刪掉不再使用的工具的 include。剛換過郵件服務商？檢查有沒有殘留的第二條記錄——兩條 SPF 記錄等於一個 PermError。
- 重新掃描並確認。 SPF 在正確的網域上通過，DKIM 已對齊，DMARC 通過。完整參考見如何修復 SPF；服務商操作指南如 GoDaddy 上的 SPF 和 IONOS 上的 DMARC 覆蓋了具體的 DNS 面板點擊路径。
HubSpot、Salesforce、Mailchimp 和 SendGrid 分別該怎麼做？
HubSpot。 在 HubSpot 設定裡連線你的發信網域，發布它簽發的兩條 DKIM CNAME（hs1-… / hs2-…）。這能讓 DKIM 和你的 From 網域對齊。除非你已經把 HubSpot 設定成使用你自己的退信網域，否則不需要 HubSpot 的 SPF include。
Salesforce。 在 Salesforce Setup 裡建立一個 DKIM 金鑰，發布它生成的那對 CNAME。如果 Salesforce 用你組織的退信路径發信，就新增 include:_spf.salesforce.com 並設定退信網域——這是少數几個真正經常需要 SPF include 的大型 CRM 之一。
Mailchimp。 驗證你的網域，發布 k2 / k3 這兩條 DKIM CNAME。Mailchimp 的對齊只靠 DKIM——已經沒有 SPF include 可以加了，從舊教程裡抄一條只會白白浪費查詢次數。
SendGrid。 完成網域驗證（“automated security”）：三條 CNAME，同時處理 DKIM 和你自己子網域上的退信路径。不需要 SPF include。在 SPF 授權了 sendgrid.net 的 740,321 個網域中，只有 18.0% 有強制執行的 DMARC（資料截至 2026-06-29）——大多數 SendGrid 發件方就差最後一步。
Zendesk 及其他所有工具：模式相同。找到該工具的“網域驗證”頁面，發布它的 DKIM CNAME，只有在該工具文件明確說明它使用你的退信路径時，才去動 SPF。
SPF 對歐洲企業有什麼不同嗎？
沒有——SPF、DKIM 和 DMARC 在任何地方的工作原理都一樣。在歐洲不同的是背景：誰在問，以及你的邻居們已經做到了什麼程度。
你的 ccTLD 決定了當地的基準線。 歐洲的 ccTLD 發布 SPF 的比例明顯高於 .com，但真正把活兒做完——在此之上再加一個強制執行的 DMARC 政策——的網域，在任何地方都是少數：
| TLD | SPF 採用率（占已評分網域） | 強制執行 DMARC（占已評分網域） |
|---|---|---|
| .nl | 75.91% | 29.43% |
| .ie | 70.89% | 8.79% |
| .de | 64.67% | 21.38% |
| .dk | 50.42% | 19.88% |
| .com | 54.14% | 9.50% |
資料截至 2026-06-29。法國：13.65% 強制執行 DMARC；意大利：5.24%。
你的歐洲主機商的默認設定很重要。 有 4,346,526 個網域在 SPF 裡授權了 IONOS 的歐盟郵件伺服器（_spf-eu.ionos.com）——其中只有 0.3% 以嚴格的 -all 結尾，1.0% 強制執行 DMARC。OVH 的 2,132,049 個在嚴格性上表現更好（43.7%），但只有 2.2% 強制執行 DMARC（資料截至 2026-06-29）。如果你從沒動過自己的記錄，你現在站的就是這些默認設定。
監管機構現在明確點了名。 NIS2 第 21(2)(j) 條要求受監管實體保障其通信安全，歐盟委員會實施法規 (EU) 2024/2690 明確規定了郵件和 DNS 安全措施。郵件驗證是其中具體、可核查的一环——而且難得的是，作為合規要求，它是免費的。
關於資料駐留： Defaults.Exposed 的掃描器和普查系統執行在 AWS eu-west-1，我們只公開彙總資料，一次掃描只檢查你所詢問的那一個網域。
常見問題
我的 SPF 檢測工具顯示“通過”，但這個工具的儀表盘却說 SPF 失敗——為什麼？ 檢測工具測的是你的記錄；接收方測的是這個工具實際使用的 Return-Path 網域，然後 DMARC 把它和你的 From 網域做比對。這是一個對齊失敗，不是記錄失敗——要靠服務商的自定義網域 DKIM 來修，不是靠修改 SPF。
我要不要干脆給我們用的每個工具都加上 SPF include？ 不要。每一個 include 都會遞歸地消耗 SPF 10 次查詢預算的一部分：在 138,927,207 個發布 SPF 的網域中，有 2,119,539 個處在 9–10 次查詢，至少 797,263 個已經超標——它們的 SPF 會返回 PermError，起不到任何保護作用（資料截至 2026-06-29）。
加了 include 也能順帶修好 DMARC 嗎？ 只有當這個工具用你的退信路径發信、讓 SPF 既通過又對齊時才行。對大多數 SaaS 工具來說並非如此——這就是為什麼讓 SaaS 郵件的 DMARC 通過 的那條腿是對齊的 DKIM，而不是 SPF。
這在歐盟是一項法律要求嗎？ 對於 NIS2 監管範圍內的實體來說，第 21(2)(j) 條和實施法規 (EU) 2024/2690 把郵件安全變成了一項義務。即便不在監管範圍內，保險公司和客戶問卷也越來越常問到這個——截至 2026-06-29，沒有任何一個歐盟 ccTLD 有超過三分之一的網域達到強制執行的 DMARC 政策（表現最好的 .nl 也只有 29.43%；.it 是 5.24%）。
把報告發給老板
CNAME 生效後，重新執行掃描，把評分報告轉發給企業負責人或客戶。它會用大白話說明之前哪裡在失敗、你修了什麼、這個網域現在處於什麼狀態——這正是保險續保或客戶安全問卷所需要的書面證據，而不只是你嘴上說說。
免費檢查你的網域
私密、僅網域所有者可見地看看 SPF、DKIM 和 DMARC 到底是哪條腿在失敗。
檢查你的網域 → · 修復 SPF → · SPF PermError：“DNS 查詢次數過多” → · 我們如何評分 → · 僅使用彙總資料。資料在歐盟境內儲存和處理。