DKIM 1024 or 2048 bits: which key size to choose

When generating a DKIM key, one question always comes up: 1024 or 2048 bits? The underlying answer is simple — 2048 is the right choice today — but it comes with a technical trap many discover at the worst moment: a 2048-bit key is longer, and publishing it in DNS can hit a little-known limit. This guide explains why to aim for 2048, how to avoid the 255-character trap, and how to migrate an old 1024 key without breaking anything.

The short answer: 2048 bits

For a new deployment, choose 2048 bits. It's the recommended standard today: a 2048 key is far more resistant to brute force than a 1024 key, which is considered too weak for modern use. Major mailbox providers and security best practices converge on 2048 as the baseline. If you're starting fresh, the question is settled: 2048.

Why 1024 is on borrowed time

1024 bits isn't "broken" in the sense that anyone could forge your signatures tomorrow morning. But its security margin has eroded with available computing power, to the point that it's now considered insufficient for a secret meant to last. Keeping it means accepting a key whose robustness only decreases. Many domains still run on 1024 by legacy — a key set years ago and never renewed. That's precisely the kind of debt a well-run key rotation resolves.

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.your-domain.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: if you paste a 2048 key as one block into an interface that only accepts a single string, you get either an error or a truncated key — and the signature fails. Most DNS hosts handle this splitting automatically, but some interfaces require you to do it 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. Reserve 4096 for very specific cases, knowingly.

How to know your current key size

Before migrating, know where you start. You can fetch your public key in DNS (dig TXT selector._domainkey.your-domain.com) and infer the size, or — simpler — run your domain through our free analyzer, which reads your current DKIM key and tells you whether it's 1024 or 2048. If you discover an old 1024 key, it's not a burning emergency, but it's a good candidate for your 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. Generate a new 2048 key under a new selector and publish its public key (handling the string splitting if needed).
2. Verify the new public key is complete and visible in DNS.
3. Switch signing on the platform side to the new selector.
4. Monitor your aggregate reports: the new 2048 signatures should pass and align.
5. Remove 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.

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. Here's how to handle it depending on your DNS host. If your interface accepts a long value and handles the splitting itself (the case for most modern hosts), just paste the key as-is: the interface inserts the separating quotes for you. If it requires strings of at most 255 characters, split the key yourself into segments and wrap each in quotes; the resolver will glue them back. When in doubt, publish then verify immediately with dig TXT selector._domainkey.your-domain.com: you should find the whole key, reconstituted, with no break or stray character. Never trust the interface's preview; trust what DNS actually returns. 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. Remember the practical rule: 2048 by default, 1024 to replace, 4096 only if 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. Treat it as debt to resolve at your 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 you to insert the separating quotes yourself.

Should I aim for 4096 for more security? 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. Still, check, 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. Consider 2048 as the floor, not a ceiling.

How do I tell if my current key is 1024 or 2048? Fetch it with dig TXT selector._domainkey.your-domain.com and look at the p= value: a 1024-bit key encodes to about 216 characters in base64; a 2048-bit key encodes to about 392 characters. You can also use our free analyzer which 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 yours, 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 tells you. Key size is therefore one link in a chain to get right, not the only one. The right order: 1) make sure the key is published and complete; 2) verify the signature aligns with your domain; 3) aim for 2048 bits (or migrate at the next rotation); 4) rotate 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.

Let Thomas check your keys

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

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