# DKIM 2048-bit key too long for a TXT record: how to split it correctly

URL: https://iblockspam.com/blog/dkim-2048-bit-key-txt-record-too-long
Last updated: 2026-10-10
Published: 2026-10-10
Topic: SPF, DKIM & DMARC
Author: iBlockSpam Team

> Why a 2048-bit DKIM key won't fit in one 255-character TXT string, how to split it correctly, what Cloudflare, Route 53 and GoDaddy expect, and how to check it.

## Short answer

A single TXT string holds at most 255 characters, and a 2048-bit DKIM record is about 410. Publish it as one TXT record containing several quoted strings, such as "v=DKIM1; k=rsa; p=MIIB..." "...IDAQAB". Receivers join the strings with no spaces. Never split it into two separate TXT records, and check the result with a DKIM checker.

You generate a 2048-bit DKIM key, paste it into your DNS host, and get an error like "value too long", or the record saves but DKIM fails. The key isn't wrong. It's longer than one TXT string can hold, and it needs to be stored the way DNS expects.

## Why doesn't a 2048-bit DKIM key fit?

DNS limits each piece of text in a TXT record, not the record as a whole.

[RFC 1035](https://www.rfc-editor.org/rfc/rfc1035.html) defines a TXT record as "one or more `<character-string>`s" (section 3.3.14). Each character-string is "a single length octet followed by that number of characters" and "can be up to 256 characters in length (including the length octet)" (section 3.3). That leaves 255 characters of text per string.

A DKIM key record is the selector's TXT value, such as `v=DKIM1; k=rsa; p=` followed by the base64 public key. We generated standard RSA keys with OpenSSL to measure the sizes:

| Key | Base64 public key | Full record with `v=DKIM1; k=rsa; p=` | Fits in one string? |
|---|---|---|---|
| RSA 1024-bit | 216 characters | about 234 | Yes |
| RSA 2048-bit | 392 characters | about 410 | No: needs 2 strings |
| RSA 4096-bit | 736 characters | about 754 | No: needs 3 strings |

So 1024-bit keys fit, and 2048-bit keys don't. That's why the problem appeared when providers moved to 2048 bits, which [RFC 8301](https://www.rfc-editor.org/rfc/rfc8301.html) recommends: signers "SHOULD use RSA keys of at least 2048 bits." Our guide to [DKIM key rotation](https://iblockspam.com/blog/dkim-key-rotation) covers when to move up.

[Google's DKIM troubleshooting guide](https://knowledge.workspace.google.com/admin/security/troubleshoot-dkim-issues) states the problem directly: "You can not enter a 2048-bit key as a single text string with a 255-character TXT record limit. Your DKIM key might be truncated, or your DKIM records might be sent out of order."

## How do you split a DKIM key correctly?

You keep **one TXT record** and put the value in **several quoted strings** inside it. Receivers glue them back together. [RFC 6376, section 3.6.2.2](https://www.rfc-editor.org/rfc/rfc6376.html#section-3.6.2.2) says: "Strings in a TXT RR MUST be concatenated together before use with no intervening whitespace."

A split 2048-bit record looks like this (key shortened):

```
selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...first-part" "...second-part...IDAQAB"
```

The rules:

1. **One record, several strings.** All strings go in the same TXT value.
2. **Each string is 255 characters or fewer.** A 2048-bit record splits comfortably into two.
3. **Split anywhere.** Because nothing is added between strings, you can break in the middle of the base64 key.
4. **Don't add spaces or line breaks inside a string.** A space within the key changes it.
5. **Don't lose characters at the boundary.** The end of string one and the start of string two must join to the exact original key.
6. **Don't use two TXT records.** RFC 6376 says that if there are multiple records in an RRset at a selector, "the results are undefined."

Splitting in the middle of the key is safe for DKIM. It isn't always safe for SPF, where a split between two terms needs a trailing space; see [SPF record syntax](https://iblockspam.com/blog/spf-record-syntax-examples).

### Splitting by hand

1. Copy the full value from your email provider into a plain text editor, on one line.
2. Count off the first 250 characters or so, and cut there.
3. Wrap each part in double quotes, and put the parts on one line with a single space between the closing quote of one and the opening quote of the next.
4. Check that the two parts, joined, match the original exactly.

If you're editing a BIND zone file directly, RFC 9989's own examples show long TXT values as several quoted strings inside parentheses, which is the same thing on multiple lines.

## What do Cloudflare, Route 53 and GoDaddy expect?

DNS hosts handle long values differently. Some split for you, some make you do it, and some don't say.

| DNS host | What its documentation says | What to enter |
|---|---|---|
| Cloudflare | Long values are split into multiple quoted strings | Paste the key as one value, without your own quotes |
| Amazon Route 53 | Each string up to 255 characters; you must split longer values | Pre-split quoted strings on one line |
| GoDaddy | Value field accepts up to 1,024 characters | Paste the value as your provider gives it, then verify |
| Google Cloud DNS, others | Varies | Check your host's TXT documentation |

### Cloudflare

[Cloudflare's DNS FAQ](https://developers.cloudflare.com/dns/faq/) explains that "when the value you enter exceeds 255 characters, it must be split into multiple strings," so a saved record "may appear to have a quote in the middle." It says this splitting "is required by the DNS protocol and is performed by all DNS providers, even if some do not display it in their UI or API," and that for DKIM "the receiving application will concatenate the strings back together." Its [record types page](https://developers.cloudflare.com/dns/manage-dns-records/reference/dns-record-types/) adds that if you save TXT content without quotes, Cloudflare adds them, and that inconsistent quotes can cause a validation error.

So in Cloudflare, paste the key as a single value without adding quotes. Seeing `" "` in the middle afterwards is normal. Our [Cloudflare DNS guide](https://iblockspam.com/blog/add-dmarc-spf-dkim-records-cloudflare) shows the full screen-by-screen steps.

### Amazon Route 53

Route 53 makes you split. Its [record type documentation](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ResourceRecordTypes.html) says "A single string can include up to 255 characters," and "If you need to enter a value longer than 255 characters, break the value into strings of 255 characters or fewer, and enclose each string in double quotation marks." In the console, list all the strings on the same line. The maximum value length is 4,000 characters.

If you paste the key as one string, Route 53 returns an error. The AWS knowledge center article is titled after it: "CharacterStringTooLong (Value is too long)". [Its fix](https://repost.aws/knowledge-center/route53-resolve-dkim-text-record-error): split the key into two parts, put each in double quotes, "Include a blank space between the two parts" and "Don't add a line break between the two parts." It also confirms that "when you split the value, the DKIM functionality doesn't break."

### GoDaddy

GoDaddy's [Add a TXT record](https://www.godaddy.com/help/add-a-txt-record-19232) page says the Value field allows a maximum of 1,024 characters, which is enough for a 2048-bit key record. It doesn't say whether GoDaddy splits long values itself or expects quoted strings. Paste the value exactly as your email provider gives it, save, and then confirm the published key with a lookup as shown below. If the lookup shows a truncated key, contact GoDaddy support before trying again. Our [GoDaddy DNS guide](https://iblockspam.com/blog/add-email-dns-records-godaddy) covers where the DKIM record goes.

## What about Microsoft 365 and Google Workspace?

**Microsoft 365** doesn't ask you to paste a key at all. [Microsoft's DKIM guide](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure) says the public keys are stored in "CNAME records in Microsoft 365," so your two selector CNAMEs point at keys Microsoft publishes. Its PowerShell cmdlets take `-KeySize` values of 1024 or 2048. The 255-character limit isn't your problem there.

**Google Workspace** gives you a TXT value to paste. When you [generate the key](https://knowledge.workspace.google.com/admin/security/set-up-dkim), Google says to choose 2048 "if your domain provider supports 2048-bit keys" and 1024 if it doesn't. Its troubleshooting page also suggests contacting your domain host "to find out whether TXT records with more than 255 characters can be supported."

Our [DKIM setup guide for Microsoft 365 and Google Workspace](https://iblockspam.com/blog/dkim-setup-microsoft-365-google-workspace) walks through both, and the [DKIM records by provider](https://iblockspam.com/dkim) pages show what [Google Workspace](https://iblockspam.com/dkim/google-workspace), [Microsoft 365](https://iblockspam.com/dkim/microsoft-365) and other services ask you to publish.

## How do you check the key was published correctly?

1. **Look up the selector.** Run the [DKIM Checker](https://iblockspam.com/tools/dkim-checker) with your domain and selector. It reads the full record, joins the strings, and reports the key type and size, for example "2048-bit RSA key". If the key can't be parsed, it fails the check, which is what a truncated or mangled key looks like.
2. **Inspect the raw answer.** From a terminal, run `dig +short TXT selector._domainkey.example.com`. You should see **one** answer line with two or more quoted strings. Two separate answer lines mean two records.
3. **Compare with the source.** Google suggests comparing the value at your DNS host with the value in your Admin console. Join the strings in your head, or in an editor, and check the start and end of the key match.
4. **Send a test message.** Send to an outside mailbox and open the headers in the [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer). Look for `dkim=pass` with your domain in `header.d`.
5. **Then turn on signing.** In Google Workspace and most sending platforms, only start signing once the record checks out.

If you don't know your selector, our guide on [how to find a DKIM selector](https://iblockspam.com/blog/find-dkim-selector) shows where it appears in a message header.

### Common mistakes and what they look like

| Mistake | Symptom | Fix |
|---|---|---|
| Key pasted as one string where the host doesn't split | Error on save, or truncated key | Split into quoted strings |
| Strings saved as two TXT records | Intermittent or permanent DKIM failures | Delete both; publish one record with two strings |
| Extra quotes pasted into Cloudflare | Quote characters inside the key | Re-enter without quotes |
| Space or line break inside the key | Key can't be parsed | Re-copy from the provider on one line |
| Characters lost at the split point | Key can't be parsed | Re-split from the original value |

## Is there a shorter alternative?

Ed25519 keys, defined in [RFC 8463](https://www.rfc-editor.org/rfc/rfc8463.html), are far shorter and fit in one string. But mailbox providers don't all document support for them. For backward compatibility, RFC 8463 section 6 describes signing with both RSA and Ed25519, each under its own selector, rather than replacing RSA. [What is DKIM?](https://iblockspam.com/blog/what-is-dkim) explains the trade-off. For most domains, a correctly split 2048-bit RSA key is the practical answer.

## Next steps

- Check every selector you use with the [DKIM Checker](https://iblockspam.com/tools/dkim-checker) and note which ones are still 1024-bit.
- If you run your own mail server, generate a new 2048-bit key pair with the [DKIM Generator](https://iblockspam.com/tools/dkim-generator), publish it under a new selector, and switch over using the [key rotation guide](https://iblockspam.com/blog/dkim-key-rotation).
- Run a full [Email Health Check](https://iblockspam.com/tools/email-health-check) to confirm SPF and DMARC are in order too.

Browse our other [SPF, DKIM and DMARC guides](https://iblockspam.com/blog/topic/authentication).

## Frequently asked questions

### Why is my 2048-bit DKIM key too long?

DNS stores TXT data as character-strings of up to 255 characters each. A 2048-bit RSA public key is 392 characters of base64, so the full record with v=DKIM1; k=rsa; p= is about 410 characters. It must be stored as two or more strings in the same TXT record.

### Should I split a DKIM key into two TXT records?

No. Use one TXT record that contains several quoted strings. Two separate TXT records at the same selector name are a different thing: RFC 6376 says that if there are multiple records, the results are undefined, so verification can fail at random. Receivers only join strings within one record.

### Does splitting the key break DKIM?

No. RFC 6376 says strings in a TXT record must be joined with no intervening whitespace before use, so receivers see one continuous key. AWS also notes that splitting the value doesn't break DKIM. What breaks it is a missing chunk, a stray space or quote, or chunks in separate records.

### Where should I split the DKIM key?

Anywhere, as long as each string is 255 characters or fewer. Because the strings are joined with nothing in between, you can split in the middle of the base64 key. Don't add spaces or line breaks inside a string, and don't drop any characters at the boundary.

### Should I just use a 1024-bit key instead?

Only as a stopgap. RFC 8301 says signers SHOULD use keys of at least 2048 bits, and 1024 is the minimum. Google suggests 1024 bits only if your DNS host can't store a longer TXT value. Most hosts can, if you enter the key correctly, so try splitting first.

## Sources

- [RFC 1035: Domain Names, sections 3.3 and 3.3.14 (character-string and TXT format)](https://www.rfc-editor.org/rfc/rfc1035.html)
- [RFC 6376: DKIM Signatures, section 3.6.2.2](https://www.rfc-editor.org/rfc/rfc6376.html#section-3.6.2.2)
- [RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM](https://www.rfc-editor.org/rfc/rfc8301.html)
- [Google Workspace Admin Help: Troubleshoot DKIM issues](https://knowledge.workspace.google.com/admin/security/troubleshoot-dkim-issues)
- [Amazon Route 53 Developer Guide: Supported DNS record types (TXT)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ResourceRecordTypes.html)
- [AWS re:Post Knowledge Center: Resolve the CharacterStringTooLong error for DKIM TXT records](https://repost.aws/knowledge-center/route53-resolve-dkim-text-record-error)
- [Cloudflare Docs: DNS FAQ (TXT record with a double quote in the middle)](https://developers.cloudflare.com/dns/faq/)
- [GoDaddy Help: Add a TXT record](https://www.godaddy.com/help/add-a-txt-record-19232)

## Free tools for this guide

- [DKIM Key Generator](https://iblockspam.com/tools/dkim-generator): Create a DKIM key pair and the DNS TXT record for your selector — keys are generated in your browser.
- [DKIM Checker](https://iblockspam.com/tools/dkim-checker): Validate DKIM keys by selector, including key type and strength.
- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.
- [Email Health Check](https://iblockspam.com/tools/email-health-check): Grade your domain's MX, SPF, DKIM, DMARC and transport security in one scan.

---

Source: iBlockSpam, https://iblockspam.com/blog/dkim-2048-bit-key-txt-record-too-long (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt