Route 53 – Should I duplicate the SPF records as TXT records

amazon-route53domain-name-systemspf

Amazon Route 53 supports both "SPF Records" and "TXT Records". Most documentation I read tells me to list my SPF Record as a TXT Record. I understand that the SPF Record is a newer standard. Is it therefore correct for me to duplicate my SPF Records so they're listed as an SPF Records and a TXT Record to ensure backwards compatibility while also following the new standard? I'm unfamiliar with DNS so not sure if this would cause any problems or if I should even bother duplicating them?

My records are as follows:

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

Best Answer

It's not actually correct that the SPF RR type is the newer standard (in the context of desired SPF behavior). The experimental phase of the SPF specification had a new record type assigned but the migration path was unclear and it has since been abandoned.

The current version of the SPF spec specifically states:

SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only. The character content of the record is encoded as [US-ASCII]. Use of alternative DNS RR types was supported in SPF's experimental phase but has been discontinued.

In 2003, when SPF was first being developed, the requirements for
assignment of a new DNS RR type were considerably more stringent than they are now. Additionally, support for easy deployment of new DNS
RR types was not widely deployed in DNS servers and provisioning
systems. As a result, developers of SPF found it easier and more
practical to use the TXT RR type for SPF records.

In its review of [RFC4408], the SPFbis working group concluded that its dual RR type transition model was fundamentally flawed since it
contained no common RR type that implementers were required to serve
and required to check. Many alternatives were considered to resolve
this issue, but ultimately the working group concluded that
significant migration to the SPF RR type in the foreseeable future
was very unlikely and that the best solution for resolving this
interoperability issue was to drop support for the SPF RR type from
SPF version 1. See Appendix A of [RFC6686] for further information.

The circumstances surrounding SPF's initial deployment a decade ago are unique. If a future update to SPF were developed that did not
reuse existing SPF records, it could use the SPF RR type. SPF's use
of the TXT RR type for structured data should in no way be taken as
precedent for future protocol designers. Further discussion of
design considerations when using new DNS RR types can be found in
[RFC5507].


As a sidenote, there was also a Sender ID record (unfortunately referred to as "spf2.0" despite it being a different spec) in your example, the rules for that type of record are still experimental and [match the experimental version of the SPF spec](https://tools.ietf.org/html/rfc4406#section-4.3), no updates have been published.
Related Topic