Defaults.Exposed › 報告
SPF PermError 報告：突破 10 次查詢上限的域名數量，是表面統計所顯示的 100 倍（2026）
發布於 2026-07-03
數據截至 2026-06-29 · 方法論 v7，另加一次於 2026-07-03 運行的鏈條定價掃描。 我們從 261 百萬個已評級域名的普查中，解析了每一個被引用 100 次及以上的 SPF
include:目標——共 10,842 個目標，覆蓋全部 include 引用的 95.2%——並根據這張圖譜為每個域名保留的鏈條定價。未解析的尾部目標計為零，且鏈條內容反映的是解析當天的狀態，因此這個頭條數字是一個保守的、偏向下限的近似值：所以我們說「至少」。僅為彙總數據；絕不涉及某個具體企業的記錄。參見我們如何評級。
有多少域名突破了 SPF 的 10 次查詢上限？
至少 797,263 個——因為 SPF 在標準中內置了一顆自毀裝置，而其觸發點恰好隱藏在域名所有者看不到的地方。 RFC 7208 §4.6.4 將一次 SPF 檢查的上限設為 10 次 DNS 查詢；一旦超過十次，接收方就會停止並返回 PermError，而一條 PermError 記錄什麼都保護不了。如果只統計記錄本身可見的查詢次數——大多數工具都是這麼做的，我們自己的普查在本報告之前也是如此——你會發現大約 8000 個違規域名（精確來說是 7,958 個）。但如果把這些記錄實際拉取進來的 include: 鏈條也定價，數字就會達到 797,263：大約是前者的 100 倍。
為什麼所有者預見不到？
因為查詢預算是被別人的記錄花掉的。include:onetool.example.com 在你的 DNS 面板裡只是一行——但接收方也必須去獲取那條記錄，並遞歸地統計它所包含的每一個查詢機制。一條帶有三個 include 的記錄可能就要耗費十一次查詢。你越過界線的那一天，你自己的區域裡什麼都沒變；只是某個服務商多嵌套了一個 include，你的 SPF 就毫無預警地失效了。
更糟的是，DMARC 將 PermError 視為 SPF 環節的失敗——所以一個以這種方式弄壞自己 SPF 的域名，如今正在其自身認證中失敗一半。
鏈條定價發現了什麼
| 發現 | 域名數 |
|---|---|
| 超過 10 次查詢上限，鏈條已定價 | 797,263 |
| 僅統計可見機制時超過上限 | 7,958 |
以嚴格 -all 結尾卻仍超過上限 | 112,215 |
| 恰好處於 9–10 次查詢——懸崖邊緣 | 2,119,539 |
這張表裡藏著兩個故事——第三個，也就是懸崖邊緣，會在下面單獨成節：
- 表面統計漏掉了約 99% 的失效情況。 可見機制的統計得出 7,958 個；對鏈條定價則得出 797,263 個。幾乎所有的損害都是從 include 所包含的內容裡繼承來的。
- 112,215 條失效記錄以
-all結尾。 它們的所有者一切都做對了——攀上了那堵牆、選擇了嚴格的結尾——卻因為多了一個 include 而讓整條記錄作廢。看似嚴格卻已失效，是電子郵件安全中最殘酷的失敗方式。
2.1 百萬個域名，離懸崖只差一個工具
真正應該讓目前一切正常的讀者擔憂的數字是：2,119,539 個域名解析下來恰好是 9 或 10 次查詢——今天還在上限之內，只要有人再接入一個平台，明天就報廢了。這大約佔所有 SPF 發佈者的 66 分之一，而且與整個分佈的形態吻合：處於第 99 百分位的 SPF 記錄已經達到 9 次查詢。再註冊一個營銷工具，粘貼上它那句「只要加上這個 include」，一條早餐時還在上限之內的記錄，到午飯時就作廢了。
這是誰的錯？越來越是整個技術棧的錯
最大的那些服務商已經悄悄扁平化了他們的 SPF——Google 的 _spf.google.com 和 Microsoft 的 spf.protection.outlook.com 如今都展開成純 IP 列表，內部查詢成本為零（在本次分析中，我們對照實時 DNS 核實了這兩者）。問題出在別處：嵌套三層深的託管面板鏈條、單單一個 include 就要花掉 7–10 次查詢的區域性服務商，以及 SaaS 那種老實巴交的累積——郵箱加訂閱郵件加 CRM 加工單系統，每個都只是「加一個 include」而已。幾乎沒人是故意添上那第十一次查詢的。它是作為一連串合理決定的總和悄然到來的。
如何免費檢查並修復你自己的記錄
- 算出你真正的總數——我們的免費檢查會解析你的鏈條，或者用任何一款 SPF 查詢計數器。
- 削減無用負擔：不再使用的工具、重複的 include，以及已棄用的
ptr機制。 - 只扁平化你能掌控的部分。 用 IP 段替換一個深層 include，對你自己的基礎設施是可行的；第三方 IP 卻會毫無通知地變更。
- 給批量發信者一個子域名。 來自
news.yourdomain.com的訂閱郵件會獲得自己的記錄和自己獨立的 10 次查詢預算。
常見問題
什麼是 SPF 的 10 次 DNS 查詢上限？
RFC 7208 §4.6.4 規定，評估一條 SPF 記錄最多允許 10 次 DNS 查詢——這要遞歸地計入每一個 include: 內部的查詢。超過就會返回 PermError：該記錄被視為無效，不提供任何保護。
SPF PermError 是什麼意思？ 這是一種永久性評估錯誤——接收方無法處理你的記錄（查詢次數過多、存在多條記錄，或語法有誤），於是把你的域名當作沒有可用的 SPF。DMARC 會將其計為 SPF 環節的失敗。
有多少域名超過了 SPF 查詢上限？ 根據我們的鏈條定價掃描，在 139 百萬個 SPF 發佈者中，至少有 797,263 個——約為不解析鏈條即可見的那 7,958 個的 100 倍。此外還有 2,119,539 個域名處於 9–10 次查詢，離上限只差一個 include。
PermError 會阻止我的郵件被投遞嗎？ 通常不會——接收方會在沒有 SPF 的情況下繼續處理，你的郵件靠 DKIM 和信譽過關。停止運作的是保護：偽造者不再被拒收，而且你郵件的每一次 DMARC 檢查都會丟掉它的 SPF 環節。它是隱形的，直到它變得代價高昂。
我該如何減少自己的 SPF 查詢次數？
刪除不用的 include 和 ptr，把你自己的基礎設施扁平化為 ip4:/ip6:，將批量發信者遷移到子域名，並在每次接入新工具後重新計數。修復指南會帶你一步步操作。
查出你真正的數字
你能看到的那些機制並不是你的查詢次數——解析出來的數字才是接收方計算的那個，而這只是一次 30 秒的檢查。
檢查你的域名 → · 修復 SPF → · SPF 成熟度模型 → · 兩條 SPF 記錄 = 沒有記錄 → · ptr 陷阱 → · 僅為彙總數據。數據在歐盟境內存儲和處理。