Route 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
RR 類型的支持並未廣泛部署在 DNS 伺服器和供應
系統中。結果，SPF 的開發人員發現
將 TXT RR 類型用於 SPF 記錄更容易、更實用。
在其審查
$$ RFC4408 $$，SPFbis 工作組得出的結論是，其雙重 RR 類型轉換模型存在根本缺陷，因為它
不包含實施者需要服務
和檢查的通用 RR 類型。考慮了許多替代方案來解決
此問題，但最終工作組得出結論，在可預見的將來 不太可能
大量遷移到 SPF RR 類型，解決此 互操作性問題的最佳解決方案是放棄對 SPF RR 類型的支持 SPF 版本 1。見附錄 A
$$ RFC6686 $$了解更多資訊。 十年前 SPF 最初部署的情況是獨一無二的。如果將來開發了不
重用現有 SPF 記錄的 SPF 更新，則可以使用 SPF RR 類型。SPF
將 TXT RR 類型用於結構化數據絕不應被視為
未來協議設計者的先例。
有關使用新 DNS RR 類型時的設計注意事項的進一步討論，請參見
$$ RFC5507 $$.
作為旁注，在您的範例中還有一個發件人 ID 記錄（不幸的是，儘管它是不同的規範，但被稱為“spf2.0”），該類型記錄的規則仍然是實驗性的，並且$$ match the experimental version of the SPF spec $$（https://tools.ietf.org/html/rfc4406#section-4.3），沒有發布更新。