Fix an SPF record that’s too long (over 255 characters)

What the error means

You see it when you save the record: a DNS panel that says the TXT value is too long, or Amazon Route 53’s:

CharacterStringTooLong (Value is too long) encountered with {Value}

The limit comes from DNS itself, not from SPF. RFC 1035 §3.3 defines the strings a TXT record is made of: “<character-string> is a single length octet followed by that number of characters.” One length octet counts to 255, so one string holds 255 characters at most. A TXT record can hold several strings, and SPF is written for that. RFC 7208 §3.3:

• How receivers read it: “If a published record contains multiple character-strings, then the record MUST be treated as if those strings are concatenated together without adding spaces.”
• Why: “TXT records containing multiple strings are useful in constructing records that would exceed the 255-octet maximum length of a character-string within a single TXT record.”

So the fix for “too long” is to split the value into strings of 255 characters or fewer inside the same record. Route 53’s documentation puts it this way: “If you need to enter a value longer than 255 characters, break the value into strings of 255 characters or fewer, and enclose each string in double quotation marks ( " ).” Google Workspace’s SPF help says “SPF records can have up to 255 characters. The TXT record file size should be no larger than 512 bytes.” Read the 255 as per string: RFC 7208 §3.3 lets one record hold several strings (see the FAQ below). Splitting keeps the record within the standard; a record that also fits in fewer characters is easier to manage, so shorten it where you can (see below).

“SPF too long” sometimes means something else: more than 10 DNS lookups. That limit counts include, a, mx and similar terms, not characters, and splitting doesn’t change it. See fixing too many DNS lookups.

Sources: RFC 1035 §3.3 and §3.3.14; RFC 7208 §3.1, §3.3, §3.4, §4.5, §4.6, §4.7 and §5.2; Amazon Route 53 Developer Guide, Supported DNS record types (TXT); AWS re:Post Knowledge Center, Resolve the “CharacterStringTooLong” error from a DNS TXT record; Google Workspace Admin Help, About SPF records (checked 1 October 2026).

Check how your SPF record is split

Enter the domain in your envelope sender (Return-Path), or your From: domain if you don’t know it. It checks exactly the name you enter: www. isn’t removed, and include targets such as _spf.example.com work too. The check runs in your browser against public DNS and reads the TXT records the way a receiver gets them: each string separately, with its exact length.

This reads what your DNS publishes right now through Cloudflare’s public resolver, or Google’s when Cloudflare’s fails, using the binary DNS answer so string boundaries and lengths are exact. If every lookup fails (server error or timeout), it says it couldn’t check and reports nothing about the record. It checks the record at the name you enter; included records are checked for lookups and void terms by the DMARC checker and the void lookup checker.

How splitting goes wrong

A split in the middle of a term is fine: "… ip4:198.51.10" "0.25 ~all" joins back to ip4:198.51.100.25. What matters is that the joined text is exactly the record you meant.

How to fix it

1. Write out the full record first, as one line, in a plain-text editor. Remove any terms you no longer need now: it may then fit in one string.
2. Split it into pieces of 255 characters or fewer, at a space between terms. Keep that space inside a piece, at the end of one or the start of the next, so the joined record still has it.
3. Enter the pieces in one TXT record, the way your DNS host expects. In a zone file, and in Route 53, that is each piece in double quotes on one line: "first piece " "second piece". Some panels take the long value as is and split it for you; your DNS host’s TXT help says which. Never add a second TXT record for the rest.
4. Delete stray fragments: any TXT record at the same name that holds SPF terms but doesn’t begin with v=spf1. Move its terms into the SPF record first if they belong there.
5. Check again. Run the checker until every join shows “Joins cleanly” and the record ends with your all.

For example, this record is 275 characters:

v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/24 ip4:203.0.113.0/24 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:mail.zendesk.com include:servers.mcsv.net include:_spf.salesforce.com include:amazonses.com include:spf.mandrillapp.com ~all

Published as two strings in one TXT record, with the space at the end of the first:

"v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/24 ip4:203.0.113.0/24 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:mail.zendesk.com include:servers.mcsv.net " "include:_spf.salesforce.com include:amazonses.com include:spf.mandrillapp.com ~all"

That record has eight includes, and each included record adds lookups of its own, so check the 10 DNS lookup limit too: a record long enough to need splitting is often near it. From a terminal, dig +short TXT example.com prints each string in its own quotes, so you can see where the splits are.

Making the record shorter

RFC 7208 §3.4 says the record “SHOULD remain small enough that the results of a query for it will fit within 512 octets”, and gives a guideline: “If the size of the DNS message, the combined length of the DNS name and the text of all the records of a given type is under 450 octets, then DNS answers ought to fit in UDP packets.” That counts every TXT record at the name, including verification tokens. To shorten: remove includes for services that no longer send for you, merge adjacent ip4: addresses into one CIDR range where you own the whole range, delete verification TXT records whose services you’ve finished setting up, and move a high-volume service to its own subdomain with its own SPF record.

FAQ

Is the 255-character limit for the whole SPF record?

No. 255 is the limit for one string inside a TXT record (RFC 1035). One TXT record can hold several strings, and RFC 7208 says receivers join them into one SPF record. A 400-character SPF record is valid when it is published as two strings in one record.

Do I need a space where I split the record?

Only if the split falls between two terms. Receivers join the strings without adding spaces, so the space has to be inside one of the strings: at the end of the first or the start of the next. A split in the middle of a term needs no space; the term is joined back whole. The checker on this page shows how each split joins.

Can I put the rest of the record in a second TXT record?

No. Receivers read only TXT records that begin with v=spf1. A second record that also begins with v=spf1 makes two SPF records, which is a permerror. A second record without it is ignored, so the senders in it aren’t authorized. Put every term in one record, split into strings.

Is there a maximum total length for an SPF record?

RFC 7208 sets no fixed maximum. It says the record SHOULD stay small enough that the answer fits in 512 octets, and gives 450 octets for the name plus all TXT records at it as a guideline. DNS hosts set their own caps; Amazon Route 53, for example, allows 4,000 characters per TXT value. The 10 DNS lookup limit and the void lookup limit apply whatever the length.

Does the checker see how my DNS host split the record?

Yes. It asks a public resolver for the binary DNS answer, which keeps every string separate with its exact length, the same data a receiver gets. If both resolvers fail, it says it couldn’t check instead of guessing.

Checking many domains?

If you manage domains for clients or brands, Email Security Signals checks a whole list and returns one row per domain with SPF, DKIM, DMARC and an A–F grade, including SPF syntax errors, the lookup count and void lookups. $0.02 per graded domain ($20 per 1,000); invalid inputs, domains that don’t exist, DNS lookup failures and duplicates are free.

Related: fixing “multiple SPF records”, fixing SPF “too many DNS lookups”, fixing “too many void lookups” and the free DMARC, SPF and DKIM checker.