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.
Best Answer
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".