DKIM 2048-bit key too long for DNS: how to split the TXT record

2026-06-21 · dkim · dns · txt-record · email · deliverability

dkimdnstxt-recordemaildeliverability

A 2048-bit RSA DKIM public key has a base64 p= value of roughly 380 to 420 characters, and a single DNS TXT record character-string can hold at most 255. The correct fix is a single TXT record whose value is split into several adjacent double-quoted strings — DNS resolvers concatenate them back into one logical value. Do not create two separate TXT records for the selector; that breaks DKIM. Most provider UIs split it for you; BIND zone files and some control panels make you do it by hand.

Why 255 is the wall

The 255-character limit is not a per-record limit — it is a per character-string limit baked into the DNS wire format (RFC 1035 §3.3.14). A TXT record's value is a sequence of character-strings, each prefixed by a single length octet, and one octet maxes out at 255. A 1024-bit key's p= fits in one string; a 2048-bit key does not.

The fix: one record, multiple quoted strings

It is still one TXT record at selector._domainkey.example.com. Chop the long value into chunks of 255 or fewer characters and wrap each in its own pair of quotes, separated by whitespace:

default._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA"
  "u1Q3...first255chars...kQ2b" "Hf9R...next255chars...wIDAQAB" )

Resolvers join the strings with no separator, so the reassembled value is identical to the original v=DKIM1; k=rsa; p=... blob. Where you put the splits inside the base64 does not matter, as long as you never insert spaces inside a quoted string.

When you have to split it yourself

Paste the full key into Cloudflare, Route 53, or most registrar panels and they chunk it for you — you never see the quotes. The places that bite you:

BIND / NSD zone files — you write the quoted strings by hand, as above.
Legacy cPanel/Plesk builds — older versions silently truncate at 255 instead of splitting. Verify after saving.
APIs that take a raw value — some reject a single 400-char string; send an array of chunks instead.

After publishing, confirm the resolver returns the whole value:

dig +short TXT default._domainkey.example.com

A correctly split record comes back as one answer with the quoted chunks rejoined.

Two traps that quietly break signing

Two records for one selector. If you add a second TXT record at the same selector._domainkey name instead of adding a quoted string to the existing one, resolvers return both as separate answers. Verifiers pick one (or neither parses), and DKIM=fail follows. One name, one record, multiple strings inside it.

Dropping to 1024-bit to "fit." A 1024-bit key fits in a single string, so it is tempting. Don't. 1024-bit RSA is below the modern bar — 2048-bit is the current standard and what Google and Microsoft expect. Splitting the record is trivial; weakening the key to dodge it is not a trade worth making.

Run the DKIM check on your domain →

Why 255 is the wall

The fix: one record, multiple quoted strings

When you have to split it yourself

Two traps that quietly break signing

Further reading