Why 1024-bit DKIM keys are being phased out

What "1024-bit" actually refers to

DKIM signs each outbound message with a cryptographic key — the receiving mail server fetches your public key from DNS and uses it to verify the signature. The "1024-bit" or "2048-bit" refers to the size of the underlying RSA key.

Bigger keys are mathematically harder to factor. 1024-bit RSA was the standard DKIM default for a long time because key size was constrained by DNS UDP packet limits (large public keys won't fit in a single UDP response). Almost every modern resolver supports DNS-over-TCP fallback now, so the 1024-bit ceiling is a historical artifact rather than a real constraint.

Who's deprecating it, and when

• NIST deprecated 1024-bit RSA for digital signatures in 2013 (Special Publication 800-131A). That's the U.S. government body that effectively sets cryptographic standards everyone else follows.
• Google began surfacing warnings about 1024-bit DKIM keys to recipients in 2024, as part of their bulk-sender enforcement push. Mail still gets delivered, but the trust signal is degraded.
• RFC 8301 (2018) explicitly removed 1024-bit support from the DKIM specification's recommended set. The minimum key size in the modern spec is 2048-bit RSA, with Ed25519 as a smaller-and-stronger alternative.

None of this means a 1024-bit key fails outright today. It means you're on a slow ramp toward "this signature is no longer considered authoritative" — and the ramp steepens every year.

What to rotate to

The current safe choice is RSA 2048-bit. It works everywhere, every ESP supports it, every receiver verifies it. Most ESP admin UIs default new selectors to 2048-bit now.

If you have the option, Ed25519 (RFC 8463) is the modern alternative. It's stronger than 2048-bit RSA at a fraction of the byte count — your DNS record stays short, signing and verification are faster, and there's no looming "we need to move to 4096-bit eventually" treadmill. The catch: Ed25519 DKIM is supported by major mailbox providers but not universally, so most senders still publish an RSA selector alongside it for compatibility.

Don't bother with 4096-bit RSA. The marginal security benefit doesn't justify the DNS payload size; if you want stronger than 2048-bit, jump to Ed25519.

The rotation playbook

You can't "upgrade in place." DKIM keys are tied to a selector — a label like k1 or selector1 in the DNS hostname <selector>._domainkey.example.com. Rotating the key means introducing a new selector, switching your sender to use it, and eventually retiring the old one. Done in the right order, no mail breaks.

Step 1: Generate a new 2048-bit key in your ESP

Almost every ESP has a "Rotate DKIM" or "Add new key" option in the admin UI:

• Google Workspace: Apps → Google Workspace → Gmail → Authenticate email. Generate a new key with 2048-bit selected (newer accounts default to this).
• Microsoft 365: Microsoft 365 Defender → Email & collaboration → Policies & rules → Email authentication → DKIM. Click "Rotate DKIM keys" for your domain — Microsoft handles the selector dance for you.
• Mailchimp / SendGrid / Mailgun / Postmark: each has a "DKIM" or "Email authentication" panel. Look for a "Rotate" or "Generate new key" action. Most allow you to publish a new selector without disturbing the old one.

Step 2: Publish the new selector's TXT record in DNS

The ESP gives you a hostname like k2._domainkey.acme.com and a long public-key string. Publish the TXT record. Don't touch the existing record yet — it's still signing live mail.

Step 3: Tell the ESP to start signing with the new selector

Some ESPs do this automatically once they detect the new TXT record. Others require you to manually flip a switch ("activate" or "set as primary"). After this step, all new outbound mail is signed with the 2048-bit key.

Step 4: Wait at least 7-14 days

Mail in flight may still reference the old selector via cached DNS or in-transit signatures. Leave the old selector's TXT record in place for at least one full DMARC aggregate-report cycle (typically 24h, but mail systems can buffer for days). 7-14 days is the conservative window most teams use.

Step 5: Remove the old selector's TXT record

Once you're confident no live mail is being signed with the old selector — you can verify in DMARC reports that the new selector is the only one appearing in DKIM results — delete the old TXT record. You're now fully on 2048-bit.

Things to watch out for

Don't delete the old selector before the rotation completes

If you publish the new TXT but delete the old one before the ESP starts signing with the new selector, all in-flight mail signed with the old selector will fail DKIM verification. Wait for confirmation.

Watch DMARC reports for unsigned mail

Some legacy senders or shadow-IT tools may still be configured against the old selector. If your DMARC reports show "Unknown" senders or DKIM failures from sources you thought were rotated, those senders need their own rotation cycle — not just a DNS flip.

Test mode (t=y) is not the rotation flag

Some ESPs publish new selectors with t=y in the DKIM record, which tells receivers "this signature is testing only — ignore failures." That's fine during the rotation but you must remove t=y once the new selector is in production. Otherwise receivers will keep ignoring valid signatures from the new key — which means you've effectively still got no DKIM enforcement.

Don't have DKIM published yet?

Then rotation isn't your problem — publishing is. Most modern ESPs walk you through first-time DKIM setup in their authentication UI. Generate the key, publish the TXT record, wait for the ESP to verify, and you're done. Start at 2048-bit so you don't have to do this dance again in two years.

Related

• DKIM verifier — auto-scans common ESP selectors and surfaces 1024-bit keys.
• DMARC alignment, in plain English — why a strong DKIM key matters even when SPF passes.
• What is DMARC? — the 5-minute primer.