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

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. Generating a new key under a new selector (say s2), and publishing its public key in DNS — without touching the old selector (s1).
2. Letting it propagate and verifying that the new public key is visible everywhere.
3. Switching signing on the platform side so it now signs with s2.
4. Monitoring for a few days: confirming the new signatures (s2) pass and align in the aggregate reports.
5. Removing 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. Deleting its selector before it's all delivered makes its signature fail verification — even though it's perfectly legitimate. The rule: the old selector stays in place for several days after signing switches, long enough for all the old mail to be processed. Better one extra selector for a few days than a broken signature.

The other extreme: ghost selectors

Removing too early breaks signatures; never removing creates a different problem. An old selector left published indefinitely remains a valid key in the eyes of receivers: anyone holding the matching private key — a forgotten backup, a decommissioned server, a departed provider — can still sign verifiable mail in the domain's name, years later. Every rotation should therefore end with the actual removal of the old DNS record, once the overlap period has passed. A complementary good practice: an inventory of the selectors actually published on the domain, reviewed from time to time. Ghost selectors accumulate silently as platforms get tried and then abandoned, and each one is a potential back door that no report will ever flag on its own.

Manual or automated rotation

Two approaches, depending on the setup:

• Automated. Signing via a platform that offers the CNAME (Microsoft 365, many SaaS) usually means rotation is handled upstream: the provider rotates the key behind the CNAME published once. That's ideal — nothing left to do.
• Manual. Own infrastructure, or hard-coded TXT records, means driving the rotation in-house, following the dual-selector sequence above. It's more work, but perfectly doable with a written procedure and a schedule.

Where to store the DKIM private keys

Rotation is pointless if the 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 the domain's 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, Hucency Vault is worth a look. 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 nobody has to remember. Rather than relying on memory, DKIM rotation belongs 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. Documenting the procedure once — which selector, which platform, which key size, how many overlap days — makes each subsequent rotation an execution, not a reinvention. For domains with several platforms, staggering the rotations rather than doing them all on the same day limits the risk surface if a switch goes wrong, and keeps attention available to watch each transition one at a time.

Emergency: a compromised key

Planned rotation is one thing; emergency rotation is another. Any reason to think a private key has leaked — a compromised server, an exposed backup, a provider departing with access — overrides the planned deadline: rotation happens immediately. The sequence stays the same (new selector, new key, switch signing), but the overlap shortens and the old key gets revoked 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 the domain's name, the worst possible scenario. It's a leaked password by another name — rotate and revoke without delay — and the incident gets documented for traceability.

Verifying a rotation went well

After a rotation, two checks are enough:

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

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

Frequently asked questions

How often should renewal happen? 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, not with the dual-selector method: both keys coexist during the transition, so there's no interruption.

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

Does my platform handle rotation? With a provider-supplied CNAME published, probably yes. With hard-coded TXT records, the rotation has to be driven in-house.

Does the selector have to change 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. Very long mail queues or retry windows (some servers retry for up to 72 hours) call for a full week to be safe. In case of doubt, the longer overlap wins — removing a selector is a one-click operation, but fixing broken signatures mid-flight is not.

DKIM and compliance: what frameworks expect

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. A simple DKIM rotation log (date, selector, platform, size) settles 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 its own author, months later, with the details forgotten.

Thomas paces the rotations

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

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