SPF PermError：SPF 的 10 次 DNS 查询限制

什么会消耗预算

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 对齐同样失败，投递风险会进一步增加。

修复顺序

1. 列出当前仍在发送邮件的所有服务商和自有服务器。
2. 删除已经停用的 include，不要只因为记录“以前就有”而保留。
3. 逐层展开每个 include 与 redirect，统计最坏路径的潜在查询。
4. 优先让服务商提供更精简的官方记录；不要盲目复制第三方 flatten 结果。
5. 修改后再次扫描，并发送一封真实邮件检查 SPF 与 DMARC 对齐结果。

工具结果如何理解

本工具报告的是静态可见配置的潜在查询数。SPF 宏、运行时分支、临时 DNS 错误和接收方缓存可能让实际过程不同，因此接近 10 次时也应保留余量。

宏 include 与字面授权检查不是同一事实

某些托管网关发布带运行时宏的策略，例如 include:%{ir}.%{v}.%{d}.spf.example。其中 %{i} 来自实际 SMTP 客户端 IP，%{v} 取决于 IP 版本，%{d} 是当前 SPF 求值域；缺少真实发送 IP、MAIL FROM 域和 HELO 上下文时，静态工具不能可靠展开最终查询名。

• 接收方报告 SPF pass，只能证明该次 SMTP 路径和身份通过了 SPF 求值。
• 产品界面检查是否存在某个固定 include:，验证的是另一项配置约束；一次 SPF pass 不能证明这个字面目标存在。
• 如果应用直接发往收件方，应确认应用的真实出口 IP受到当前 MAIL FROM 策略授权。
• 如果应用先中继到托管网关，应把“本机直发授权”和“网关最终发信授权”分开显示，避免把静态字面检查称为完整 SPF 失败。