Defaults.Exposed › 修復 › Guides
SPF PermError：如何在不弄壞郵件的前提下修復"DNS 查詢次數過多"（2026）
發布於 2026-07-08
資料截至 2026-06-29 · 方法論 v7。 基於 261 百萬個已評分網域的彙總普查資料。參見我們如何評分。
根據 Defaults.Exposed 對 261,086,232 個網域的普查——出自 139 百萬個 SPF 發布者——至少有 797,263 個網域超出了 SPF 10 次 DNS 查詢的上限。超過十次，接收方就會停止解析並返回 PermError：你的 SPF 作廢，而 DMARC 會把 PermError 算作一次失敗。
修法有嚴格的順序，而大多數指南都搞反了。先數清你真實的、已解析的查詢次數；刪除失效和不再使用的 include——光這一步就能修好大多數記錄；把大宗發信方移到有自己 SPF 預算的子網域上；只在萬不得已時才做扁平化，而且只用會自動重新扁平化的方式，因為静態扁平化會腐化，並且會悄无聲息地破壞送達率。
“SPF PermError：DNS 查詢次數過多”是什麼意思？
RFC 7208 §4.6.4 把每次 SPF 檢查的上限定為 10 次 DNS 查詢。超過十次，接收方就會停止解析，返回 PermError——整條記錄都會被當作損壞處理，而不只是超出預算的那部分。同一節裡還有一個不太為人所知的第二道上限：最多允許 2 次“空查詢”（返回无結果或 NXDOMAIN 的查詢），所以哪怕只是几個指向已停用服務的失效 include: 條目，單靠它們自己就足以讓你的 SPF 作廢。
後果比“沒有 SPF”還要糟：DMARC 把 PermError 當作 SPF 失敗處理，所以一個自己弄壞了 SPF 的網域，在每一次 DMARC 評估裡 SPF 這條腿都是未驗證的。如果 DKIM 沒配好，或者在傳輸途中出了問題，這些郵件就會彻底 DMARC 失敗。
有一個普查數字最能說明這種失敗方式有多殘酷：有 112,215 個網域發布了嚴格的 -all 記錄，却因為查詢次數超標而作廢——這是在總共發布 -all 的 54,655,923 個網域裡統計出來的。它們的所有者已經做對了最難的那部分——選擇了嚴格的結尾——結果多加了一個 include，就把整條記錄關掉了。它們看起來很嚴格；實際上是壞的。完整資料見 SPF PermError 報告。
為什麼我什麼都沒改，SPF 却壞了？
因為這個預算大部分是被別人的記錄花掉的。每一個 include: 都是遞歸求值的，它內部的每一個查詢機制都會算進你的十次配額裡。DNS 面板裡的一行，解析開之後可能要花掉四五次查詢。某個服務商在裡面又嵌套了一個 include，你的 SPF 就死了，而你的區域文件裡連一個字都沒改過。
大平台不是問題所在：Google 和 Microsoft 都已經把自己的 SPF 扁平化了——_spf.google.com 和 spf.protection.outlook.com 展開後就是純 IP 列表，內部查詢成本為零（對照實時 DNS 核實，2026 年 7 月）。真正的爆表往往來自主機面板裡嵌套了好几層的 include 鏈，以及誠實的 SaaS 堆叠——郵箱加通讯工具加 CRM 加工單系統，每個都“只是一個 include”。沒有人是故意加上第十一次查詢的；它是一系列合理決定累加出來的結果。這就是為什麼懸崖邊上挤滿了網域：有 2,119,539 個網域正好處在 9–10 次已解析查詢——大約每 66 個 SPF 發布者裡就有 1 個，今天還沒事，哪天有人再粘贴進一個 include 就作廢了。SPF 記錄的第 99 百分位已經解析到 9 次查詢。如果你的技术栈以 SaaS 為主，SPF 在 SaaS 工具上失敗的指南 覆蓋了按服務商拆解的版本。
SPF 記錄裡哪些部分算作 DNS 查詢？
| 機制 | 查詢成本 | 備注 |
|---|---|---|
include: | 1 次 + 其內部的一切，遞歸計算 | 几乎所有爆表都源自這裡 |
a | 每個 1 次 | 即便是你自己網域的裸 a 也算 |
mx | 每個 1 次（外加 MX 主機的 A 記錄查詢） | 經常被忽略 |
ptr | 1 次——而且自 2014 年起已被棄用 | 不管怎樣都該刪掉 |
exists: | 每個 1 次 | 少見 |
redirect= | 1 次 + 目標記錄的內容 | 計算方式和 include 一樣 |
ip4: / ip6: | 0 | 這正是扁平化管用的原因 |
-all / ~all / ?all | 0 | 限定符本身不計費 |
數的是解析後的總數，不是看得見的行數。四個 include 可能是四次查詢，也可能是十四次。
怎麼在不弄壞郵件的前提下修復“DNS 查詢次數過多”？
- 動 DNS 之前，先執行免費掃描。 它會解析你完整的 include 鏈，顯示你真實的查詢次數，讓你修的是真正的問題——而不是面板裡看起來的那個樣子。（如果它說你根本沒有 SPF，那是另一種失敗——見 “SPF 記錄未找到”。）
- 先刪除失效和不再使用的 include。 2023 年就不用了的工具、遷移後殘留的舊主機 include、重復項、任何
ptr機制。失效的 include 有双重毒性：既消耗查詢預算，又是空查詢最常見的來源。大多數超標記錄光靠這一步就能重新回到 10 次以下。如果你的記錄裡還帶著上一個服務商的機制，參照遷移清理指南。 - 檢查剩下的每個 include 是否還有作用。 接收方是對照 Return-Path（RFC5321.MailFrom）網域，而不是 From 標头來評估 SPF 的——而很多 SaaS 工具會把它們自己的退信網域放在 Return-Path 上，所以你記錄裡它們的 include 除了消耗預算之外什麼作用都沒有。只為那些真正用你的網域做 Return-Path 的服務保留 include；其余的改用服務商的自定義網域 DKIM。
- 把大宗發信方移到子網域。 通讯郵件用
news.yourdomain.com，事務性郵件用mail.yourdomain.com。每個子網域都有自己獨立的 SPF 記錄和全新的 10 次查詢預算，某一條流裡的問題也不會波及其他流。 - 只有到這一步才考慮扁平化——而且只做自動化的扁平化。 見下文。
- 重新掃描以確認你稳稳低於 10 次——目標是留有余量，而不是剛好卡在 10 上，否則你又重新加入了懸崖邊上那 2.1 百萬個網域的行列。然後處理修復 SPF 頁面標出的其他問題。
我該不該扁平化我的 SPF 記錄？
扁平化就是把 include 替換成它們底層的 ip4:/ip6: 網段，查詢成本為零。這確實管用——但如果是手動做的，就是一場延遲發作的送達率事故。
| 做法 | 查詢次數 | 隨時間推移 |
|---|---|---|
| 精簡 + 子網域（第 2–4 步） | 通常能回到 10 次以下 | 稳定；服務商自己管理自己的 IP |
| 自動化扁平化（服務或定時任務會重新解析並 republish） | 接近 0 | 能跟上服務商的 IP 變化；安全 |
| 一次性手動扁平化 | 接近 0——但只是今天 | 會悄悄腐化：服務商會轮換 IP，合法郵件開始 SPF 失敗，而你這邊不會有任何報錯 |
服務商會定期轮換發信 IP，而且從不通知任何人。一份静態 IP 列表在你粘贴進去的那一天是對的，几個月內會悄悄變錯——而因為這種失敗表現為別人收不到你的郵件，你往往很晚才會發現。如果精簡和子網域已經能讓你回到上限以下，就到此為止；永遠不要把第三方的 IP 網段手動抄進你的記錄當作永久解決方案。
常見問題
SPF PermError 是不是意味著我的郵件會立刻停止送達？ 不會立刻——這正是它危險的地方。DMARC 把 PermError 算作 SPF 失敗，所以送達完全依賴 DKIM；如果 DKIM 缺失或在傳輸中出問題，你就是在 DMARC 失敗。在我們普查的 139 百萬個 SPF 發布者中（截至 2026-06-29），至少有 797,263 個處於這種狀態——大多數人對此一无所知。
我的記錄只有四個 include——怎麼會超過 10 次查詢？ Include 是遞歸計數的：每個 include 內部（以及它自己的 include 內部）的一切都算進你的預算，所以四行看得見的記錄，解析出來可能是十四次查詢。要用能遞歸解析的工具來數，不能靠肉眼——正是靠解析這些鏈條，我們的 PermError 報告 才發現了比表面數字多出約 100 倍的損壞網域。
我的記錄以 -all 結尾——那我肯定是受保護的吧？
只有在記錄能正常求值的前提下才是。我們的普查（截至 2026-06-29）發現有 112,215 個網域的嚴格 -all 記錄因為查詢超標而作廢。一個 PermError 記錄上的嚴格限定符起不到任何保護作用。
10 次查詢的上限是針對每個 include，還是針對整條記錄？ 是針對整次評估：RFC 7208 §4.6.4 把完整檢查的上限定為 10 次，外加最多 2 次空查詢。每個子網域都有自己獨立的記錄和預算——這也是第 4 步管用的原因。
ip4 和 ip6 條目算進上限嗎？ 不算——IP 機制不花任何查詢成本，這正是扁平化能降低查詢次數的原因。
把報告發給老板
如果你是在替客戶或雇主修這個問題，用證據來收尾。改動生效後重新執行免費掃描，把評分報告轉發給企業負責人：語言直白、帶日期、PermError 已消失。這是他們在網路保險續保和下一份客戶安全問卷時需要的凭證——“我改了几條 DNS 記錄”和一份記錄在案的前後對比，區別就在這裡。
免費檢查你的網域
私密、僅網域所有者可見地看看你真實的、已解析的查詢次數——以及 SPF、DKIM 和 DMARC 的其他一切。
檢查你的網域 → · 修復 SPF → · SPF 在 SaaS 工具上失敗 → · 在 GoDaddy 上設定 SPF → · 我們如何評分 → · 僅使用彙總資料。資料在歐盟境內儲存和處理。