Google服务器的SPF记录是TXT还是SPF记录，或者是，还是两者皆有？

#1 楼

我意识到这是一个相当老的问题，但是如果有人偶然发现，这就是我的发现。看来SPF记录类型现在已过时。请参阅：


研究表明RRTYPE 99尚未有任何实质性用途，实际上，[RFC4408]中定义的它的存在和机制已经引起了一些互操作性问题。因此，它的使用现在已过时，并且新的实现方式不再使用它。


来自：https://tools.ietf.org/html/draft-ietf-spfbis-4408bis -15＃section-13.1

另请参阅cPanel的功能请求论坛上有关此主题的帖子。

#2 楼

请阅读RFC4408“类别：实验”的状态以及此状态的定义。

此外，来自RFC


公认的当前做法（使用TXT记录）不是最佳选择，但有必要，因为有许多常用的DNS服务器和解析器实现无法处理新的RR类型。


，毕竟，与TXT版本相比，SPF RR没有任何附加值

#3 楼

我会同时创建两者，因为您具有这种能力。完成后，您可以发送电子邮件至“ mailtest@unlocktheinbox.com”，它将自动响应并为您完整诊断您发送的电子邮件，让您知道所有设置是否正确。

#4 楼

根据satyenshah在2017年7月19日对本帖子的回复：


专用的type=SPF记录从未真正流行。使用``type = TXT记录''的发件人策略在2000年代初期建立得太好，以至于type=SPF记录无法在2010年代立足。您的权威DNS服务器可能支持发布SPF记录，但是仅查询TXT记录就可以满足Internet的MX服务器的要求。 。他们的管理员发现type=TXT记录是不必要的。

在大多数情况下，发布具有这两种记录类型的域的type=SPF策略都没有危害。有两个注意事项：


您需要勤奋地手动保持这两个记录同步。更新策略记录的一个副本时，必须记住要更新另一个。
根据您的DNS服务器，SPF查询可能在答复中同时包含type=ANY和TXT记录，从而使响应变大。
这本身有两个缺点。


首先，您更容易受到DNS放大/反射DDoS攻击的影响。其次，如果您域的ANY响应的大小徘徊在UDP / TCP之间的512字节阈值附近，那么您可能会遇到由RFC对DNS协议的含糊不清引起的错误。这很少见，但确实会发生。






网络工具信息提示框（如果您输入的域显示SPF记录）说：


有关不推荐使用的SPF记录的更多信息
主机名返回了不推荐使用的SPF记录

在2014年停止使用SPF的试验阶段先前支持的替代DNS RR类型。现在必须仅将SPF记录作为DNS TXT（类型16）资源记录（RR）[RFC1035]发布。有关此更改的更多详细信息，请参阅RFC7208。


根据RFC 7208第3.1节：在SPF开发期间，分配新DNS RR类型的要求比它们是今天，并且在DNS服务器和配置系统中尚未部署对新DNS RR类型的部署的支持。最终结果是SPF的开发人员发现遵循SPF的TXT RR类型更加容易和实用。




但是，我还读过一些人的报告，在添加SPF记录之前，他们在发送电子邮件时遇到了麻烦。

鉴于Google仅提供TXT记录，这很好地表明只有一个SPF条目才可以工作。

#5 楼

考虑到RFC发布已经7年了，我说任何仍在使用无法处理未知RR类型的DNS服务器的人基本上都是他们的问题，因为它们无法使软件保持最新。 （也考虑通过不升级，有多少已知的漏洞仍然容易受到攻击）。 RFC 4408表示，直到IANA发布7年前也发生过的SPT RRtype（类型99）之前，TXT RRtype的超载才是临时措施。

因此，我说TXT的使用用于SPF的RRtype早已过期。运行仅检查TXT类型的解析器的人已损坏。

我不同意SPF RRtype不会“增加价值”。它可以将机器可处理的数据保留为人类可读的DNS RRtype。