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 陷阱 → · 仅为汇总数据。数据在欧盟境内存储和处理。