DKIM Keys: 1024 vs 2048 Bits, and When to Rotate Them

In 2012, a mathematician named Zachary Harris got a curious recruiting email from Google and noticed something better than the job: Google was signing its mail with a 512-bit DKIM key. He factored it in about 72 hours of cloud time, then sent Sergey Brin an email as Larry Page, cryptographically valid, indistinguishable from the real thing. Google rotated to 2048 bits within days.

That story is the entire argument for caring about DKIM key length. Your DKIM key is the thing that proves your mail is yours, we've called it the load-bearing wall of DMARC alignment, since it's the pass that survives forwarding. Which means a cracked or leaked key isn't a partial problem: whoever holds it can send mail that passes your DMARC at p=reject. Perfect spoofing, signed by you.

Two operational decisions keep that from happening: how long the key is, and how often you replace it.

Key lengths in 2026: the honest comparison

512-bit, broken. Factorable for under $100 of cloud compute since the Harris incident. Most receivers now ignore signatures from keys this short, which means signing with one is worse than not signing. If a legacy system still uses one, treat it as an incident.

1024-bit, the deprecated floor. Not publicly cracked, but NIST deprecated RSA-1024 back in 2013, and factoring it is considered within reach of well-resourced attackers. Gmail accepts it as a minimum and explicitly recommends 2048. The practical read: 1024 doesn't fail any check today, but you're betting your domain's identity on "probably nobody with a budget cares about us." Replace it at your next convenient window, via the rotation procedure below, it costs nothing.

2048-bit, the standard. Use this. The right answer for effectively everyone: secure against factoring for the foreseeable future, universally supported by receivers. One implementation quirk: a 2048-bit public key exceeds the 255-character limit of a single DNS TXT string, so it must be published as multiple quoted chunks ("v=DKIM1; k=rsa; p=MIIBIjANBg..." "...rest..."). Modern DNS providers handle the splitting automatically; some older interfaces make you do it by hand, and a truncated paste is one of the classic ways DKIM silently breaks.

4096-bit, overkill. The security gain over 2048 is marginal against any realistic threat model, some DNS providers and validators handle the oversized records badly, and larger signatures add bytes to every message. Not wrong, just not useful.

Ed25519 (RFC 8463), the future, partially arrived. Modern elliptic-curve DKIM: keys so short they fit DNS trivially, faster to verify. The catch is receiver support, which remains incomplete, so an Ed25519-only setup will fail authentication wherever it isn't understood. If you adopt it, dual-sign: attach both an RSA-2048 and an Ed25519 signature to each message. Receivers that understand Ed25519 use it; the rest fall back to RSA.

Why rotate a key that isn't broken

Because keys don't announce when they leak. A private key lives on your ESP's signing infrastructure, maybe on your own servers, sometimes, regrettably, in a git repository or a config backup. An ESP breach, a departed employee, a compromised host: any of these can expose it, and a stolen DKIM key is the quiet kind of stolen. Nothing fails; someone can simply sign as you.

Rotation caps that exposure. Whatever leaked last year stops working the day you rotate. It also limits DKIM replay, a scheme where spammers capture one legitimately-signed message and re-send it at scale, riding your signature and your reputation; shorter key lifetimes narrow the replay window.

The cadence: every 6–12 months as routine, and immediately when there's a trigger, a vendor security incident, offboarding someone who had infrastructure access, a key spotted anywhere it shouldn't be, or unexplained DMARC report rows passing DKIM from sources you don't recognize.

One large exemption: if your DKIM records are CNAMEs pointing at your ESP (the common s1._domainkey.you.com → s1.domainkey.esp.com pattern), the vendor owns the keys and many rotate them automatically, that's the main argument for the CNAME pattern. If your record is a TXT you generated and pasted yourself in 2021, the calendar is yours.

Rotating with zero downtime

Selectors are what make rotation painless, that's the string before ._domainkey in your DNS, and it's chosen per-signature, which means old and new keys can coexist:

1. Publish the new key under a new selector, if you sign with s1, create s2._domainkey.yourdomain.com with the new 2048-bit public key. Nothing changes yet; verify it resolves.
2. Switch signing to s2 in your ESP or mail server. New mail now carries s=s2 signatures; receivers look up the new record.
3. Grace period, leave s1 published for ~72 hours. Mail signed before the switch is still in transit and in queues; its signatures reference s1 and must stay verifiable.
4. Revoke, then remove s1. Publishing the record with an empty key (p=) explicitly revokes it, the RFC-blessed way to say "no longer valid", then delete it at leisure. Next rotation: back to s1.

No overlap gap, no window where mail fails. The only failure mode is skipping step 3 and invalidating in-flight mail, 72 hours of patience is the whole trick.

Check what you're running today

Most people don't know their own key length, it was set once, by someone, a while ago. Run your domain through our free domain checker: it probes 35 common DKIM selectors, shows every published key with its algorithm and length, and flags weak or revoked ones alongside the rest of your authentication stack. And because a vendor rotating keys out from under you is one of the classic ways DKIM breaks between checks, Inboxight monitors your selectors continuously and alerts you the moment a signature stops validating, before the spam folder tells you instead.

FAQ

How do I find out my current DKIM key length?

Query your selector's TXT record (dig s1._domainkey.yourdomain.com TXT) and decode the p= value's length, or skip the math: a domain checker that probes common selectors will report each key's algorithm and bit length directly. If you don't know your selector, check a sent message's headers for the s= tag in DKIM-Signature.

Is a 1024-bit DKIM key still acceptable in 2026?

It passes validation, and Gmail still accepts it as a floor, but it's been deprecated by NIST for over a decade and sits within plausible reach of well-funded attackers. There's no reason to keep it: rotation to 2048 is zero-downtime and free. Treat 1024 as technical debt with a due date.

How often should DKIM keys be rotated?

Every 6–12 months as a routine, and immediately after any trigger: a vendor breach, infrastructure staff departure, key exposure, or unexplained DKIM passes in your DMARC reports. If your DKIM is CNAME-delegated to your ESP, check their policy, many rotate managed keys for you.

Does rotating DKIM keys break email already in transit?

Not if you use the selector procedure: publish the new key under a new selector, switch signing, and keep the old selector's record published for ~72 hours so in-flight messages still verify. The only way rotation breaks mail is deleting the old record the moment you switch.

Should I use Ed25519 instead of RSA?

Not instead, alongside. Ed25519 (RFC 8463) is technically superior, but receiver support is still incomplete, so Ed25519-only mail fails where it isn't understood. Dual-sign with RSA-2048 plus Ed25519 if you want to adopt it; RSA-2048 alone remains a fully defensible choice.

Further reading: Why your emails go to spam · How to read a DMARC report · DMARC from p=none to p=reject · Check your DKIM keys · Setup guides by ESP