DKIM key length and rotation

Updated 2026-08-05 · Troubleshooting

Two questions come up once DKIM is working: is my key long enough, and do I need to change it periodically? Both have practical answers, and both have a failure mode that is easy to walk into.

For what a key is and where it lives, see What is a DKIM selector?.

DKIM key length: 1024 vs 2048

The 1024 vs 2048 DKIM question is settled by RFC 8301, which sets the floor at 1024 and recommends a DKIM 2048-bit key. Verifiers still validate 1024-bit signatures, so a domain running one is not losing mail today — but 1024 is considered weak, and upgrading belongs on the list rather than in a panic.

4096-bit is where diminishing returns arrive: the record becomes long enough to hit DNS limits reliably, and signing costs more, for a margin nobody is attacking.

Why 2048-bit keys break some DNS panels

A single DNS TXT string cannot exceed 255 characters. A 2048-bit public key does not fit, so the record has to be published as multiple strings inside one record:

selector._domainkey  TXT  ( "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
                            "...AQAB" )

Receivers concatenate the strings before parsing, so this is correct and expected. What breaks is the paste: a panel that accepts only one string, or an administrator who splits it across two records instead of two strings, produces a key that never verifies.

Most managed providers (Google Workspace, Microsoft 365, the large ESPs) generate the key and hand you a value that is already formatted for this. Trouble is concentrated in hand-run mail servers and older DNS control panels.

If a panel genuinely cannot store a 2048-bit key, that is a reason to move DNS, not a reason to stay at 1024 permanently.

DKIM key rotation: what it is actually for

Rotation limits the damage from a private key you did not know was exposed — a leaked backup, a decommissioned server, a departed administrator. It is hygiene, not an urgent defence, and for most domains once or twice a year is a sensible cadence.

Two situations turn it from hygiene into a task with a deadline:

• You suspect the key was exposed. Rotate now.
• You are leaving a provider. Their signing key should stop being valid for your domain.

Some large senders rotate monthly with automation. If you are hand-editing DNS, that cadence buys very little and adds many chances to make the mistake below.

The gap that breaks mail

Here is the failure mode. Somebody generates a new key, replaces the DNS record, and switches signing — all at once.

Every message already in flight was signed with the old key. Its selector record is now gone, so those messages cannot be verified and they fail DKIM at delivery. Depending on your policy and whether SPF is aligned, some of them are rejected.

To rotate DKIM key material safely, overlap the old and new selectors rather than overwriting:

1. Generate a new key under a new selector — 202608 if you date them, or selector2 if you alternate.
2. Publish the new selector's record. Both are now live; nothing signs with the new one yet.
3. Wait for DNS propagation — at least the record's TTL, and in practice a few hours.
4. Switch signing to the new selector at the sending platform.
5. Watch the reports until DKIM results show the new selector passing.
6. Wait several days, then remove the old record. Mail in retry queues can be days old.

Never reuse a selector name for a new key. That collapses steps 2 and 6 into one moment and reintroduces the gap you were avoiding.

This overlap is exactly why Microsoft 365 publishes selector1 and selector2: it alternates between them, so a rotation is a switch between two records that both already exist. Publishing only one of the pair produces intermittent failures on roughly half the mail — a symptom listed in Why DKIM fails.

Revoking a DKIM key

To revoke a DKIM key rather than delete it, publish the record with an empty p=:

selector._domainkey  TXT  "v=DKIM1; k=rsa; p="

An empty p= means revoked: signatures using it must be treated as failing, which is a stronger and clearer statement than a missing record (which can also mean a DNS problem). Use it when a key is known to be compromised. For ordinary rotation, deleting the old record after the overlap is enough.

Confirming a rotation worked

The reports show which DKIM domain and result each source produced, so a rotation is verifiable rather than hopeful: within a day you should see the new selector passing and the old one disappear. How to read a DMARC report covers that view.

And the same caution applies as everywhere else in DKIM: a signature that verifies still earns nothing if it is not aligned with your From domain — DMARC alignment explained.