SPF Record Over 255 Characters: 3 Real Fixes (Flattening, Splitting & Compression)

Published September 21, 2026 · 5 min read · spFlat!

A single DNS TXT character-string cannot exceed 255 octets. That is a DNS encoding limit (RFC 1035), not an SPF invention. When you flatten several providers into ip4:/ip6: ranges on your own domain, you hit it fast - often faster than the 10-lookup limit.

The 255-octet cap is widely misunderstood. RFC 7208 does not forbid splitting a long value. It forbids something else, and the practical ceiling is larger than 255 characters. Here is what actually breaks, and the 3 fixes that match the spec.

What the 255-character limit actually is

A DNS TXT record is stored as one or more character-strings. Each string is max 255 octets. RFC 7208 §3.3 says that if one TXT record contains multiple strings, receivers MUST concatenate them without adding spaces. That is how you legally publish an SPF policy longer than 255 characters.

Amazon SES already does this on amazonses.com: one TXT record, two quoted strings, concatenated into a single v=spf1 … -all policy. Microsoft's current Outlook SPF is ~248 characters on its own. Google's is ~192. Paste both plus SendGrid as raw CIDRs onto your domain and you are well past 255 and past a comfortable UDP DNS answer.

Two different mistakes get lumped together as "too long":

• Two (or more) v=spf1 TXT records at the same name - RFC 7208 §3.2 makes that a PermError. Some DNS panels split a long paste into a second record. That is the dangerous split.
• One TXT record, multiple strings - allowed. The risk is the panel, not the RFC: missing spaces on concatenate, or the whole answer growing past the ~450-octet / 512-byte UDP guideline in §3.4.

Fix 1: Multiple strings in one TXT record (valid - easy to get wrong)

RFC 7208's intended way past 255 octets per string is quoted chunks inside a single TXT record:

"v=spf1 include:_spf.google.com include:spf.protection.outlook.com "
"include:sendgrid.net include:mailgun.org ~all"

Receivers join those strings with no extra space. Put the space at the end of the first chunk (as above) or you glue tokens together and get a syntax error. Route 53, Cloudflare and others document this quoting; Amazon SES's public record is a live example.

This solves the per-string cap. It does not shrink the DNS answer, so it will not save you from UDP truncation. And if your panel creates a second TXT record instead of a second string, you get PermError. Check the wire with dig TXT after you publish.

Fix 2: Compress the record (quick win, not always enough)

You can often shave characters without changing meaning:

• Remove redirect= or redundant mechanisms if present
• Drop ip4:/ip6: entries that are already covered by an include
• Remove duplicate entries (e.g. an ip4: that's also inside an include)

This buys you room, but only delays the problem - every new provider pushes you back toward both limits.

Fix 3: Hosted flattening (the fix that stays short and under 10 lookups)

Dumping every resolved CIDR onto your own domain usually makes the TXT longer, not shorter. The record that stays small is one include pointing at a flattening service:

Before (several includes, nested lookups, or a huge IP list):

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:mailgun.org ~all

After hosted flattening (one lookup on your domain):

v=spf1 include:_yourdomain.spf.spflat.cloud ~all

Receivers do one include lookup. The long IP list lives on the flattening hostname, where it can be split into legal TXT strings and kept current. Your published record stays well under 255 characters and under 10 lookups.

The bottom line

1. Multiple strings in one TXT - RFC-correct for the 255-octet string cap. Confirm you did not publish two SPF records, and watch UDP size.
2. Compression - fine as a stopgap, but it doesn't scale.
3. Hosted flattening with SPFlat! - the durable fix: one short include on your domain, lookups and size handled behind it. Free checker, then a 14-day trial.

Check your domain on spflat.cloud - see the live lookup count (and the 10-lookup PermError), and whether one more provider would break evaluation.