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"
答案1
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 记录更简单、更实用。在审查 [RFC4408] 时，SPFbis 工作组得出结论，其双 RR 类型转换模型存在根本缺陷，因为它
不包含实施者必须遵守
和检查的通用 RR 类型。为解决
此问题，工作组考虑了许多替代方案，但最终得出结论，
在可预见的未来大规模迁移到 SPF RR 类型的
可能性很小，解决此
互操作性问题的最佳解决方案是从 SPF 版本 1 开始放弃对 SPF RR 类型的支持。
有关更多信息，请参阅 [RFC6686] 的附录 A。十年前 SPF 首次部署的情况非常独特。如果未来开发的 SPF 更新不重复
使用现有 SPF 记录，则可以使用 SPF RR 类型。SPF
对结构化数据使用 TXT RR 类型绝不应成为
未来协议设计者的先例。有关使用新 DNS RR 类型时的设计注意事项的进一步讨论，
请参阅
[RFC5507]。
附注：您的示例中还有一个发件人 ID 记录（不幸的是，尽管它是不同的规范，但被称为“spf2.0”），该类型记录的规则仍处于实验阶段，并且 [与 SPF 规范的实验版本相匹配](https://tools.ietf.org/html/rfc4406#section-4.3)，尚未发布任何更新。
答案2
是的，复制它们；我不知道有多少比例的 SPF 检查器实际上支持当前的记录类型标准，但如果我大胆猜测的话，我敢打赌，可能有 10% 的检查器不会查看记录SPF，只会TXT。