The 255 character limit that breaks long DKIM records

You generate a 2048 bit DKIM key, paste the public key into a TXT record, and the DNS provider truncates it, rejects it, or accepts it while mail signed with that key fails verification. The cause is a size limit written into the original DNS specification in 1987, and it catches people because the workaround is invisible in most control panels.

Where the limit comes from

A TXT record's data is not a single string. RFC 1035 defines it as one or more character-string values, and a character-string is length prefixed by a single byte. One byte can express 0 to 255, so no individual string can exceed 255 bytes.

That is the entire constraint. It is not a limit on the record, and not a limit on the zone. It is a limit on each string inside the record.

A TXT record may contain many such strings, one after another, and the total is bounded by message size rather than by 255. So a long value is legal. It just cannot arrive as one piece.

Why DKIM in particular

A DKIM public key record contains the base64 encoding of the key, along with a few tags. Rough sizes:

A 1024 bit key squeezes in, which is why this problem did not exist for years. Once 2048 bit became the recommended minimum, every DKIM record needed splitting.

SPF rarely hits this, because SPF records are short and the ten lookup limit constrains them long before length does. DMARC records are shorter still. DKIM is the common casualty, along with the occasional long verification token.

How splitting works

The record is published as several quoted strings separated by whitespace:

selector._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1x"
  "kJ3mQZ8fT2pQ0aVn5cR7yGhL9wXsD4eB6uK1oP3iM5nA8vC2tY7rE0jW4sH6bN9x"
  "QIDAQAB" )

The consumer concatenates them into one value before parsing. The critical detail is that concatenation adds nothing between the strings. No space, no separator. "abc" "def" becomes abcdef.

That is the mistake. If any tool, provider or copy and paste step inserts a space at a boundary, the base64 becomes abc def, the key no longer decodes, and every signature fails. The record looks correct in a control panel that renders the strings joined with spaces for readability, which is exactly how the error hides.

What providers do differently

• Automatic splitting. Route 53, Cloudflare and several others accept a long value and split it correctly on save. You paste the whole key and it works.
• Manual quoting required. Some providers expect you to supply the quoted, split form yourself. Pasting the raw key produces a truncation or a validation error.
• Silent truncation. The worst behaviour. The field accepts 255 bytes and discards the rest without warning. The record exists, parses as valid DKIM syntax, and contains an incomplete key.

If you do not know which category your provider falls into, assume the third until you have verified the published record from outside.

The other size limits nearby

Two more limits sit close enough to be confused with this one.

512 bytes over UDP. The original DNS specification capped UDP messages at 512 bytes. A response larger than that sets the truncation bit, and the resolver retries over TCP. This is a transport limit on the whole response, not on a string.

EDNS0 raises it. RFC 6891 lets a resolver advertise a larger UDP buffer, commonly 1232 or 4096 bytes. Most modern resolvers do. A large DKIM record usually still fits in one UDP response.

TCP fallback must work. If a firewall blocks DNS over TCP port 53, truncated responses cannot be retried and large records fail intermittently, typically for some resolvers and not others. Intermittent DKIM failures that correlate with no obvious pattern are worth checking against this.

Verifying the record actually published

Never trust the control panel rendering. Query the record as a resolver sees it, using the DNS Lookup tool against selector._domainkey.example.com with type TXT. Then check three things:

1. The full key is present. Compare the tail of the published p= value against your key file. Truncation removes the end, and the end usually includes the QIDAQAB suffix common to RSA public keys.
2. No spaces inside the base64. Base64 contains only letters, digits, +, / and = padding. A space anywhere inside p= means the concatenation went wrong.
3. It resolves from more than one place. Use the DNS propagation checker to confirm several resolvers return the same complete value, which also catches TCP fallback problems.

If the key looks intact and signatures still fail, the problem has moved elsewhere in the chain, and why a DKIM signature did not verify walks through the remaining causes. To regenerate a key and its record together, the DKIM generator produces both, and the email health check confirms the selector is visible alongside your SPF and DMARC records.