DKIM key length: 1024 vs 2048 vs 4096

Every DKIM check ultimately comes down to one number: the length of the RSA key behind the signature. It decides how hard the key is to break, whether receivers trust it, and — at the top end — whether your DNS host can even store the record. This guide sets out what the standards say, what happens at each common length, and how to move between them safely.

What the standards require

The original DKIM specification (RFC 6376) allowed keys from 512 to 2048 bits. That floor did not survive contact with reality: in 2012 a researcher demonstrated that 512-bit DKIM keys used by several large companies could be factored cheaply, letting anyone sign mail as those domains. RFC 8301 (2018) updated the rules:

• Signers must use keys of at least 1024 bits, and should use 2048 bits or more.
• Verifiers must be able to validate keys from 1024 to 4096 bits, and must not accept anything shorter than 1024.

In plain terms: below 1024 your signatures are refused outright; 1024 is the legacy floor; 2048 is the modern default; and beyond 4096 you are outside what receivers are obliged to support.

1024-bit: works today, weaker than recommended

A 1024-bit key still verifies everywhere, which is exactly why so many old records linger. But its security margin is thin. Public factoring records stand at 829 bits (RSA-250, 2020), and the gap between 829 and 1024 is not a comfortable one against a well-resourced attacker — especially for a key that may sit unchanged in DNS for a decade. A factored DKIM key is a quiet disaster: someone else can sign mail as your domain, and it will pass authentication.

This is why our checker reports 1024-bit keys as a Warning rather than a pass: “DKIM selector found. RSA key length: 1024-bit. Consider rotating to 2048-bit or stronger.” The mail is not broken — but the key is due for retirement. The only legitimate reason to publish a new 1024-bit key today is a DNS host that cannot store a longer TXT value, and even then it should be a stopgap while you move DNS somewhere better.

2048-bit: the current standard

2048-bit RSA is where the trade-offs balance. It is the length RFC 8301 recommends, the default at Google Workspace, Microsoft 365 and most sending platforms, and comfortably beyond any demonstrated factoring capability. Signing and verification costs are negligible on modern hardware.

There is one practical wrinkle: a 2048-bit public key produces a record value longer than 255 characters, and a single DNS TXT string holds at most 255 octets. The record is therefore published as two quoted strings that verifiers join back together. Almost every DNS control panel handles this automatically — you paste one long value and the host splits it — but a handful of older panels reject the value instead. That, not cryptography, is usually what people are working around when you still see 1024-bit keys.

4096-bit: stronger, with sharper edges

A 4096-bit key is unquestionably stronger, but it buys security you are unlikely to need this decade at a real operational cost:

• The record value grows to roughly 700 characters across three or more TXT strings. More DNS hosts mishandle values this long, and mistakes here produce permerror failures that are unpleasant to debug.
• The DNS response may exceed classic UDP packet sizes, forcing retries over TCP — some badly-configured resolvers and firewalls handle that poorly, and the result is intermittent verification failure.
• RFC 8301 only requires verifiers to support up to 4096 bits, so you are at the edge of the guaranteed envelope. Signing cost also rises noticeably at high mail volumes.

If your threat model genuinely calls for more than 2048-bit RSA, it is worth knowing that the better long-term direction is a different algorithm entirely: RFC 8463 added Ed25519 to DKIM. Its keys are far shorter (a 44-character p= value) with excellent security. Receiver support is still incomplete, so senders who use it publish two selectors and dual-sign — an Ed25519 signature plus an RSA one — letting modern receivers verify the new key while everyone else falls back to RSA.

Rotation: length is only half the story

A 2048-bit key that has sat in DNS since 2019 has had years of exposure: staff turnover, server compromises, backups and copies you have forgotten about. Rotating keys periodically limits how long a quietly leaked key stays useful. A reasonable cadence for most organisations is every 6–12 months, and immediately after any suspected compromise or when a staff member with access to the private key leaves.

Rotation is safe as long as you publish the new key under a new selector and leave the old record in place while in-flight mail is still being verified. The full sequence — with a checklist — is in how to rotate DKIM keys. Date-based selector names (s202607) make the discipline visible at a glance; see DKIM selectors explained.

How to find out what you have

Run your domain through the DKIM checker. It fetches the record, decodes the p= value, and measures the actual RSA modulus, so the length reported is exact rather than guessed from the record’s size. If you do not know your selector, the selector finder will sweep the common ones. The verdicts map directly onto this guide: 2048-bit and above passes, 1024-bit warns, and anything below 1024 — or a key that will not decode — fails.

Recommendations at a glance

Ready to upgrade? The record generator creates a 2048-bit key pair in your browser — the private key never leaves the page — and gives you the exact TXT record to publish.

Related guides

• How to rotate DKIM keys — upgrade to a stronger key without failed mail.
• DKIM troubleshooting — record and key failures, and how to fix each one.
• DKIM vs SPF vs DMARC — how the three standards fit together.
• Email DNS validator (dns.studio) — check SPF and DMARC alongside DKIM.