DKIM 1024 or 2048 bits: which key size to choose

The 2048 trap: the DNS 255-character limit

Here's what surprises people moving to 2048. An encoded 2048-bit public key is long — often more than 255 characters. But a DNS TXT record is made of strings, each limited to 255 characters. A 2048 key therefore doesn't fit in a single string: it has to be split into several strings inside the same TXT record.

Concretely, instead of a single long value, the record looks like:

selector._domainkey.example.com.  IN TXT
  ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
    "...the rest of the key on a second quoted string..." )

The two quoted strings are concatenated by the resolver to reconstruct the key. It's a DNS syntax peculiarity, not an option: a 2048 key pasted as one block into an interface that only accepts a single string produces either an error or a truncated key — and the signature fails. Most DNS hosts handle this splitting automatically, but some interfaces require it to be done by hand.

What about 4096 bits?

If 2048 is good, why not 4096 to be "even safer"? In practice, 4096 is rarely recommended for DKIM: the key becomes very long (several strings, bulky DNS records), some implementations handle it poorly, and the real security gain over 2048 doesn't justify it for email signing. The consensus stays 2048 bits: the best compromise between robustness and compatibility. 4096 stays reserved for very specific cases, chosen knowingly.

Identifying the current key size

Before migrating, the starting point has to be known. Fetching the public key in DNS (dig TXT selector._domainkey.example.com) allows the size to be inferred, or — simpler — a pass through our free analyzer reads the current DKIM key and reports whether it's 1024 or 2048. An old 1024 key turning up isn't a burning emergency, but it's a good candidate for the next rotation.

Migrating from 1024 to 2048 without breaking anything

Moving from 1024 to 2048 isn't a separate operation: it's a normal key rotation, with a new size. The sequence is the dual-selector one:

1. Generating a new 2048 key under a new selector and publishing its public key (handling the string splitting if needed).
2. Verifying that the new public key is complete and visible in DNS.
3. Switching signing on the platform side to the new selector.
4. Monitoring the aggregate reports: the new 2048 signatures should pass and align.
5. Removing the old 1024 selector after a few days.

It's all detailed in key rotation. The only point specific to 2048 is the correct DNS publishing of the longer key.

If several platforms sign for the same domain — the corporate mailbox provider, a marketing tool, a transactional relay — each has its own selector and its own key, so the migration is per-platform, not global. That's good news in practice: one source can be upgraded at a time, starting with the highest-volume one, and each switch is independently reversible. There's no flag day where everything must change at once, and a 1024 key remaining on a minor source doesn't undermine the 2048 keys already deployed elsewhere — it just stays on the to-do list for the next rotation.

Publishing a 2048 key, step by step

The difficulty with 2048 isn't cryptographic, it's purely practical: the key is too long for a single TXT string. The handling depends on the DNS host. An interface that accepts a long value and handles the splitting itself (the case for most modern hosts) takes the key pasted as-is: it inserts the separating quotes on its own. An interface that requires strings of at most 255 characters needs the key split into segments by hand, each wrapped in quotes; the resolver glues them back. In case of doubt, publishing then verifying immediately with dig TXT selector._domainkey.example.com settles it: the whole key should come back, reconstituted, with no break or stray character. The interface's preview deserves no trust; what DNS actually returns does. A signature test on a real message then confirms the published key matches the private key that signs.

A little context: why size matters

The size of an RSA key measures, simplifying, how hard it is to "break" by computation. A 1024-bit key offered a comfortable margin fifteen years ago; computing power has since advanced so much that the margin has shrunk, and standards bodies raised the bar to 2048 for secrets meant to last. DKIM doesn't escape this logic: a signature is supposed to reliably prove a message's origin, which assumes a key an attacker can't reproduce. Keeping 1024 out of inertia means letting that guarantee erode without noticing. Conversely, over-sizing to 4096 doesn't bring a proportional guarantee for email and complicates publishing — hence the consensus on 2048, the balance point between real robustness and universal compatibility. The practical rule holds: 2048 by default, 1024 to replace, 4096 only where a specific requirement justifies it.

Frequently asked questions

Is 1024 dangerous to use today? Not immediately dangerous, but weakened and discouraged for the long term. It's debt to resolve at the next rotation, not an emergency to handle tonight.

Why doesn't my 2048 key "fit" in my DNS? Because it exceeds 255 characters and must be split into several strings within the same TXT record. Many interfaces do it themselves; some require the separating quotes to be inserted by hand.

Is 4096 worth aiming for, security-wise? No, generally. 2048 is the standard; 4096 bloats the record and causes compatibility issues without a commensurate benefit for DKIM.

Does my platform choose the size for me? Often, yes. Microsoft 365, Google Workspace and most SaaS generate 2048 keys by default. A check remains worthwhile, especially on old accounts set up long ago.

Does a larger key slow down sending? The impact on signing and verification is negligible. The only real concern with 2048 is DNS publishing, not performance.

Is there a key size requirement for DMARC or BIMI? DMARC itself doesn't mandate a key size — it just requires DKIM alignment. But for BIMI with a VMC (the logo-in-inbox feature), some certification authorities and industry guidelines recommend at minimum 2048-bit DKIM keys as part of the overall domain security posture. 2048 stands as the floor, not a ceiling.

How do I tell if my current key is 1024 or 2048? Fetching it with dig TXT selector._domainkey.example.com and reading the p= value settles it: a 1024-bit key encodes to about 216 characters in base64; a 2048-bit key encodes to about 392 characters. Our free analyzer also reads the key and reports the size directly.

What key size doesn't fix

Moving from 1024 to 2048 is the right call, but key size doesn't compensate for an alignment problem. A perfectly published 2048-bit key, with d= pointing to the provider's domain rather than the sender's, still doesn't contribute to DMARC. Likewise, a careful rotation is pointless if the key is never verified after publishing — a single truncated character and the signature fails silently until a report surfaces it. Key size is therefore one link in a chain to get right, not the only one. The right order: 1) confirming the key is published and complete; 2) confirming the signature aligns with the sending domain; 3) aiming for 2048 bits (or migrating at the next rotation); 4) rotating regularly. Each step builds on the previous one; size is the third, not the first. Getting worked up about key size before confirming alignment is like choosing the grade of lock before checking whether the door closes all the way.

Thomas checks the keys

Knowing the size of each DKIM key, spotting a forgotten old 1024, publishing a 2048 without truncating it: all easy details to miss. Thomas, the virtual CISO, reads the size of the current keys, flags the ones to modernize, and guides the publication of a correct 2048 key, DNS splitting included.

Analyze a domain for free or create an account for DKIM keys at the right size.