TXT Record Splitter (255-Byte Chunks)
Split a long SPF, DKIM or DMARC TXT record into the 255-byte strings DNS requires, in BIND, generic zone-file, Cloudflare or Route 53 syntax.
_record IN TXT ( )
DNS character-strings are length-prefixed by one byte → 255 max per string. TXT records concatenate multiple strings, which is how DKIM keys longer than that fit in DNS.
How to use
- Paste your full TXT value (DKIM public key, long SPF, long DMARC). Sample buttons fill in realistic examples.
- Pick the DNS UI you're publishing through. The output adjusts to that provider's quoting.
- Copy and paste into the value field. The resolver re-assembles the chunks transparently for clients.
About this tool
ShowHide
A single DNS TXT character-string is capped at 255 bytes, because its length is stored in one byte at the front of it. That is a hard limit in RFC 1035 and not a provider policy, so anything longer — an RSA DKIM public key, an SPF record with a lot of includes — has to be published as several character-strings inside one TXT record. This tool splits the text at byte boundaries and emits the form your DNS provider expects: BIND's parenthesised ("part" "part"), space-separated quoted strings for a generic zone file, the shape Route 53 accepts, and a note where a provider splits for you.
The concatenation happens with nothing in between. A resolver hands the application the strings joined end to end, so a split may fall anywhere, including in the middle of a base64 run or halfway through a word — there is no separator to strip and no requirement that the pieces mean anything individually. Adding a space or a newline at the join, which looks tidier in a zone file, corrupts the value. DKIM specifies this behaviour explicitly, which is why a key that "looks right" in the DNS UI can still fail verification: the extra character is inside the record, not in the display.
A 2048-bit RSA DKIM key is the usual reason anyone needs this. Its public key is around 392 base64 characters before the v=DKIM1; k=rsa; p= prefix, which puts the record comfortably over 255 bytes and into two strings. A 1024-bit key fits in one, which is part of why so many DKIM records were left at 1024 bits long after that stopped being a good idea.
Two practical notes. Bytes, not characters — a non-ASCII character can take up to four bytes in UTF-8, so a 255-character limit and a 255-byte limit are not the same thing, and splitting in the middle of a multi-byte sequence produces two invalid halves. And the whole answer still has to travel: a TXT record that grows past the UDP payload limit forces a truncated response and a retry over TCP, which some restrictive networks quietly drop, so a very large record can work everywhere except one office.
Frequently asked questions
Why 255 bytes?
DNS character-strings are length-prefixed by a single byte. That byte caps a single string at 255. A TXT record can contain multiple strings concatenated by the resolver — "abc" "def" is read as abcdef. The protocol leaves the join up to the application.
Does Cloudflare really auto-split?
Yes. Paste a 600-byte string into Cloudflare and it'll silently split into three character-strings under the hood. The output we show for Cloudflare is just the joined value — paste that, no quoting needed.
Do the chunks need to break at a particular place?
No. A resolver concatenates the strings with nothing between them, so where you cut makes no difference as long as no chunk exceeds 255 bytes and the pieces are in order. What does matter is that the boundaries add nothing: a space introduced at a join, or a chunk quoted on its own line by a control panel that then adds one, changes the value the receiver reconstructs.
Should a long key be split, or is there a better fix?
For DKIM, consider whether the key needs to be that long — a 1024-bit key fits without splitting while a 2048-bit one does not, so many providers publish the longer key split, which is fine. What is not fine is splitting one record into several TXT records at the same name: that is a different structure, not a longer value, and verification fails.
Related tools
DKIM Record Builder & Parser
Build or parse a DKIM DNS TXT record — paste your public key, pick selector, key type, hash and flags, and get the record plus its chunked form.
Network
TLSA Record Generator (DANE) & Checker
Turn a certificate into its TLSA records — every selector and matching type — and check an existing record against the certificate you are serving.
Network
CAA Record Builder (DNS Certificate Authority Authorization)
Generate Certificate Authority Authorization (CAA) DNS records so only the CAs you trust can issue TLS certificates for your domain.
Network
SVCB / HTTPS Record Builder & Decoder
Normalise, encode and check an SVCB or HTTPS record: SvcParams decoded, the wire bytes broken down, and every RFC 9460 rule it breaks named.
Network
Email Header Analyzer
Paste a raw email header to walk the Received hops in order, see the per-hop delay, and read off the SPF/DKIM/DMARC verdicts.
Network
SPF Record Builder
Compose a Sender Policy Framework TXT record from mechanisms, IPs and includes — with a live DNS-lookup counter and warnings.
Network