SPF 只有两个 include 却超出查询限制：检查递归展开后的预算

域名的 SPF 记录看起来很短，只有两个 include，检查工具却提示 Too many DNS lookups，部分发信还出现 spf=permerror。应继续查看被包含域名的 SPF：一层 include 可以再包含多层规则，查询预算不会在进入另一个域名时重新开始。

以下针对 RFC 7208 的 SPF 规则。检查工具展开整个配置后发现超过预算，说明有风险；某一封邮件是否真的超限，还取决于它的来源 IP 和实际走到的规则。不要把工具给出的展开总数直接当成每封邮件都已执行的次数。

先确认查的是实际发信身份

SPF 通常检查 SMTP 的 MAIL FROM 域名；空反向路径等场景还涉及 HELO 身份。邮件里读者看到的 From 地址，并不总是 SPF 使用的域名。先从可信收信系统的认证结果和发信服务配置中确定检查对象，再查询该域名：

dig example.com TXT

这里的 example.com 需要替换为实际被检查的域名。普通 TXT 记录可以有多条，但同一被检查域名出现多条以 v=spf1 开头的 SPF 记录，会引发另一种 permerror。把授权服务拆成两条 SPF 记录，不能增加可用预算。

一条 TXT 记录可以包含多个字符串，SPF 解析时将它们直接连接，中间不会自动加空格。修改 DNS 控制台中的分段时，也要确认拼接后的规则仍然有效。

十次限制按哪些规则计算

SPF 对一次检查过程中会引发 DNS 查询的规则项设置十次上限，包括 include、a、mx、ptr、exists 和 redirect。递归包含与重定向共用这份预算。ip4、ip6、all 和 exp 不占这项十次预算；这不表示它们没有其他语法或使用限制。

这里统计的是规定的规则项，不能拿抓包里的 DNS 请求数、是否命中缓存，或顶层 TXT 查询次数代替。mx 的地址查询和没有有效结果的查询，还各有相应限制，不能只核对一个总数。

例如下面这条记录只是结构示例，不是可直接采用的配置：

v=spf1 include:_spf.service-a.example include:_spf.service-b.example -all

顶层有两个 include，但需要继续读取这两个域名，记录它们内部的包含、重定向及其他占用预算的规则。遇到服务商自己的聚合域名，还要按实际展开情况继续向下检查，不能只数第一行的关键字。

SPF 按顺序评价规则，匹配成功后可以提前结束。因此，一个靠前命中的发信来源可能通过，走到后面分支的来源却超限。记录本身的语法错误又有独立的处理规则，不能以“那段平常走不到”为理由保留无效语法。

按真实发信服务减少重复授权

列出仍在使用的邮件服务，并核对每个包含项的用途。某个聚合记录已经授权了另一项相同服务时，确认服务商当前要求和实际发信范围后，才考虑去掉重复项。已停用的营销平台、旧网关和迁移残留，也应在确认不再发信后撤销。

不要仅凭域名长得相似就删除其中一个。有的服务按地区、产品或发信集群使用不同授权，漏掉一项会让对应业务从通过变成失败。改动前保存完整记录与业务清单，安排可核对每类发信的变更窗口。

若不同业务可以采用独立的 MAIL FROM 子域名，可以分别配置各自需要的 SPF，减少每次检查涉及的服务数量。只改邮件显示的 From 地址不会完成这项迁移；还需要发信平台支持该身份，并检查已有的其他邮件认证策略。

展平成 IP 地址需要持续维护

将包含项换成 ip4 或 ip6 可以减少这项查询预算，但服务商的发信地址可能变化。手工复制某一天解析出的地址后长期不更新，会遗漏新地址；过度扩大网段又可能授权不应代表你发信的主机。

只有能持续获取权威地址范围、更新记录并检查变化时，才考虑这种做法。使用托管展开服务，也要了解地址更新、失效处理和回退方式。不要为了让检查工具显示绿色，随意删除授权、采用 +all，或更改原有的拒绝策略。

发布后分别检查每类邮件

确认实际生效的 TXT 记录只有一份 SPF，语法和字符串拼接正确，再按不同发信服务的实际来源检查评价路径与剩余预算。DNS 缓存尚未更新的收信方可能继续使用旧记录，应结合变更前的 TTL 和观察时间判断。

用各类仍在使用的业务发送受控邮件，核对可信收信系统对实际 MAIL FROM 身份给出的 SPF 结果。某一类邮件通过，不能证明所有包含分支都通过；SPF 通过本身也不等于其他邮件认证或投递结果都正常。

若删减授权后特定业务失败，恢复保存的记录并等待缓存按实际 TTL 更新，再重新核对遗漏的发信范围。恢复 DNS 不会重新投递已被拒收的邮件，是否重发应依据业务记录处理。