这 SPF ptr 机制是一种通过验证来授权连接主机的传统方法 反向DNS。目前的SPF指南表示不应发布该指南，因为该指南速度缓慢、在某些 DNS 错误情况下不可靠且操作繁重。它仍然是协议的一部分，合规评估者必须支持它。
这种区别很重要：不鼓励并不意味着普遍被忽视或自动无效。在不识别依赖它的发件人的情况下删除它可能会改变真实的身份验证结果。 RFC 7208第 5.5 节 提供了相关指导。
了解被替换的权限
从概念上讲，ptr 从连接地址的反向查找开始。然后，它向前解析返回的名称以验证它们是否指向连接地址。经过验证的名称必须与目标域匹配或位于其域边界内，以便机制进行匹配。
这不仅仅是检查主机名是否包含熟悉的字符串。诸如relay.example.com之类的名称位于example.com内； relay.notexample.com不是。仅反向答案也是不够的：前向验证很重要。
反向DNS通常由地址所有者而不是编辑SPF组织管理。当策略依赖于所选域下的主机名时，这会产生额外的管理依赖性。
走一个综合遗留示例
假设example.com发布 v=spf1 ptr:example.com -all。连接来自192.0.2.55 。它的反向答案是outbound.example.com ，并且该名称的 A 答案包括192.0.2.55 。在此简化的装置中，经过验证的名称位于example.com内，因此 ptr 匹配。
如果转发地址是192.0.2.99 ，则不会验证连接地址的反向名称。如果没有其他经过验证的名称符合条件，则 ptr 不匹配并且策略达到-all 。同样，目标域之外的经过验证的名称并不能仅仅因为看起来相似而合格。
这些是合成输入的预期协议结果，而不是来自生产领域的观察结果。真实评估还应用查找和处理限制，包括反向和正向工作的界限。
不要混淆两个反向 DNS 决策
从SPF中删除ptr机制并不意味着删除服务器的PTR记录。反向DNS可能仍然与SMTP操作、接收者要求和独立于SPF信誉检查相关。主机可以拥有适当的反向DNS同时其SPF策略使用 ip4、ip6 或已记录的提供程序包括。
保持迁移范围狭窄。替换授权机制并保留其他工作DNS设置，除非单独的、合理的更改需要它们。
从观察到的发件人中选择替代者
对于您控制下的专用稳定出口，显式 ip4 和 ip6 权限使预期地址可见。对于具有托管变更基础设施的服务，请使用其记录的SPF配置，而不是重建提供商主机名规则。
这 一种机制 当专门控制的主机名旨在定义发送地址时，可能是合适的。它并不是 ptr 的自动最佳替代品：它更改了权限模型并创建了自己的转发 DNS 依赖项。
建立当前通过 ptr 的地址清单并获取所有权证据。包括故障转移、 IPv6和不频繁流量。不要收集一些最近的地址并声称您已经建立了完整的权限集。
迁移时不隐藏不确定性
创建授权已验证合法路由的建议策略。评估该集的新旧策略以及未经授权的控制。检查是否有新的授权范围比旧的授权范围更广，以及未知的发件人是否仍未得到解决。
保留先前的记录并定义与合法工作流程失败相关的回滚条件。通过正常的变更控制进行发布、检查DNS答案并验证代表收到的消息。如果合法发件人失败，请在添加权限之前确认其身份和所有权。
实用的外卖
使用有关真实发件人的证据，淘汰 ptr 作为SPF授权机制。保留必要的反向DNS ，并用显式的、可维护的权限模型替换隐藏的主机名依赖项。
记录下一个决定
对于合成遗留源，分别保留反向答案、正向答案、验证名称和目标边界比较。然后将建议的替换与已知、故障转移和不常见的来源以及未经授权的控制进行比较。如果一个发件人的所有权仍然未知，请记录该差距，而不是默默地扩大差距 CIDR。此审核未执行PTR查询或迁移。