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 → · 我们如何评分 → · 仅使用汇总数据。数据在欧盟境内存储和处理。