SPF 中的机制之一是ptr。该机制检查使用某个域名的发送者是否从指向该名称的子域的（前向确认的）IP 地址进行连接。
例如，当发送者[email protected]从 IP 地址 1.2.3.4 连接时，该ptr机制将首先对 1.2.3.4 进行反向查找。如果该查找返回的域名（例如mail.example.com）也具有 IP 地址 1.2.3.4，并且是 的子域example.com，则发送者是被授权的。
这似乎是一个有用的功能。在撰写本文时，该域名yahoo.com在其 SPF 记录中使用了此机制。
然而，SPF 规范明确不鼓励使用该ptr机制（'不应该被发布”[=使用在某些情况下可能是可以接受的，但必须经过仔细考虑]）。它给予以下解释：
注意：此机制速度慢，在 DNS 错误的情况下不如其他机制可靠，并且会给 .arpa 名称服务器带来很大负担。如果使用，则必须为域的主机设置适当的 PTR 记录，并且“ptr”机制应该是最后检查的机制之一。经过多年的 SPF 部署经验，我们得出结论，它是不必要的，应该使用更可靠的替代方案。
在我看来，这个解释似乎相当模糊，或者至少不足以完全放弃这个有用的功能。为什么这个机制“缓慢”或“不可靠”，它如何给名称服务器带来“巨大”的负担？在邮件服务器环境中进行一次额外的 DNS 查找肯定不是什么大问题？
是否有强有力的、实际的理由不使用ptr，或者是否有理由尽管有 RFC 文本但仍使用它？
答案1
我认为它很慢只是因为它需要多次查找才能处理；首先PTR基于连接 IP 地址进行查找，然后通过查找A或AAAA在结果中获得的名称来确认该响应PTR，以验证它是否真正匹配，然后再使用该PTR结果来决定 SPF 结果。
请记住，SPF 总是归结为指定允许的 IP 地址列表，收件人可以使用它来判断传入邮件是否由合法主机传递，因此理想的 SPF 机制是ip4/ ip6。
所有其他机制都只是间接的，为 SPF 发布者提供了一定程度的便利，但代价是电子邮件收件人的效率；这就是为什么这些间接查找限制为 10 次通过限制收件人验证收到的电子邮件的成本来强制实现某种平衡。
请注意，SPF 机制的特殊情况ptr是间接的，SPF 记录的发布者甚至不知道他们要求电子邮件收件人执行的查找顺序（因为初始查找基于连接的 IP 地址！）。在我看来，这给速度和可靠性带来了额外的问题。
至于.arpa名称服务器的负担，在邮件传递过程中引入更多查找的机制显然会增加负担，但与出于其他原因进行的所有其他反向查找相比，很难判断这在实践中可能造成多大的问题。
答案2
确实，上述问题ptr似乎微不足道。我想说，它们不太可能出现在邮件服务器设置的性能配置文件中。
然而，ptr与其他机制相比，有一个地方存在明显的缺点。第5.5款RFC 7208 规定：
如果在执行 PTR RR 查找时发生 DNS 错误，则此机制匹配失败。如果在执行 A RR 查找时发生 DNS 错误，则跳过该域名并继续搜索。
因此，类似下面的记录可能会被评估为失败=‘明确未授权！’当发生 DNS 错误时：
v=spf1 ptr -all
而对于其他机制，DNS错误将用临时失败结果，允许重试验证：
v=spf1 mx -all
对我来说，这是主要的问题ptr：即使查询刚刚遇到某些 DNS 超时，这种记录的结果也可能是明确的负面授权。
尽管如此，由于 RFC 要求（“必须”）ptr由兼容的实现支持，并且它只不鼓励使用它（“不应该”），仍然可以使用ptr，并且一旦考虑到权衡，就可能是可以接受的。