Can I just update the key on my existing DKIM selector?

No, that's the one thing to avoid. Editing a live selector's public key instantly invalidates any mail already signed with the old key that's still in transit or queued, causing dkim=fail. Always publish a new selector and cut over to it.

How long should I keep the old DKIM selector published?

One to two weeks is a safe overlap. Delayed, retried, and queued messages may still carry a signature made with the old key, and they need the old public record in DNS to verify. Remove it only once no live mail depends on it.

Does rotating DKIM keys hurt my sending reputation?

No. Reputation is tied to your domain and signing domain (d=), which rotation doesn't change. As long as messages keep passing DKIM through the overlap, receivers see continuous authenticated mail and reputation is unaffected.

DKIM Key Rotation: How and When to Rotate Your Keys

VigilDog Team · September 13, 2026 · 6 min read

Your DKIM private key is a long-lived secret sitting on a mail server, and like any secret it's worth rotating. Done right, rotation is invisible to recipients. Done in place, by editing the existing key, it bounces mail. This guide walks the safe, zero-downtime way to rotate DKIM keys and how to keep DMARC happy while you do it.

Why rotate DKIM keys at all

DKIM signs your outbound mail with a private key and publishes the matching public key in DNS, so receivers can verify a message really came from your domain and wasn't altered in transit. That private key lives on a mail server or inside an ESP, and the longer it exists the more chances it has to leak.

You rotate DKIM keys for three reasons: to limit the blast radius if a private key is ever exposed, a leaked key lets anyone forge signed mail as you until it's retired, to retire weak keys by moving a legacy 1024-bit RSA key up to 2048-bit, and for plain hygiene when you change ESPs or on a regular schedule. Handled correctly, DKIM key rotation is something recipients never notice.

How selectors make rotation safe

The mechanism that makes zero-downtime rotation possible is the selector. Every DKIM signature names a selector in its header, and that selector points to a specific DNS record: selector._domainkey.example.com. You can publish many selectors at once, each carrying its own public key.

So rotation is never about editing an existing key in place, it's about standing up a new selector alongside the old one, moving your signing over to it, and only then removing the old record. Both keys stay valid during the overlap, so mail signed with either one continues to verify.

How SPF, DKIM and DMARC verify an email

Step-by-step: a zero-downtime rotation

The whole rotation is an overlap: publish new, cut over, retire old.

Generate a fresh 2048-bit keypair: openssl genrsa -out s2.private 2048, then extract the public key, or let your ESP generate it and hand you the DNS record.
Publish the public key under a new selector, e.g. s2._domainkey.example.com as a TXT record: v=DKIM1; k=rsa; p=MIIBIj.... Leave the old selector's record untouched.
Wait for DNS to propagate and verify it: dig +short TXT s2._domainkey.example.com. A 2048-bit key exceeds the 255-character TXT limit, so it's split into multiple quoted strings, that's normal, not a bug.
Switch your MTA or ESP to sign with the new selector. Send a test message and inspect the headers for dkim=pass in Authentication-Results, with header.s=s2.
Keep the old selector published for one to two weeks. Queued, delayed, and retried mail may still carry the old signature, and removing it early makes that mail fail DKIM.
Once no live mail depends on it, delete the old TXT record. Rotation complete.

How often, and which algorithm

There's no single universal mandate, but sensible cadence and settings look like this:

Rotate every 6–12 months for keys you manage yourself, and rotate immediately if you suspect exposure or when offboarding whoever had server access.
Use 2048-bit RSA. A 1024-bit key still verifies but is considered weak and some receivers distrust it; anything shorter, replace now.
ed25519 keys (RFC 8463) are shorter and modern, but not every receiver verifies them yet. If you adopt ed25519, publish an RSA selector too so both sign each message and there's always a key everyone can check.
If your ESP offers managed or rotating DKIM keys, let it handle rotation, just confirm it's actually using 2048-bit or ed25519 under the hood.

Don't break DMARC while you rotate

DKIM doesn't stand alone. DMARC decides what happens when authentication fails, and it requires alignment: the DKIM signing domain (d=) must line up with the domain in the From header. Rotation keeps d= the same, so alignment is preserved as long as you use a new selector rather than editing the old key.

The danger is a botched overlap. Remove the old selector too early, while mail signed with it is still in flight, and those messages get dkim=fail. If SPF is also misaligned on that path, DMARC fails outright, and under a p=reject policy the mail is bounced. So verify dkim=pass on the new selector before you retire the old one, and confirm your posture with the DMARC checker after the switch.

Continuous email deliverability monitoring closes the loop: it watches your SPF, DKIM selectors, and DMARC records and alerts you if a rotation leaves a key missing or a record malformed, before receivers start rejecting your mail.