Defaults.Exposed › 報告

為什麼我的SPF失敗了？英國和歐盟發件人的SaaS 10次查詢問題（2026年）

發布於 2026-07-09

數據截至2026-06-29 · 方法論 v7。 覆蓋261百萬個已評級域名的彙總普查數據。查看我們的評級方式。

當英國或歐盟企業使用SaaS工具時SPF失敗，最可能的原因是一條您從未需要考慮過的RFC規則：超過10次DNS查詢後，SPF不會返回”fail”——它會返回PermError，意味著該記錄被視為不存在。 至少已有797,263個域名越過了這條線。另有2,119,539個域名正好處於9至10次查詢的邊緣——再新增一個工具就會跌入同樣的深淵。

添加SaaS工具後為何SPF會出現問題？

SPF通過列出被授權代表您的域名發送郵件的郵件服務器來工作。現代企業不再運營自己的郵件服務器——他們使用Google Workspace處理內部郵件、Mailchimp用於營銷活動、HubSpot用於銷售序列、Pipedrive用於CRM外聯。每個平臺都會提供一行include:供您粘貼到DNS中。

問題在於：每個include:本身就是一次DNS查詢。該include內部的每條記錄也可能遞歸地觸發更多查詢。RFC 7208 §4.6.4設定了10次的硬性上限。超過10次後，接收郵件服務器將停止評估並返回PermError——PermError並非最終進入垃圾郵件的軟性失敗，它意味著您的SPF記錄被視為不存在。郵件身份驗證在SPF環節失敗。

您在DNS面板中看不到這種情況。計數器僅在實時評估期間觸發。您的可見記錄中可能只有三行include:，但實際上可能已有12層查詢深度，因為每個供應商的SPF記錄都會引入自己的子-include。

已有多少域名超過了限制？

至少797,263個。 這是在解析了所有被引用100次或以上的SPF include:目標（10,842個獨立目標，覆蓋所有include引用的95.2%）並評估每個域名完整鏈路之後得出的數字。表面計數（僅計算記錄中可見行的方式）約能找到7,958個。鏈路評估後的數字是其100倍，因為幾乎所有損害都隱藏在include目標內部不可見。

最可能影響歐洲企業的情況：

歐洲託管服務商與薄弱的SPF默認設置

您最初選擇的託管服務商至關重要——因為有些服務商設置的SPF默認值在您接入任何SaaS工具之前就已消耗了10次查詢配額中的幾次。

在我們普查中歐洲域名使用的最大託管服務商中：

IONOS尤為突出：1.0%的IONOS託管域名啟用了強制DMARC，這意味著絕大多數域名根本沒有任何有意義的發件人身份驗證。OVH域名在SPF嚴格設置方面表現更好（43.7%），但在DMARC強制執行方面仍降至2.2%——沒有DMARC的SPF只能保護信封，而非收件人實際看到的From:標頭。

Microsoft 365是個積極的例外：85.0%的Microsoft託管域名使用嚴格SPF，這主要是因為Microsoft的郵件流向導默認設置為-all。Google Workspace默認設置為~all（軟失敗），導致其92%的域名缺乏嚴格保護。

如何在60秒內診斷您的SPF故障

最快的檢查方法是使用能評估完整查詢鏈（而非僅可見記錄）的免費工具。在命令行運行nslookup -type=TXT yourdomain.com，計算看到的每個include:。然後查找每個記錄並計算其中的數量。如果在include用完之前手指先不夠用，您就處於危險區域。

更可靠的方法：在此檢查您的域名——掃描器會評估完整的解析鏈，標記PermError，並顯示哪些機制正在消耗您的查詢配額。

三種診斷結果：

• PermError — 您已超過10次。發送的每封郵件都會在接收方的SPF檢查中失敗。
• 處於9至10次查詢 — 您正處於懸崖邊緣。下一個SaaS集成將使您跌落。
• Softfail (~all) 而非 hardfail (-all) — 您在限制以內，但記錄設置過於寬鬆，無法提供真正的保護。關於-all與~all的完整說明，請參閱SPF配置錯誤報告。

使用多個SaaS工具時如何修復SPF

按永久性從高到低，有三種方法：

1. 審計和清理。 首先列出當前記錄中的所有include:。刪除任何您不再使用的平臺——舊的ESP、以前合同中的CRM工具、測試後放棄的平臺。這是免費的，通常可以恢復幾次查詢配額。每刪除一個include:可能消除1至3個子查詢。

2. 壓平您的SPF記錄。 SPF壓平將所有include:目標解析為底層IP範圍，並將其直接以ip4:和ip6:機制寫入您的記錄。IP機制不觸發查詢，因此壓平後的記錄可以列出數十個發件來源，查詢次數仍為零。缺點是：每當供應商更新其發件IP時您需要重新壓平，而這種更新不會提前通知。大多數企業使用付費的SPF壓平服務（PowerDMARC、EasyDMARC、Dmarcian等均提供此服務）或構建監控工作流。

3. 使用SPF宏。 RFC 7208宏允許您構建每次檢查只執行一次DNS查詢並動態響應的記錄，而非採用include鏈式結構。宏需要DNS託管支持和一定的實施工作，但對於擁有大量SaaS發件人的組織來說，這是架構上最乾淨的解決方案。

修復SPF後，將其與DMARC強制執行配合使用——沒有DMARC的SPF只能驗證信封發件人，而非收件人看到的From:標頭地址。

常見問題

為什麼我的SPF記錄通過了DNS工具測試，卻仍在郵件標頭中失敗？ 大多數DNS查詢工具只計算您自己記錄中可見的機制，而不計算這些機制觸發的子查詢。您可能只有兩行include:，但如果每個供應商的記錄中還包含更多，您同樣會超過限制。只有鏈路評估工具（或接收郵件服務器）才能計算完整深度。檢查您的域名以查看真實的鏈路計數。

SPF失敗是否意味著我的郵件會進入垃圾郵件？ PermError（查詢次數過多）意味著身份驗證的SPF環節返回無結果——實際上相當於缺失。DMARC同時評估SPF和DKIM；如果DKIM通過，即使SPF出現PermError，DMARC仍可能通過。如果兩者均未通過，DMARC失敗，結果取決於您的DMARC策略。p=none時，郵件仍會投遞但失敗會被記錄。p=quarantine或p=reject時，郵件會被過濾或退回。請修復SPF，不要僅依賴DKIM。

典型的SaaS技術棧會使用多少次查詢？ 我們普查中的p99 SPF記錄已處於9次查詢——在添加任何內容之前就已接近限制。Google Workspace記錄增加3至4次查詢；Mailchimp增加1至2次；HubSpot根據其當前配置增加1至3次。三個主流工具加上託管服務商的默認設置，往往足以突破10次。

SPF壓平安全嗎？ 只要保持更新就是安全的。壓平將include:鏈轉換為靜態IP範圍——如果供應商輪換其發件IP而您未重新壓平，您將開始拒絕其郵件。大多數組織使用能監控IP變更的託管壓平服務，而非手動維護。

我的SPF多年來一直如此——為何突然失敗？ 因為您的供應商更新了他們的SPF記錄，而非您的記錄。每當SaaS平臺添加新的發件IP範圍或嵌套另一個include時，您這邊無需任何變更，鏈路成本就會上升。10次查詢限制是在消息接收時實時評估的，因此供應商周二上午的更改可能在週二下午就會破壞您的SPF。

修復SPF能提高郵件送達率嗎？ 它消除了身份驗證失敗的一個來源，這是保持穩定送達的先決條件——尤其是自Google和Yahoo開始對批量發件人強制執行DMARC對齊以來更為重要。SPF本身不是全部：將其與DKIM和DMARC配合使用，實現完整的郵件身份驗證。

免費檢查您的SPF

如果您不確定SPF記錄是否超過了查詢限制——或者設置過於薄弱而無法保護您的域名——請運行免費檢查。它會評估完整的解析鏈，並準確顯示查詢配額的消耗位置。

檢查您的域名 → · 修復SPF → · SPF PermError報告 → · SPF配置錯誤報告 → · SPF採用成熟度模型 → · 修復DMARC → · 僅使用匯總數據。數據在歐盟境內存儲和處理。