什么会消耗预算
RFC 7208 将 SPF 求值期间的 DNS 交互限制为 10 次。常见会触发查询的机制和修饰符包括 include、a、mx、ptr、exists 与 redirect。其中 include 的目标记录还会继续展开。
v=spf1 include:_spf.google.com include:mail.vendor.example -all
ip4、ip6 和 all 本身不需要 DNS 查询。记录字符数不是查询次数，删除空格或把记录拆成多个 TXT 片段也不会降低预算。
为什么超限会直接失败
接收方必须在达到限制后停止求值并返回永久错误。此时合法邮件也可能无法通过 SPF；如果 DKIM 或 DMARC 对齐同样失败，投递风险会进一步增加。
同一域名发布两条独立的 v=spf1 记录不会“分担”查询，反而会产生 SPF PermError。
修复顺序
- 列出当前仍在发送邮件的所有服务商和自有服务器。
- 删除已经停用的 include，不要只因为记录“以前就有”而保留。
- 逐层展开每个 include 与 redirect，统计最坏路径的潜在查询。
- 优先让服务商提供更精简的官方记录；不要盲目复制第三方 flatten 结果。
- 修改后再次扫描，并发送一封真实邮件检查 SPF 与 DMARC 对齐结果。
工具结果如何理解
本工具报告的是静态可见配置的潜在查询数。SPF 宏、运行时分支、临时 DNS 错误和接收方缓存可能让实际过程不同，因此接近 10 次时也应保留余量。