2

The SPF specification says:

The published SPF record for a given domain name SHOULD remain small enough that the results of a query for it will fit within 512 octets. Otherwise, there is a possibility of exceeding a DNS protocol limit.

Note that when computing the sizes for replies to queries of the TXT format, one has to take into account any other TXT records published at the domain name.

It also points out that more recent DNS specifications allow for larger UDP responses (the reason for the limitation, as the SPF spec implies you should not rely on DNS over TCP working), but that doesn't really seem to override the "SHOULD".

The problem is that so many organizations require TXT records on the same domain for verification purposes (things like facebook-domain-verification, google-site-verification, atlassian-domain-verification, adobe-sign-verification, etc.) and can quickly pump the size of the total TXT RRset well over 512 bytes.

It looks like the majority of big organizations are complying with this, but there are a few that go over:

% dig +noall +stats netflix.com TXT | grep 'MSG SIZE'
;; MSG SIZE  rcvd: 593

% dig +noall +stats linkedin.com TXT | grep 'MSG SIZE'
;; MSG SIZE  rcvd: 632

% dig +noall +stats twitter.com TXT | grep 'MSG SIZE'
;; MSG SIZE  rcvd: 642

% dig +noall +stats microsoft.com TXT | grep 'MSG SIZE'
;; MSG SIZE  rcvd: 1459

(You can see the potential truncation happening by running something like dig +notcp +noedns +ignore microsoft.com TXT.)

I've been right up against the edge for six months, and now I need to add another verification record for a new vendor that will push me well past 512 bytes. I've done as much as I can to consolidate my SPF record, and I've made sure that I can't remove existing verification records.

What should I do here? I can't not have the verification records, but I don't want to ignore the SPF spec, either. That said, Microsoft seems to be ignoring it, and I don't think they're getting their mail rejected.

  • 1
    I'm assuming you've made good use of the include or redirect functions? – Paul Jan 24 '20 at 1:42
  • Yeah. Unfortunately, SPF also dictates no more than 10 total DNS requests, and we have a number of includes to other vendors who send email on our behalf, and they also have their own includes, so I'm at the absolute limit there. (And hoping that those vendors don't add any new ones.) – wfaulk Jan 24 '20 at 18:46
  • 1
    Normally "verification" records may be needed just once, at the verification step and not later. It can be a burden to add/remove them on purpose, but maybe you do not need all of them all the time. – Patrick Mevzek Jan 24 '20 at 19:11
  • 2
    BTW your use case totally shows the error of having SPF using a TXT record instead its own SPF record type as planned at the beginning, and the fact of anchoring it at root, where under a _spf label it would have been fine. – Patrick Mevzek Jan 24 '20 at 19:12
  • 2
    Technically you are not violating anything. The RFC uses "SHOULD" which is formerly defined as "This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." I believe your analysis of the problem completely respects the "full implications must be understood and carefully weighed", and based on my understanding of your constraints I personally see no real other solutions (than going over 512 octets) – Patrick Mevzek Jan 24 '20 at 21:15
0

After rereading the SPF spec, the concern about the TXT RRset size is that DNS responses could be truncated if the client both does not support EDNS and the client does not support DNS over TCP. DNS over TCP has always been a required part of DNS, and the caveat seems to be concerned with broken DNS. (To be fair, there have been a lot of places where DNS over TCP was broken, especially in the past.)

But I know that my DNS servers are accessible via TCP, and I'm far less concerned with other people's actively broken DNS than I am with ensuring that they support a (relatively) new DNS spec.

So the answer seems to be that I have "valid reasons … to ignore [the] item, [and] the full implications [have been] understood and carefully weighed".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.