DKIM record too long for DNS? How to split 2048-bit DKIM keys correctly

dkim

If your DNS UI throws an error like "value too long" when adding a 2048-bit DKIM key, nothing is broken.

This is one of the most common DKIM setup moments: the key is valid, but the DNS provider field expects the value to be split.

The important part is understanding why this happens so the fix feels routine, not risky.

Per RFC 1035, TXT data is made of one or more character strings. And per RFC 6376, those strings are concatenated with no extra whitespace before DKIM verification. So splitting is not a workaround. It is standards-compliant DNS behavior.

Google's own admin guidance says the same in practical terms: with providers that limit TXT segments to 255 characters, split long DKIM values into multiple quoted strings in order (Google DKIM troubleshooting, Google DKIM setup).

If this topic is new, quick reassurance: most teams hit this at least once.

Why 2048-bit DKIM keys trigger this

A 2048-bit RSA public key (p= value) is long enough that many DNS control panels do not accept it as one literal chunk.

Some providers silently split it for you. Others require manual splitting. A few reject the full string with an unhelpful validation message.

None of these mean the selector is invalid. They just reflect how that DNS UI maps user input to TXT character strings.

If key length choices are still being decided, keep DKIM key length and algorithms: 1024 vs 2048, RSA vs Ed25519 (practical guide) nearby.

Correct split format (the part that matters)

Use the exact DKIM value generated by your mail platform. Then split only the long value into adjacent quoted chunks.

Do not add spaces between chunks. Do not reorder chunks. Do not remove semicolons between DKIM tags.

Example selector record for example.com:

selector1._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtLzL8xQk4I3xv3bq"
  "mP8W0o0i8J8x0h7B4Q8u2Qb7v5P0cR1kWfB6y1U6Tn4n3r2fR0d9Zs8tY6vD2x3"
  "4J7QqQz2dJQhK9s7g2cV8m5aN1r2uYxP7g8fN6mY1dV9k7eT0qX5mN3sA2bQ4c"
  "...rest-of-provider-generated-key..."
)

The resolver returns one logical TXT value, and DKIM verifiers use that combined value.

Step-by-step: fix "record too long" without guesswork

  1. Generate or copy the DKIM value from your sending platform.
  2. Keep the prefix exactly as provided (v=DKIM1; k=rsa; p=).
  3. Split only the long p= portion into quoted chunks that fit your DNS provider's per-string limit (often 255).
  4. Save the TXT record for the selector host (for example selector1._domainkey.example.com).
  5. Query DNS and confirm the full value is returned in the right order.
  6. Send a real message and verify dkim=pass in Authentication-Results.

That order is important: DNS first, real mail second.

How to verify the published key quickly

From any terminal, query the selector:

dig TXT selector1._domainkey.example.com +short

You should see either one long quoted string or multiple quoted strings. Both are fine if, when concatenated, they exactly match your original DKIM value.

Then validate on live traffic in message headers:

  • DKIM-Signature includes your selector (s=) and domain (d=)
  • Authentication-Results shows dkim=pass

Microsoft's current DKIM admin docs are useful here even if your specific platform differs, because the verification flow and selector checks are the same ideas (Microsoft DKIM configuration).

Yahoo's sender guidance also reinforces the operational baseline: authenticate correctly with DKIM and keep records clean and standards-compliant (Yahoo sender requirements).

Mistakes that break otherwise good DKIM records

  • Splitting in random places and accidentally inserting a space.
  • Copying wrapped text from a rich UI and introducing hidden characters.
  • Publishing at the wrong host (for example at apex instead of selector._domainkey).
  • Mixing an old p= value with a new selector.
  • Rotating selector and key at the same time across all send streams without staged checks.

If rotation planning is next, these guides help keep transitions safe: DKIM selectors and key rotation playbook and How Often Should You Rotate DKIM Keys?.

Bottom line

When a 2048-bit DKIM record looks "too long," the fix is usually simple: publish the same value as multiple quoted TXT chunks in order.

That keeps the setup aligned with RFC behavior, passes receiver checks, and avoids unnecessary fallback to shorter keys.

Previous Post