Defaults.Exposed › 报告
什么是 SPF 的 ptr 机制——为什么至今仍有 950,631 条记录在用它？（2026）
发布于 2026-07-03
数据截至 2026-06-29 · 方法论 v7。 对 261 百万个已评级域名的汇总普查。所有数据均为汇总统计——绝不涉及任何单个企业的记录。参见我们如何评级。
ptr 是一种 SPF 机制，它通过反向 DNS 查询来授权发件方——而 SPF 标准本身自 2014 年起就明确表示”不要使用它”。12 年后，仍有 950,631 个域名在发布它。 这意味着，在互联网上 139 百万条 SPF 记录中，大约每 146 条就有 1 条携带着一个在其中某些域名注册之前就已被规范弃用的机制。
ptr 本应做什么
ptr 的含义是：“接受来自任何反向 DNS 能解析回我域名的服务器的邮件。“这听起来很优雅——无需维护 IP 列表。但实际上，它要求接收方对连接的 IP 做一次反向查询，然后对返回的每一个主机名做正向确认。RFC 7208（§5.5）用直白的措辞将其弃用：该机制*“速度慢，在出现 DNS 错误时不如其他机制可靠，并且对 .arpa 域名服务器造成巨大的资源负担”*——并明确指出它**“不应被使用（SHOULD NOT be used）”**。
为什么它在 2026 年仍是一个陷阱
一个 12 年前就被弃用的机制，至今仍值得关注，有三个原因：
- 它消耗你的查询额度。 每个
ptr都会计入 SPF 每次校验最多 10 次 DNS 查询的硬性上限——一旦超出这个上限，整条记录就会因 PermError 而失效。一个什么可靠功能都不提供的机制，仍在占用你真正的include:机制所需的额度。 - 它会不可预测地失败。 反向 DNS 是大多数网络中维护最差的一个角落。当
ptr查询超时，或正向确认失败时，你的合法邮件就会失去它本指望的那个 SPF pass。 - 有些接收方干脆跳过它。 因为标准已将其弃用，一些实现直接忽略
ptr——所以它本该授权的那些发件方，从一开始就根本没有得到保护。
它从何而来
如今几乎没有人会主动选择 ptr。它是通过继承而来的：一份写于 2009 年的配置指南，一个从旧服务器配置里复制来的模板，一条历经三次托管迁移而原封不动的”能用”的记录。这正是我们的普查在每一个已弃用却仍存在的机制中所看到的模式：旧建议不会消亡，它只是被不断复制粘贴。 携带 ptr 的域名并非粗心大意——他们只是在遵循 12 年前就已退役的指示。
如何修复它——免费，五分钟
- 找到你的 SPF 记录（
dig TXT yourdomain.com，或免费检测）。 - 如果其中包含
ptr，弄清楚哪些服务器曾依赖它。 - 用精确的形式替换
ptr：对你自己控制的服务器使用ip4:/ip6:块，或使用你的服务商所记载的include:。 - 既然你已经在改，顺便确认记录以一个真正的限定符结尾——参见
~all与-all。
常见问题
SPF 记录中的 ptr 是什么意思？ 它会授权任何反向 DNS 能解析进你域名的服务器。RFC 7208 §5.5 在 2014 年以”慢且不可靠”为由将其弃用，并指出它不应被使用——然而截至 2026-06-29，仍有 950,631 个域名在发布它。
SPF 的 ptr 机制有任何时候是有效的吗？
它仍然能被解析，一些接收方也仍会评估它——但标准在所有情况下都建议不要使用它，一些接收方会忽略它，而且它会消耗你十次 DNS 查询中的一次。没有任何现代配置会让 ptr 成为正确答案。
我应该用什么来代替 ptr？
对你自己控制的服务器使用 ip4:/ip6: 块，或使用你服务商所记载的 include:。两者都是确定性的、快速的、可靠的——恰恰是 ptr 所不具备的一切。
ptr 会计入 SPF 的 10 次查询上限吗？
会——每个 ptr 至少会消耗接收方在放弃并返回 PermError 之前所执行的十次 DNS 查询中的一次。在一条已经堆满 include: 机制的记录上，这个失效的机制很可能就是把你推过上限的那一个。
检查你的记录里有没有”幽灵”
一个 12 年前就被弃用、却仍安坐在你 DNS 里的机制，正是那种没人会去主动排查的东西。而排查它只需半分钟。
检测你的域名 → · 修复 SPF → · 两条 SPF 记录 = 零条 → · SPF 成熟度模型 → · 仅为汇总数据。数据在欧盟境内存储和处理。