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
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.