DKIM DNS gotchas: splitting long TXT records (255-char chunks), quoting rules, and how to verify the published key

The DNS part of DKIM is usually boring until a 2048-bit key meets a DNS control panel that says the value is too long.

Then the guessing starts:

• should the key be split?
• where should the quotes go?
• is this one TXT record or several?
• how can the published key be checked without trusting the DNS UI?

This is the part that matters: splitting a long DKIM TXT value into 255-character chunks is normal DNS behavior, not a DKIM hack.

Per RFC 1035 Section 3.3.14, TXT RDATA is made of one or more character-strings. And each character-string is limited to 255 octets of content, which is why long DKIM keys often need multiple chunks in practice.

Per RFC 6376 Section 3.6, DKIM public keys are published in DNS under selector._domainkey.<domain>, and verifiers retrieve that published value from DNS when checking the signature.

So if the provider asks for chunking, the goal is not to change the DKIM key. The goal is to publish the same DKIM key in DNS syntax the provider accepts.

If the shorter version is enough, keep these rules in mind:

• split one long TXT value into adjacent chunks, usually no more than 255 characters each
• do not insert spaces between chunks unless the provider explicitly generates them for you
• do not turn one DKIM selector into multiple separate TXT records with different partial values
• verify the DNS answer itself, not just what the control panel preview shows
• after DNS looks right, confirm real mail produces dkim=pass

Why this happens with DKIM keys so often

The long part of a DKIM record is the p= tag, which contains the public key material.

With 2048-bit RSA keys especially, that value is often long enough that a provider UI will reject it as a single literal input, silently wrap it, or require manual splitting. That does not mean the key is too large for DKIM. It usually means the provider is exposing the DNS TXT string limit in a clumsy way.

If key size choice is still being debated, DKIM key length and algorithms: 1024 vs 2048, RSA vs Ed25519 covers the operational tradeoffs. If the immediate problem is just the DNS length error, stay focused on publication format first.

One logical TXT value, not several partial records

This is the easiest place to break an otherwise valid setup.

There is a real difference between these two ideas:

1. one TXT record made of multiple strings
2. multiple TXT records at the same selector name

The first is normal. The second is where admins accidentally publish fragments as if each fragment were its own record.

Correct concept:

selector1._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApart1"
  "part2"
  "part3"
)

Broken concept:

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApart1"
selector1._domainkey.example.com. IN TXT "part2"
selector1._domainkey.example.com. IN TXT "part3"

In the valid form, DNS serves one logical TXT value composed of adjacent strings. In the broken form, the selector has multiple TXT answers that are not the same thing as one DKIM key.

If a simpler walkthrough is what you need, DKIM record too long for DNS? How to split 2048-bit DKIM keys correctly covers the shorter version of the fix.

Quoting rules: the DNS standard and the control-panel reality

This is where people get tripped up because different DNS interfaces expose different layers of DNS syntax.

In zone-file style syntax, individual TXT strings are commonly shown as quoted strings:

"v=DKIM1; k=rsa; p=AAA..." "BBB..." "CCC..."

That is a perfectly normal way to express a TXT record made of multiple strings.

But many web DNS panels do one of these instead:

• ask for the raw TXT value and add quoting internally
• ask for one value field and auto-split it on save
• ask for several segment fields that together become one TXT record

So the practical quoting rule is not "always type quote characters manually".

The practical rule is:

1. follow the provider's input format
2. make sure the resulting DNS answer contains the exact DKIM value in the correct order
3. avoid adding literal extra quote characters into the published value

Three common mistakes show up over and over:

• pasting quotes into a field that already treats input as quoted text
• copying wrapped text from email or docs and accidentally adding spaces or line breaks inside p=
• splitting at random and losing the v=DKIM1; k=rsa; p= prefix or one chunk in the middle

The key idea is simple even if the UI is not: publish the exact same DKIM record content your mail platform generated, only reformatted into TXT chunks when necessary.

Where to split, and where not to get clever

The safest approach is mechanical, not creative.

1. Copy the DKIM record from the sending platform exactly.
2. Keep the tag structure intact, especially v=DKIM1;, k=rsa; when present, and p=.
3. Split the long value into chunks that fit the provider limit, commonly 255 characters per chunk.
4. Keep the chunks in the original order.
5. Do not insert spaces between the chunks.

In practice, splitting inside the base64 key material is fine. The DNS TXT representation is allowed to use multiple strings, and the receiver reconstructs the full value from them.

What is not fine is changing the characters themselves.

Broken examples:

v=DKIM1; k=rsa; p=MIIB... part2
v=DKIM1; k=rsa; p=MIIB...
part2
"v=DKIM1; k=rsa; p=MIIB..." " part2"

That third example is especially nasty because the leading space in the second chunk becomes part of the value.

How to verify the published key, not just the form field

This is the most useful habit in the whole process.

After saving the record, query the selector directly:

dig TXT selector1._domainkey.example.com +short

Depending on the resolver and tool output, you might see:

• one long quoted string
• several quoted strings on one line
• several quoted strings that need to be mentally concatenated

All three can still be correct.

What should be checked in the answer:

• the owner name is the expected selector under _domainkey
• the value starts with v=DKIM1;
• the p= value is complete and in the right order
• there are no unexpected spaces, missing characters, or quote characters embedded inside the actual key material

If the provider gave the original expected value, compare the DNS answer against that original source, not against memory and not against a screenshot.

For a deeper live check, send a real message through the platform that uses that selector and inspect the headers:

• DKIM-Signature should show the expected s= selector and d= signing domain
• Authentication-Results should show dkim=pass

That second test matters because a selector can exist in DNS and still be wrong in small ways that only show up during real verification. DMARC troubleshooting with Authentication-Results headers is a good companion when the DNS answer looks right but delivered mail still fails.

A few gotchas that waste the most time

• Publishing the record at selector.example.com instead of selector._domainkey.example.com
• Leaving an old selector in production and checking the wrong one
• Testing before DNS propagation has reached the resolver being queried
• Trusting a provider preview that shows wrapped text differently from the actual DNS answer
• Assuming a TXT lookup success means the DKIM key is correct without checking a real signed message

If selector changes are happening at the same time, DKIM selectors and key rotation playbook is worth reading before changing anything else.

Bottom line

Long DKIM TXT values do not need invention. They need careful publication.

Split the record into valid TXT chunks when required, respect the provider's quoting model, query DNS to confirm the exact published value, and then verify on a real message with dkim=pass.

That sequence prevents most of the annoying DKIM DNS mistakes before they turn into a vague "signature did not verify" problem later.