DKIM TXT Record Splitter
A single DNS TXT string is capped at 255 characters, but a 2048-bit DKIM public key is longer than that. The fix isn't a smaller key; it's publishing the value as multiple quoted strings in one record, which DNS resolvers concatenate back together. Route 53, BIND, and most providers need it formatted this way. Paste your key below.
Paste the full value (e.g. v=DKIM1; k=rsa; p=…). Existing quotes and line breaks are handled automatically.
All quoted strings on one line = one TXT record. Paste as a single value. In Route 53, putting each "…" on its own line creates separate records and breaks DKIM; keep it all on one line.
For a BIND zone file: adjacent quoted strings on separate lines are concatenated into one record. Not for the Route 53 console; use the one-value format above there.
Why a 2048-bit DKIM key needs splitting
DNS lets a TXT record hold several character-strings, but each one is limited to 255 bytes (RFC 1035). A 2048-bit RSA public key encodes to ~400 characters, so it won't fit in one string. You publish it as two (or more) adjacent quoted strings; resolvers join them with no separator, reproducing the original key. This is a DNS format requirement, not a limit of Route 53 or your provider; 2048-bit DKIM works everywhere once it's chunked correctly.
Don't downgrade to a 1024-bit key just to dodge the length problem. RFC 8301 tells verifiers to accept keys from 1024 to 4096 bits and tells signers to use at least 2048 where the DNS side allows it, and the splitting trick is exactly how the DNS side allows it. A shorter key buys you nothing except weaker signatures.
This tool runs entirely in your browser. Your key is never sent to a server.
Publishing the split record at your DNS provider
Route 53: use the one-value output above. All the quoted strings go on a single line in a single record. The Route 53 console treats each new line in the value box as a separate TXT record, and two separate records cannot be reassembled into one key, so DKIM fails. This is the single most common way a split record goes wrong.
Cloudflare: you can usually paste the full unsplit value; Cloudflare chunks long TXT content into 255-character strings for you. If you paste the pre-split one-value format instead, that works too.
BIND and zone files: use the zone-file output above. Adjacent quoted strings, whether on one line or wrapped in parentheses across several lines, are concatenated into one record by the zone parser.
Everything else (GoDaddy, Namecheap, Google Cloud DNS, ...): try the full value first. If the console rejects it for length, paste the one-value format with the quoted chunks. Whatever the console shows afterwards, the test that matters is what the published record resolves to, which you can check in seconds (below).
Mistakes that break a split DKIM record
- Two TXT records instead of one record with two strings. Resolvers only concatenate strings inside a record. Separate records for the two halves of the key can never verify.
- Whitespace between or inside the chunks. The strings are joined with no separator, so a stray space or line break inside the quotes becomes part of the key and corrupts the base64.
- Losing characters at the split point. Hand-splitting in an editor invites an off-by-one: a dropped
=of the base64 padding or a duplicated character at the boundary. The chunker here splits losslessly; verify the reassembled value matches your original. - Quoting for the wrong console. Some providers want the literal quote characters, some add quoting themselves. If your published record resolves with
\"sequences or doubled quotes in it, the console added a layer; paste the unquoted value instead.
Verify it after publishing
Query the selector directly: dig TXT yourselector._domainkey.yourdomain.com +short. The answer should show your quoted strings; any DKIM verifier will join them. Or skip the terminal and use our DKIM record lookup, which fetches the record, reassembles the strings, and parses the tags. Then send a real test email to a Gmail or Outlook mailbox and check for dkim=pass in the Authentication-Results header; our email header analyzer reads that header for you.
Starting from zero instead? The DKIM record generator creates the key pair and the ready-to-publish record, and the DKIM guide explains selectors, alignment, and rotation.
Frequently asked questions
Why is my DKIM record too long for DNS?
A single character-string inside a DNS TXT record is capped at 255 bytes by RFC 1035. A 2048-bit RSA DKIM public key encodes to roughly 400 characters, so the full v=DKIM1 value cannot fit in one string. The record itself is not too long: it just has to be published as multiple adjacent quoted strings, which resolvers concatenate back into the original value.
How do I split a DKIM record into 255-character strings?
Break the record value into chunks of at most 255 characters and wrap each chunk in double quotes, keeping the chunks in order inside one TXT record. Nothing else changes: no spaces, commas, or separators between the quoted strings, and the split can fall anywhere, even mid-way through the base64 key. This page does the chunking for you and outputs both the single-line format most DNS consoles want and the BIND zone-file format.
Do the split DKIM strings need spaces between them?
No. DNS resolvers join adjacent quoted strings with no separator at all. If you add a space between the quoted chunks, that space becomes part of the reassembled key and DKIM verification fails. The strings just sit next to each other in one record, in order.
Does a 2048-bit DKIM key work in Route 53, Cloudflare, and GoDaddy?
Yes, 2048-bit DKIM works at every standards-compliant DNS host once the value is chunked correctly. Some providers, like Cloudflare, accept the full long value and split it for you. Others, like Route 53 and BIND zone files, need the value entered as multiple quoted strings. In Route 53, keep every quoted string on one line in a single record: each new line in the value box creates a separate TXT record and breaks DKIM.
How do I verify my split DKIM record works after publishing?
Query the selector with dig TXT yourselector._domainkey.yourdomain.com +short and check that the reassembled value starts with v=DKIM1 and ends with the full key, or use a DKIM lookup tool that fetches and joins the strings for you. Then send a test email to a Gmail or Outlook mailbox and confirm dkim=pass in the Authentication-Results header.