KoltrixPublishing a 2048-bit DKIM key when DNS splits strings
A 2048-bit DKIM public key exceeds the 255-character TXT string limit. How string splitting works, provider quirks, and how to verify the result.
On this page(8 sections)
- Why 2048-bit keys need special handling
- The three ways it goes wrong
- 1. The provider rejects or truncates the value
- 2. The value becomes two separate records
- 3. Quotes or spaces end up inside the key
- How major setups handle it
- Verifying what you published
- Why not just use 1024-bit keys?
- CNAME delegation sidesteps the problem
- Checklist
- Key takeaways
You generated a 2048-bit DKIM key, pasted it into your DNS provider, and verification fails with "key syntax error" or "no key for signature." The key is fine. The way the TXT record was stored probably is not.
Why 2048-bit keys need special handling
A DKIM public key record looks like this:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...The p= value is the base64-encoded public key. For a 1024-bit RSA key it is about 216 characters, which fits comfortably in one TXT string. For a 2048-bit key it is about 392 characters, and the whole record runs past 400.
DNS TXT records are made of one or more character strings, and each string is limited to 255 bytes by the DNS wire format. Anything longer must be stored as multiple strings in the same record. Verifiers that follow RFC 6376 concatenate those strings, without adding spaces, before parsing the key.
So a valid 2048-bit DKIM record is one TXT record containing two (or more) strings:
k2026._domainkey.example.com. 3600 IN TXT (
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx3k..."
"...remaining-base64-characters...IDAQAB" )That is not two records. It is one record with two strings. The difference matters enormously.
The three ways it goes wrong
1. The provider rejects or truncates the value
Some DNS control panels enforce a 255-character limit on the input field and silently cut the value off. The record exists, the key is truncated, and verification fails because the base64 does not decode into a valid key.
2. The value becomes two separate records
If you split the key manually and create two TXT records at the same name, verifiers see two independent records. Neither is a complete key. Results vary by verifier, but none of them are good.
3. Quotes or spaces end up inside the key
Pasting a value that already contains quotes (copied from a zone file) into a panel that adds its own quotes can produce literal quote characters in the data. Similarly, a stray space or line break inside the base64 portion corrupts the key. RFC 6376 allows whitespace in some places in the tag list, and many verifiers tolerate whitespace inside p=, but you should not rely on that.
How major setups handle it
DNS providers differ, so check your own:
- Providers that split automatically. Many modern DNS hosts accept a long value in a single field and store it as multiple strings for you. This is the easiest case; paste the full value without quotes.
- Providers that require manual splitting. Some expect you to enter the value as several quoted strings separated by a space:
"first-part" "second-part". The quotes and the space between strings are syntax, not data. - Zone files (BIND-style). Use parentheses to span lines and quote each chunk, as in the example above.
- Infrastructure as code. Terraform providers and similar tools vary; some accept a long string and split it, others want a list of strings or an escaped
"\" \""separator. Read the provider's documentation for TXT records specifically.
When you split manually, break the value anywhere, ideally inside the base64, keeping each chunk under 255 characters. The split point does not matter because verifiers join the strings back together exactly.
Verifying what you published
Your provider's dashboard shows what it intends to serve. dig shows what it actually serves:
dig +short TXT k2026._domainkey.example.comA correct 2048-bit record usually appears as two quoted strings on one line:
"v=DKIM1; k=rsa; p=MIIBIjANBgkq...x3k" "Qm9...IDAQAB"Then reconstruct and validate the key locally:
dig +short TXT k2026._domainkey.example.com \
| sed 's/" "//g; s/"//g' \
| sed 's/.*p=//' \
| base64 -d 2>/dev/null \
| openssl pkey -pubin -inform der -noout -text | head -1If that prints Public-Key: (2048 bit), the published key is intact. If openssl errors, the key was truncated or corrupted.
Finally, compare it against the private key your signer uses:
openssl rsa -in k2026.private -pubout -outform der 2>/dev/null | openssl base64 -AThe output should exactly match the p= value after the strings are joined.
Why not just use 1024-bit keys?
It is tempting to avoid the problem entirely. Don't. RFC 8301 sets 1024 bits as the minimum signers must use and recommends at least 2048 bits. 1024-bit RSA is considered weak for long-lived keys, and some receivers and security scanners already flag it. Since DKIM keys tend to stay in service for years, starting at 2048 is the sensible choice.
Going larger has its own problems. A 4096-bit key produces a record of roughly 740 characters, which needs three strings and makes DNS responses large enough that some resolvers fall back to TCP. RFC 8301 only requires verifiers to support keys up to 4096 bits, so there is no benefit to going beyond that, and 2048 is the practical sweet spot today.
Ed25519 keys (RFC 8463) are tiny, about 44 base64 characters, and avoid the issue completely, but receiver support is incomplete, so they are generally deployed alongside an RSA signature rather than instead of one.
CNAME delegation sidesteps the problem
Many email providers ask you to publish a CNAME at the selector rather than the key itself:
k1._domainkey.example.com. CNAME k1.dkim.provider.example.The provider hosts the long TXT record on their own DNS, where they control the splitting. If your DNS host handles long TXT values badly, delegating the selector this way is a clean workaround, as long as you trust the provider to manage the key.
Checklist
- Generate a 2048-bit RSA key.
- Find out whether your DNS host splits long TXT values automatically.
- If not, split the value into quoted chunks under 255 characters in one record.
- Never create two separate TXT records for one key.
- Check with
digthat the record is served as one record with multiple strings. - Rebuild the key from DNS and confirm with
opensslthat it is 2048-bit and matches your private key. - Send a test message and confirm
dkim=pass.
Key takeaways
- A 2048-bit DKIM key exceeds the 255-byte limit for a single TXT string, so it must be stored as multiple strings in one record.
- Verifiers concatenate the strings with no separator; the split point does not matter.
- Truncation, duplicate records and stray quotes are the usual failures.
- Verify the served record with
digandopenssl, not just the DNS dashboard. - Stick with 2048-bit RSA; consider Ed25519 only as an additional signature.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
