Is a TXT record limited to 255 characters total?

No, and this is the misconception that causes the whole mess. The 255-byte limit is per character-string, not per record. RFC 1035 §3.3.14 defines TXT RDATA as one or more character-strings, each prefixed by a single length byte — and a length byte can only count up to 255. A TXT record can hold many of those strings back to back, so the record as a whole can be thousands of bytes (the hard ceiling is 65,535 bytes of RDATA, and in practice DNS message size limits you first). When a resolver reads the record, it concatenates the strings with no separator. So a 400-character DKIM key is perfectly legal — it just has to arrive as two strings, not one.

Does the split point matter, and can I put a space between the chunks?

The split point does not matter — you can break the value at any byte boundary, because resolvers join the strings with nothing between them. What matters is that you never let a stray space or newline land inside the data. Splitting is `"firsthalf" "secondhalf"`: one space between the closing quote and the opening quote, zero spaces inside either chunk. If a copy-paste or a tool inserts a space in the middle of a base64 key, concatenation faithfully reproduces that broken key and DKIM verification fails — even though the record looks fine in the dashboard.

Why did my 1024-bit DKIM key work but the 2048-bit one doesn't?

Length. A 1024-bit RSA public key is roughly 216 base64 characters once wrapped in `v=DKIM1; k=rsa; p=...`, which fits inside a single 255-byte string. A 2048-bit key is usually 390 or more base64 characters, so it cannot live in one string. Some DNS providers split it for you automatically; others reject it with a 'string too long' error; the dangerous ones silently truncate it or store it wrong. If you upgraded your DKIM key size and signing broke, the record length is the first thing to check.

Views: 18

TXT Record Over 255 Characters: Split It Right

TXT record over 255 characters fails because each string caps at 255 bytes. Split it into quoted chunks the right way in 4 checks. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

You paste a long TXT value — almost always a 2048-bit DKIM key, sometimes a sprawling SPF or verification record — and something goes wrong. The DNS provider rejects it with “string too long,” or it accepts the record but the thing that depends on it (DKIM signing, domain verification) fails anyway.

Symptoms

The DNS panel errors out with “character string too long” or “value exceeds 255 characters.”
The record saves, but dig TXT shows the value broken across multiple quoted strings and you’re not sure that’s correct.
DKIM verification fails with body hash did not verify or key not found, even though the record is clearly there.
It started right after you rotated a DKIM key from 1024-bit to 2048-bit.

What the 255 Limit Actually Is

This trips up almost everyone, so it’s worth being precise. RFC 1035 §3.3.14 says the RDATA of a TXT record is “one or more <character-string>s.” A <character-string> is a single length byte followed by that many bytes of data — and a single byte tops out at 255. So no individual string can exceed 255 bytes. That’s the real rule.

The misconception is reading that as “a TXT record can’t exceed 255 characters.” It can. A TXT record is allowed to carry a whole sequence of character-strings, one after another, up to 65,535 bytes of RDATA total (you’ll hit DNS message-size limits long before that). When a resolver returns the record, it concatenates the strings with no delimiter — they’re glued together byte-for-byte. So "abc" "def" is delivered to the application as abcdef.

A 2048-bit DKIM key is around 390+ base64 characters. It physically cannot fit in one 255-byte string. The fix isn’t to shorten it — it’s to publish it as two (or more) strings that concatenate back to the exact original.

Top 3 Causes

A 2048-bit DKIM key pasted as a single string — The most common case by far. The key is longer than 255 bytes, so a strict provider refuses it and a sloppy one mangles it. Correct form in a zone file or panel: "v=DKIM1; k=rsa; p=MIIBIjANBg...firstpart" "...secondpart...AQAB". Break the base64 anywhere; just don’t add characters.
A space or newline injected into the split — You split correctly, but a text editor wrapped the line, or a copy-paste dragged in a space, and now there’s whitespace inside one of the chunks. After concatenation the base64 is corrupted by that one extra byte, the public key won’t parse, and DKIM silently fails. The record looks complete; the data isn’t.
Provider auto-split you didn’t expect — Route 53, Google Cloud DNS, Cloudflare, and PowerDNS split long values for you. That’s usually fine — but if you also manually split, you can end up double-quoted or with mismatched chunking. Know whether your provider auto-splits before you split by hand.

Diagnose with DechoNet

DNS Check pulls the TXT record as resolvers actually see it, with the character-strings shown. Concatenate them in your head (no separators) and confirm the result is exactly your key — no stray spaces, no missing tail.
Email Check reads your DKIM, SPF, and DMARC records end to end. If a split DKIM key is corrupt, this is where the downstream failure shows up as an invalid or unparseable key rather than a vague DNS error.

Resolution Checklist

Confirm it’s a per-string problem: count your value. Under 255 bytes, length isn’t your issue. Over 255, it must be split.
Split into chunks of 255 bytes or fewer, each wrapped in its own double quotes, separated by exactly one space: "chunk1" "chunk2".
Verify nothing leaked inside a chunk — no spaces, no line breaks within the base64. The split point is free; injected characters are fatal.
Re-read the live record with dig +short TXT selector._domainkey.example.com and mentally concatenate the quoted strings. The joined result must equal your original key byte-for-byte.
If your provider auto-splits, paste the value as one line and let it chunk — don’t pre-split, or you may end up with broken quoting.
For DKIM specifically, send a test message and check the receiver’s dkim=pass in Authentication-Results, not just that the record exists.

When to Escalate

If the DNS panel refuses any multi-string TXT value and offers no way to enter quoted chunks, the provider’s interface is the blocker — open a ticket or move that zone to a provider that handles long TXT records.
If the record concatenates perfectly but DKIM still fails, the problem has moved past DNS: the published public key may not match the private key your mail server signs with. That’s a key-pair mismatch, not a 255-byte split issue.