SPF and the 255-character limit: strings and splitting

example.com.  IN  TXT  ( "v=spf1 ip4:192.0.2.0/28 ip4:198.51.100.0/26 include:_spf.google.com "
                         "include:spf.protection.outlook.com include:sendgrid.net ~all" )

Where it breaks: DNS interfaces and copy-paste

Faced with a value longer than 255 characters, DNS hosts' interfaces fall into three families. The first refuses outright: an explicit error message, and the value is not saved. Annoying but healthy — the failure is visible and gets fixed within a minute by splitting manually. The second family splits automatically: the interface accepts the long value and segments it into compliant strings when generating the zone. Cloudflare works this way, and it is the ideal behaviour: the value is pasted in one block, and resolvers receive a correct record.

The third family is the dangerous one: interfaces that truncate or corrupt silently. A form field carrying an invisible maxlength amputates the pasted value at the 255th character, often right in the middle of a mechanism — the published record then ends with include:_spf.example- followed by nothing. The result: a syntactically invalid SPF, permerror on every check. Under DMARC, an SPF permerror amounts to having no SPF at all: the whole authentication then rests on DKIM, and flows that only carry SPF — some line-of-business tools, ageing application servers — simply fail.

Copy-paste adds its own layer of traps: a line break inserted by a mail client or a word processor, typographic quotation marks substituted for straight quotes by an autocorrect feature, an interface that expects the bare value and stores the quotes as literal characters. None of these corruptions raises any alert at input time; they only reveal themselves through external verification, once the record has propagated — hence the dig reflex detailed further down.

Answer size: UDP, EDNS and robustness

The per-string limit is not the only reason to watch an SPF record's waistline. DNS has historically carried its answers over UDP, with a 512-byte-per-message ceiling inherited from RFC 1035. The EDNS0 extension raised that ceiling — most resolvers now advertise 1,232 bytes, the value recommended since the 2020 DNS Flag Day — but the fallback mechanism has not changed: an oversized answer is flagged as truncated (the TC bit), and the client must retry over TCP. Old firewalls, however, still block port 53 over TCP, and some middleboxes mistreat large UDP packets. A bloated answer then becomes a lost answer: the verifier returns temperror, and the legitimate message is deferred, or evaluated without authentication.

One detail makes the arithmetic worse: a TXT query returns all TXT records at the name, not just the SPF one. Verification tokens piled up over the years — google-site-verification=…, MS=…, validations for long-forgotten SaaS tools — share the same answer and inflate its size. A 300-byte SPF inside an answer already carrying 600 bytes of tokens crosses the threshold much sooner than expected. RFC 7208 explicitly recommends keeping the answer modest in size: robustness argues for concision, even when multi-string splitting makes the length perfectly "legal".

Slimming down a bloated SPF record

Before splitting, shortening is the better move. A bloated SPF is almost always a sedimented SPF: years of additions, never a removal. The clean-up follows a logical order.

• Dead mechanisms. The ESP abandoned two years ago, the decommissioned server, the agency whose contract ended: their include: and ip4: entries linger in the record. DMARC reports settle the question — a source absent from the reports for months can go.
• Redundancies. An ip4: pointing at an address already covered by an include:, two include: entries for the same provider under different names, an mx mechanism when the inbound servers never send anything: all free bytes.
• CIDR aggregation. Four contiguous addresses listed one by one (ip4:192.0.2.16 ip4:192.0.2.17 ip4:192.0.2.18 ip4:192.0.2.19) compress into a single block, ip4:192.0.2.16/30. On wider ranges, the savings run to dozens of bytes.
• The ptr mechanism. Discouraged by RFC 7208 itself, expensive and unreliable: its place is in the archives, not in the record.
• Delegation by subdomain. The most powerful lever: the newsletter leaves from news.example.com, invoicing from billing.example.com, each with its own short SPF. The main domain only carries its own flows, and every record gets room to breathe.

Two neighbouring techniques deserve a pointer rather than a treatment here. Flattening — replacing the include: entries with their resolved IP addresses — reduces DNS lookups but lengthens the record, which is the exact opposite of this page's goal; its promises and pitfalls are examined in SPF flattening and why it disappoints. As for the RFC 7208 macros, capable of radically compacting certain use cases, they have an article of their own: SPF macros and the exists mechanism.

255 characters and 10 lookups: two limits with nothing in common

The 255-character limit is regularly confused with SPF's other famous ceiling: the ten mechanisms that trigger a DNS query (include, a, mx, ptr, exists, plus the redirect modifier). Yet the two share nothing. The first is a DNS encoding constraint: it is measured in bytes and is cleanly worked around by splitting into strings. The second is a rule of SPF itself: it is counted in DNS resolutions and ends in a normative permerror from the eleventh query onward.

The confusion arises because both hit the same victims — records that grew without supervision — but the remedies diverge, and sometimes clash head-on. Flattening cures the lookups while worsening the size; multi-string splitting cures the size without removing a single query. A very short record can blow through the query ceiling (three nested include: entries are enough), while a 350-byte record made only of ip4: mechanisms consumes no lookup at all. Identifying which of the two ceilings is actually the problem is therefore the prerequisite to any fix — the ten-DNS-query ceiling has its own field guide, worth reading before touching anything.

Verification: dig, quotation marks and counting

Verification requires nothing more than dig, present on any Unix machine (or nslookup -type=TXT on Windows):

$ dig +short TXT example.com
"v=spf1 ip4:192.0.2.0/28 include:_spf.google.com " "include:sendgrid.net ~all"
"google-site-verification=kX3v…"

The output tells the whole story. Each pair of quotation marks materialises one string: two pairs on the SPF line mean the record is split and that the split survived the host's interface. The junction space can be checked by eye — here, at the end of the first string. The global count fits in one command:

$ dig +short TXT example.com | grep spf1 | wc -c

What matters is not the total but the distribution: each individual string must stay under 255 bytes, which the presence of multiple quoted strings demonstrates at a glance. Three reflexes complete the toolkit: checking after propagation (the old record's TTL can mask the change for hours), querying a public resolver (@1.1.1.1, @9.9.9.9) rather than the local cache, and watching the DMARC reports over the following days — a truncation permerror shows up there in black and white, where the DNS interface will never display anything.

In summary

SPF's "255-character limit" is in reality a DNS rule: 255 bytes per character-string of a TXT record, never per record. A long SPF remains compliant as long as it is split into several strings that the verifier concatenates without adding spaces; the real breakage comes from interfaces that truncate silently, from corrupted copy-paste, and from DNS answers grown too large for UDP. The right order of operations: slim down first (dead mechanisms, redundancies, CIDR aggregation, dedicated subdomains), split afterwards if still needed, always verify with dig — and never confuse this byte limit with the ten-DNS-query ceiling, which obeys different laws and calls for different remedies.

To find out in seconds whether a domain's record is brushing against the limit, is cleanly split, or is dragging dead bytes around, a free DMARC analysis shows the state of SPF alongside DKIM and the DMARC policy, split included. And to track over time what the reports say about the domain's real sending sources, creating an account opens up continuous monitoring — the 255-byte limit, for its part, is not going anywhere.