路线53-我应该将SPF记录复制为TXT记录吗？

Amazon Route 53支持“ SPF记录”和“ TXT记录”。我阅读的大多数文档都告诉我将我的SPF记录列为TXT记录。我知道SPF记录是一个较新的标准。因此，对我来说，重复我的SPF记录是否正确，以便将它们列为SPF记录和TXT记录，以确保向后兼容并同时遵循新标准？我不熟悉DNS，所以不确定这是否会导致任何问题，或者我是否应该重复复制它们？

我的记录如下：

"v=spf1 include:_spf.google.com include:amazonses.com -all"
"spf2.0/pra include:_spf.google.com include:amazonses.com -all"

SPFRR类型是较新的标准实际上是不正确的（在所需的SPF行为的上下文中）。SPF规范的实验阶段已分配了新的记录类型，但迁移路径尚不清楚，因此已被放弃。

SPF规范的当前版本特别声明：

SPF记录必须被发布为DNS TXT（16型）资源记录 （RR）[RFC1035] 只。记录的字符内容编码为[US-ASCII]。SPF的实验阶段支持使用替代DNS RR类型，但已停止使用。

在2003年SPF首次开发时，
分配新DNS RR类型的要求比现在要严格得多。此外，
在DNS服务器和预配
系统中并未广泛部署对轻松部署新DNS RR类型的支持。结果，SPF的开发人员发现
将TXT RR类型用于SPF记录更加容易和实用。

SPFbis工作组在对[RFC4408]的审查中得出的结论是，其双重RR类型转换模型从根本上是有缺陷的，因为它不
包含实施者需要服务
和检查的通用RR类型。考虑了许多替代方案来解决
此问题，但最终工作组得出结论，
在可预见的将来
不太可能向SPF RR类型进行重大迁移，并且解决此
互操作性问题的最佳解决方案是放弃对SPF RR类型的支持。
SPF版本1。有关更多信息，请参见[RFC6686]的附录A。

围绕SPF十年前的初始部署的情况是独一无二的。如果开发的SPF将来更新不
重用现有SPF记录，则可以使用SPF RR类型。SPF
对结构化数据使用TXT RR类型的方法绝不应作为
未来协议设计者的先例。
在使用新的DNS RR类型时，有关设计注意事项的进一步讨论可以在
[RFC5507]中找到。

附带说明一下，在您的示例中，也有一个发件人ID记录（尽管它是一个不同的规范，但不幸的是被称为“ spf2.0”），该记录类型的规则仍处于实验阶段，并且与SPF的实验版本匹配spec，尚未发布任何更新。

是的，复制它们；我暂时不知道有多少比例的SPF检查员实际上支持记录类型的当前标准，但是如果我做出一个疯狂的猜测，我敢打赌，大概10％的检查员不会看SPF记录TXT。