1024-bit vs 2048-bit DKIM keys

22 June 2026 · 5 min read

Use a 2048-bit RSA key for DKIM. RFC 8301 says signers must use keys of at least 1024 bits and should use at least 2048 bits, and verifiers must not accept signatures from keys shorter than 1024 bits. The only practical difficulty with 2048 bits is publishing it: the DNS record is about 410 characters long, and a single DNS text string holds at most 255, so the value has to be split into two or more strings.

1024-bit versus 2048-bit at a glance

The lengths come from generating real keys with OpenSSL and measuring the base64 output.

Why 2048 bits

DKIM signatures use RSA, and the security of an RSA key depends on how hard it is to factor its modulus. Anyone who recovers your private key can sign mail as your domain that passes DKIM and DMARC. There is no public record of a 1024-bit RSA key being factored, but 2048 bits leaves far more margin, which is why RFC 8301 recommends it. A 2048-bit signature costs a negligible amount of extra processing, and there is no deliverability penalty for using one.

Google's Workspace guidance is to choose 2048 bits if your DNS host supports it, and to fall back to 1024 only if it does not.

Why a 2048-bit key needs splitting

A TXT record is made of one or more character strings, and each string can be at most 255 bytes, because DNS stores its length in a single byte (RFC 1035, section 3.3). A 1024-bit DKIM record fits in one string. A 2048-bit record does not, so it has to be published as two or more strings in the same TXT record:

selector1._domainkey  IN  TXT  ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
  "...rest of the base64...IDAQAB" )

Receivers join the strings back together with nothing in between, so the split can fall anywhere in the p= value. What matters is that the strings belong to one record. Two separate TXT records at the same selector are not the same thing and will not verify.

How DNS hosts handle long TXT values

• Cloudflare splits values longer than 255 characters into multiple strings automatically. Paste the whole value into one field. If you later see a quotation mark in the middle of the value, that is the split, not an error.
• Amazon Route 53 wants you to split the value yourself: each string in double quotation marks, all on the same line, for example "v=DKIM1; k=rsa; p=MIIB..." "...IDAQAB". Putting the strings on separate lines creates separate TXT records, which breaks the key.
• Google Cloud DNS asks you to enclose each string in quotation marks, with each string at most 255 characters. See adding DMARC, SPF and DKIM in Google Cloud DNS.
• Other DNS panels vary. Some split automatically and some reject long values. Check your provider's TXT documentation, then check the live result.
• Microsoft 365 and other CNAME-based providers never ask you to paste the key. You publish CNAME records and the provider hosts the key, so the length problem does not arise.

If your host needs manual splitting, the DNS record splitter turns a long value into correctly quoted 255-character strings.

Generating a 2048-bit key yourself

Most sending platforms generate the key for you; if they offer a choice, pick 2048. If you run your own signing server:

openssl genrsa -out dkim-private.pem 2048
openssl rsa -in dkim-private.pem -pubout -outform der | openssl base64 -A

The first command creates the private key your mail server signs with. Keep it secret: anyone holding it can sign as your domain until you rotate. The second prints the public key as one line of base64, which goes after p= in the DNS record. The DKIM generator produces a ready-to-publish 2048-bit record if you would rather not use OpenSSL.

Check what you published

Query the selector directly:

dig +short TXT selector1._domainkey.example.com

A split record shows as two or more quoted pieces on one line. Joined together, the p= value should be complete and end the same way as the key you generated, typically with IDAQAB. If it stops short, your DNS host truncated it. If two separate answers come back, you have created two records instead of one.

The DKIM checker joins the strings the way a verifier does, confirms the key parses and reports its size. Finally, send a message to a mailbox you control and check the Authentication-Results header for dkim=pass with your domain.

Moving from 1024 to 2048 bits

Do not replace the key under the selector you are signing with: mail already in transit would fail verification. Publish the 2048-bit key under a new selector, switch signing to it once it resolves, and remove the old record after a few days. How to rotate DKIM keys safely walks through the timing.

Some providers handle this for you. Microsoft 365, for example, can move a domain to 2048-bit keys during a key rotation, covered in DMARC for Microsoft 365.

Ed25519 keys

RFC 8463 added Ed25519 as a DKIM signing algorithm. Its public keys are short enough to fit in a single string, but not every receiver verifies Ed25519 signatures yet, so if you add one, keep an RSA signature alongside it. For most domains, a 2048-bit RSA key is the practical choice.

If you would rather not generate, split and rotate keys by hand, hosted DKIM creates 2048-bit keys, manages the selectors and handles rotation.