DKIM TXT Record Too Long? Why DNS Stops at 255 Characters and How to Split the Key

A DKIM record for a 2048-bit key does not fit in one DNS string, so it has to be split into two or more strings inside a single TXT record. The limit comes from the DNS standard, RFC 1035, which we read for this post on 9 November 2026. Section 3.3 defines a character string as a length octet followed by that many characters, and says a string can be up to 256 characters long including the length octet. That leaves 255 octets of data per string. Section 3.3.14 says a TXT record holds one or more of them.

If your DNS panel complained that the value is too long, or you copied the record and it came out cut off, this is why. The free DNS TXT record splitter cuts a pasted value into strings of 255 octets or less and writes the zone file line for you. The rest of this post explains what it is doing, so you can check it by hand.

Split a long TXT value →

Why a DKIM record gets long

A DKIM record starts with a few tags and then carries the public key in the p tag, base64 encoded. RFC 6376, section 3.6.1, defines those tags: v for the version, k for the key type, p for the key, and a few others. The key is the long part.

Roughly, a 1024-bit RSA public key in the common encoding produces a p value of about 215 characters. A 2048-bit key produces about 390. Add the leading v=DKIM1; k=rsa; p= and the 1024-bit record is near 235 characters, which still fits in one string, while the 2048-bit record is near 410 and does not. That is why people hit this wall the day they move up to a stronger key. (RFC 8301, section 3.2, says signers must use RSA keys of at least 1024 bits and should use at least 2048, so the move is expected. DKIM 1024 vs 2048-bit: how to check your key covers that side.)

The sizes above are approximate and depend on how the key was exported, which is why the tool counts the real octets of whatever you paste rather than relying on a rule of thumb.

One record, several strings

The fix is not a second record. It is several strings in the same record. In a zone file it looks like this, with the key shortened:

selector1._domainkey  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..." "...rest of the key..."

Each piece is in its own pair of quotes, separated by a space outside the quotes. A reader that asks DNS for the record receives both strings and joins them. RFC 6376 section 3.6.2.2 says strings in a TXT record must be concatenated with no intervening whitespace, and RFC 7208 section 3.3 says the same for SPF. The space between the two quoted strings in the zone file is zone-file syntax, not part of the value.

You can also write the strings on separate lines inside brackets, which the zone file format allows and which is easier to read for a long key. The splitter has a checkbox for that layout.

Where the cut can go

You can split anywhere, because the reader rejoins the pieces. The only rules are that no piece is over 255 octets and that you never cut inside a multi-octet character. A DKIM key is plain ASCII, so in practice every character is one octet. The splitter cuts at the limit and never in the middle of a character, which matters if you reuse it for a TXT value that has non-ASCII text.

Some people prefer shorter pieces, say 200 characters, because their DNS host asks for it. The splitter lets you lower the size for that case. 255 is the ceiling, not a target.

What goes wrong in practice

Most "DKIM fail" tickets after a key change are copy errors, not cryptography:

1. A half-pasted key. The first string was saved and the second was dropped. The key now stops mid-way and cannot be read.
2. A space inside the key. A line break from an email or a PDF turned into a space. Whitespace inside the p value breaks the key at the receiver.
3. Smart quotes. A word processor replaced the straight quotes with curly ones, and the quotes became part of the value.
4. Two records instead of two strings. The second half was added as its own TXT record under the same name. Receivers then see two DKIM records for one selector, and RFC 6376 section 3.6.2.2 requires one record per selector.
5. The wrong host name. The record sits at the domain instead of at selector._domainkey.yourdomain.

After the change saves, look the record up the way a receiver would. How to look up a domain's TXT records shows the lookup, and the DKIM key length checker reads the key and reports its size in bits. If it can report a size, the key survived the trip.

A quick check you can do by hand

1. Count the characters in your whole value. Over 255, and you need more than one string.
2. Count each quoted string in the published record. None should exceed 255.
3. Join the strings in your head, with nothing between them. The result should start with v=DKIM1 and end with the last character of the key.
4. Send a test message to an inbox you control and read the authentication results in its headers.

Authenticated is not the same as deliverable

Once DKIM is fixed, it is tempting to think the domain is ready for volume. It is half ready. Authentication tells a receiver the message really came from you. It says nothing about whether the recipient exists. A list full of dead addresses on a perfectly signed domain still produces bounces, and a high bounce rate is what damages a new sending domain's name, signed or not.

SPF, DKIM and DMARC explained covers how the three fit together. Keep the two jobs separate: DNS records are set once, and the list changes every campaign.

The routine

1. Generate the key in your sending service.
2. Paste the value into the splitter if your DNS host rejects it or cuts it off.
3. Publish it at the selector host name as one record with several strings.
4. Check it with the DKIM key length checker.
5. Verify the list at /verify before the first send, and suppress invalid rows.
6. Send valid rows first, risky rows slowly after. How often to verify an email list gives a schedule.

Try it on your own list

Upload a sample at /verify. The first 100 checks are free with a Google sign-in, no card.

Pro, $39 a month: Unlimited email verification.* Never metered, never cut off. See pricing.

*Fair use: the first 100,000 checks a month at full speed, then slower, never cut off.