Home / server / Questions / 682467
Accepted
Sean Bannister
Asked: 2015-04-14 15:39:32 +0800 CST

Route 53 - Should I duplicate my SPF records as TXT records?

  • 772

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"
domain-name-system

2 Answers

  1. 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.
    • 15

  2. Yes, duplicate them; I don't know offhand what ratio of SPF checkers actually support the current standard for record type, but if I were to make a wild guess I'd wager that probably 10% of checkers won't look at an SPF record, only TXT.

    • 3