DKIM key rotation: why, when and how (without breaking anything)

A DKIM key that never changes is a key that ages. Like any cryptographic secret, a DKIM private key benefits from being renewed regularly: the longer it lives, the larger the exposure window if it leaks, and the more likely it is to be of insufficient size as the years pass. Yet rotation scares people: done badly, it breaks signatures and sends your legitimate mail to failure. This guide explains why to rotate your keys, how often, and above all how to do it cleanly with the dual-selector method.

Why rotate your DKIM keys

Three reasons justify rotation:

• Limit the exposure window. If a private key leaks (a compromised server, a poorly protected config file), an attacker can sign mail in your name until you change the key. Regular rotation bounds that risk in time.
• Keep up with cryptographic state of the art. A 1024-bit key set years ago is now considered weak. Rotation is the chance to move to 2048 bits (see 1024 or 2048 bits).
• Good hygiene and compliance. Many security frameworks expect periodic rotation of secrets. DKIM is no exception.

How often

There's no number carved in stone, but reasonable benchmarks: a rotation every six months to a year is a good cadence for most organizations. Shorter if you handle very sensitive secrets or if an internal policy requires it; longer is risky, because the key ages. The right instinct isn't so much the perfect frequency as the systematic nature: a planned rotation, not a gesture you put off indefinitely.

The dual-selector method (no downtime)

Here's the heart of the matter. Safe rotation rests on the fact that a domain can have several selectors active at the same time (see the selector). The sequence:

1. Generate a new key under a new selector (say s2), and publish its public key in DNS — without touching the old selector (s1).
2. Let it propagate and verify the new public key is visible everywhere.
3. Switch signing on the platform side so it now signs with s2.
4. Monitor for a few days: confirm the new signatures (s2) pass and align in your aggregate reports.
5. Remove the old selector (s1) — but only after a sufficient delay.

Throughout the transition, both selectors coexist: mail signed with the old key stays verifiable, and so does the new. That overlap is what makes rotation downtime-free.

The trap to absolutely avoid

The classic mistake is removing the old selector too early. Mail signed with the old key may still be in transit, queued, or stored for delayed sending. If you delete its selector before it's all delivered, its signature fails verification — even though it's perfectly legitimate. The rule: leave the old selector in place for several days after switching signing, long enough for all the old mail to be processed. Better one extra selector for a few days than a broken signature.

Manual or automated rotation

Two approaches, depending on your setup:

• Automated. If you sign via a platform that offers the CNAME (Microsoft 365, many SaaS), rotation is often handled for you: the provider rotates the key behind the CNAME you published once. That's ideal — you have nothing to do.
• Manual. If you operate your own infrastructure or publish hard-coded TXT records, you drive the rotation yourself, following the dual-selector sequence above. It's more work, but perfectly doable with a written procedure and a schedule.

Where to store your DKIM private keys

Rotation is pointless if your private keys are lying around in an accessible config file or an email. The DKIM private key is a critical secret: anyone who obtains it can sign mail in your name. It therefore deserves the same care as any production secret — encrypted storage, audited access, tooled rotation.

DMARC.com is published by Hucency, a cybersecurity company; to centralize and encrypt this kind of secret — DKIM private keys, DNS credentials, API tokens — and orchestrate their rotation, take a look at Hucency Vault. A good DKIM rotation policy assumes a safe place where the keys live; the vault is that often-neglected link.

Building a rotation schedule

The best rotation is the one you don't have to remember to do. Rather than relying on memory, put DKIM rotation on a security calendar, just like TLS certificate renewal. A semi-annual or annual cadence, noted in advance, turns an anxiety-inducing gesture into a predictable routine. Document the procedure once — which selector, which platform, which key size, how many overlap days — and each subsequent rotation is just an execution, not a reinvention. For domains with several platforms, stagger the rotations rather than doing them all on the same day: you limit the risk surface if a switch goes wrong, and you keep attention available to watch each transition one at a time.

Emergency: a compromised key

Planned rotation is one thing; emergency rotation is another. If you have any reason to think a private key has leaked — a compromised server, an exposed backup, a provider departing with access — don't wait for the planned deadline: rotate immediately. The sequence stays the same (new selector, new key, switch signing), but you shorten the overlap and revoke the old key as soon as possible by publishing an empty p= at its selector, which invalidates any signature claiming it. A compromised key left alive is an open door to signed impersonation: the attacker can produce messages that pass DKIM in your name, the worst possible scenario. Treat it like a leaked password — rotate and revoke without delay — and document the incident for traceability.

Verify a rotation went well

After a rotation, two checks are enough:

1. The new selector signs and aligns: your reports should show s2 signatures passing. See how to verify an email signature.
2. No legitimate signature breaks during the transition: watch for the absence of sudden DKIM failures on your real sources.

Our free analyzer confirms the presence and validity of your public keys at the current selector, a useful glance right after a switch.

Frequently asked questions

How often should I renew? Every six months to a year for most cases. What matters is that it's planned and systematic, not the perfect frequency.

Does rotation interrupt sending? No, if you follow the dual-selector method: both keys coexist during the transition, so there's no interruption.

When can I remove the old selector? Several days after switching signing, long enough for all the old mail to be delivered. Removing too early breaks legitimate signatures.

Does my platform handle rotation? If you published a provider-supplied CNAME, probably yes. If you publish hard-coded TXT records, it's on you to drive it.

Do I need to change selector at each rotation? Yes, that's the whole point: a new key under a new selector enables the overlap without downtime. Reusing the same selector for a new key creates a window where signatures fail.

What's the right overlap period between old and new selectors? Three to five days covers most cases: it's long enough for queued or delayed mail to drain, and short enough not to complicate the next rotation. If you have very long mail queues or retry windows (some servers retry for up to 72 hours), go a full week to be safe. When in doubt, err on the side of longer overlap — removing a selector is a one-click operation, but fixing broken signatures mid-flight is not.

DKIM and compliance: what frameworks expect

If you operate in a regulated environment — finance, healthcare, public sector — DKIM key rotation may no longer be just a best-practice choice, but a documented requirement. Frameworks like ISO 27001 (cryptographic controls §A.10) or NIS2 expect a secrets management policy that includes periodic renewal. A DKIM key set five years ago and never renewed is hard to defend in an audit. Traceability matters too: who generated the key, when, what size, what's the next rotation date — all things auditors can ask for. Keeping a simple DKIM rotation log (date, selector, platform, size) gets you out of these situations effortlessly, and shows that email security is managed, not left to chance. It isn't much work, but it's exactly what separates "we handle it" from "we document that we handle it." The same log also serves as a runbook for whoever has to deal with rotation next — including a future you who has forgotten the details.

Let Thomas pace your rotations

A forgotten rotation lets a key age; a botched rotation breaks signatures. Thomas, your virtual CISO, tracks the age of your DKIM keys, reminds you when it's time to rotate, guides you through the dual-selector sequence, and verifies on your reports that the switch happened without breakage.

Analyze your domain for free → or create an account for DKIM keys that stay fresh and well guarded.