DKIM key rotation — how to rotate without breaking mail

A DKIM key isn't something you set once and forget. Keys age, secrets can leak, and a signature that's valid forever is a standing risk. Rotation is how you keep DKIM healthy — and the only trick to it is not breaking verification while you do it. Get the overlap right and rotation is invisible to receivers; get it wrong and you can silently fail authentication for days.

Why rotate

The private half of your DKIM key pair is a secret that signs every message as your domain. If it never changes and is ever exposed, it can be abused indefinitely. Rotating periodically bounds that exposure window — the same hygiene you'd apply to any long-lived credential. It's not about deliverability gains; it's about not leaving a permanent key lying around.

How often to rotate

There’s no single mandate, but the practical consensus is clear: rotate every six to twelve months for 2048-bit keys, leaning toward six — or quarterly — for higher-volume or sensitive mail. Industry guidance from M3AAWG puts the floor at every six months, and a conservative shop can run a 90-day cycle. Regulated senders (healthcare, finance) and anyone who’s had a security incident should rotate more aggressively.

Two cadences sit outside the routine. Emergency rotation happens immediately on any suspected private-key exposure — a server breach, unauthorised access, a departing vendor who held your keys — not on the next scheduled date. And the worst “cadence” is the common one: never. Plenty of organisations set DKIM up once and rotate only when a server or vendor changes, leaving the same key live for years. The right answer is a schedule you can actually keep — a 180-day cycle you execute beats a 90-day policy you never run.

Selectors make it safe

DKIM keys live under selectors — selector._domainkey.yourdomain — and every message records which selector signed it. That's what makes zero-downtime rotation possible: you can publish a second selector and run both at once, so receivers always find the key matching whatever selector a given message used. Rotation is really just an orderly handover between selectors.

Use 2048-bit keys

Generate new keys at 2048-bit RSA. 1024-bit keys are weak and viewed unfavourably by some receivers, so rotation is also a good moment to make sure you're on a modern key size. A correctly configured setup produces 2048-bit keys by default — including the per-domain keys the Configurator generates.

The reasoning behind 2048 is a balance. Shorter keys are dangerous: 512-bit RSA has been cracked for a few dollars of cloud compute, and 1024-bit is now considered weak — RFC 8301 sets 1024 as the bare minimum and 2048 as the practical target. But bigger isn’t automatically better in practice: some widely-deployed mail gateways (Cisco’s, notably) don’t accept keys above 2048 bits, so a 4096-bit key can actually cause verification failures at some receivers. That makes 2048-bit RSA the sweet spot between strength and compatibility — strong enough to trust, universally supported.

One practical wrinkle: a 2048-bit public key is long enough to exceed the 255-character limit of a single DNS TXT string, so it must be split into multiple quoted strings within the same record. Most DNS providers handle this automatically, but a hand-entered key that isn’t split correctly is a classic cause of a “key published but DKIM still fails” puzzle.

The overlap process, concretely

The whole rotation is five ordered moves, and the order is what protects you. Generate a fresh key pair under a new selector, publish its public half in DNS while the old record stays put, switch signing to the new selector, verify it passes, and only then — after a drain period — remove the old record:

# 1. generate a new 2048-bit key pair under a new selector
openssl genrsa -out s2026b.private 2048
openssl rsa -in s2026b.private -pubout -out s2026b.public

# 2. publish the public key in DNS alongside the old selector
s2026b._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."

# 3. point the MTA’s signing at selector s2026b, then
# 4. verify dkim=pass on a real test, 5. drain, then remove the old record

At no point is there a gap: because each message carries the selector it was signed with, receivers always find a matching public key — the old selector’s for mail signed before the switch, the new selector’s for mail signed after. The handover is invisible to them precisely because both keys are live during the overlap.

The drain period, and why it matters

The drain is the gap between switching signing to the new selector and removing the old selector’s DNS record, and it exists because mail doesn’t all get verified the instant you send it. A message can sit in a queue, be retried over hours, or be forwarded and re-checked downstream — and whenever it’s finally verified, the receiver looks up the selector that message was signed with. If you’ve already deleted that selector’s key, the lookup fails and so does DKIM, even though nothing about the message changed.

So you keep the old record live long enough to cover the slowest realistic verification. Forty-eight hours is a bare minimum; seven to fourteen days is the safer default, and longer if your streams have slow queues or heavy forwarding. A useful preparatory step is to lower the DNS TTL on the records before a planned rotation so changes propagate quickly, then restore the normal TTL once authentication looks steady on the new selector. Patience here costs nothing; haste costs you delivery on mail you already sent.

Unique selectors and why naming matters

Every rotation should introduce a brand-new selector name rather than overwriting an existing one. Two reasons. First, a new name is what creates the overlap — overwrite the live selector’s key in place and there’s no second record to fall back on, so you’ve reintroduced the gap the whole process avoids. Second, distinct names keep your header forensics readable: when you can see exactly which selector signed a message, you can tell which key generation it belongs to and when it was sent.

A simple convention makes this painless — encode a date or a sequence in the selector, so the records read as an obvious progression rather than a pile of cryptic names. It’s worth recording selector ownership and rotation dates somewhere outside DNS too, so an audit doesn’t depend on you remembering what each name meant. The selector is cheap; a clear naming scheme turns rotation history into documentation you can actually read later.

Provider and engine specifics

A couple of platform quirks trip up otherwise-careful rotations. On Microsoft 365, triggering a rotation doesn’t start signing with the new key immediately — Microsoft documents a delay of up to 96 hours, so don’t assume the switch is live the moment you click it. On Google Workspace, admins often leave the default selector in place forever; it works, but you lose the forensic clarity of distinct selectors over time. Know your platform’s timing before you plan the drain.

On a self-hosted PowerMTA or KumoMTA, rotation is a configuration step you fully control: you generate the new key, add the new selector to your signing configuration, publish the DNS record, switch the active selector, and remove the old one after the drain. Because you own both the signing config and (usually) the DNS automation, the whole sequence can be scripted — which is what turns rotation from a nervy manual chore into a routine, repeatable job.

Emergency rotation

Routine rotation is calendar-driven; emergency rotation is incident-driven, and it follows different rules. The moment you suspect a private key has been exposed — a compromised server, unauthorised access to where keys are stored, or offboarding a vendor who held them — you rotate now, not at the next scheduled slot. A leaked key lets an attacker sign mail as your domain until it’s revoked, so the exposure window is exactly as long as you take to act.

The wrinkle is that emergency rotation trades a little verification risk for security: you may need to retire the compromised selector faster than a full drain would normally allow, accepting that some in-flight mail signed with the old key could fail rather than leave a known-bad key live. That’s the right trade in a real incident, but it’s a decision you want to have thought through in advance. Keep the emergency steps written down — where the keys live, how to generate and publish a new selector, how to switch signing — before you need them, because an active compromise is the worst time to be improvising the procedure.

The real problem: nobody owns DKIM

Most organisations don’t have a DKIM technology problem — 2048-bit keys are strong — they have an ownership problem. DNS is run by IT, the mail-signing configuration lives with the messaging team, and security sets the policy but touches neither system. Each group assumes another owns rotation, so it never happens, and perfectly good setups end up sitting on keys that haven’t changed since the day they were created.

The inertia is reinforced by fear: touching DKIM risks breaking mail, broken mail means unhappy stakeholders, so the safest-feeling choice is to leave it alone — which is precisely the choice that lets a key age into a liability. The fix is organisational, not technical: assign one owner, put rotation on a calendar with a defined procedure, and the risk largely evaporates. A documented, scheduled rotation that one person is accountable for beats the most sophisticated key the team is too nervous to ever replace.

Mistakes to avoid

The failure modes are well-worn and all avoidable. Removing the old selector too early is the classic, breaking DKIM for mail already in flight. Publishing a new key without a test send leaves selector or DNS-typing errors undiscovered until real mail fails. Reusing selector names destroys the overlap and the audit trail. Keeping 1024-bit keys forever trades a one-time setup convenience for a growing security backlog. And never rotating at all — the most common of the lot — leaves a permanent key exposed for years.

Every one of these is prevented by the same disciplined sequence: new selector, publish alongside, switch, verify with a real test, drain, then remove — on a schedule someone owns. The procedure isn’t complicated; the discipline of following it every time is the whole game. Run through it the same way on every rotation — the same checklist, the same verification, the same drain — and what feels risky the first time becomes a routine maintenance task you can hand to anyone with the runbook in front of them. That repeatability is the real goal: not a heroic one-off rotation, but a dull, dependable one you can run on schedule without a second thought, which is exactly the kind of task that actually keeps getting done instead of slipping quietly off the calendar the way an intimidating, undocumented one never fails to, year after year, until a key is far older than anyone ever intended it to be, and the once-simple fix has quietly turned into the thing nobody wants to touch.

Rotation is one piece of DKIM hygiene

Rotation sits inside a small set of DKIM practices that reinforce each other. Sign all outbound mail — and make sure the signature covers the From header, since that’s what DMARC alignment checks. Use separate selectors and keys for different mail streams, so your transactional and marketing signing are independent and a rotation or problem on one doesn’t disturb the other. And keep new keys at 2048-bit. Rotation is the maintenance habit that keeps this set current rather than a one-time configuration that quietly ages.

Monitoring ties it together. Watch your DMARC aggregate reports during and after a rotation: they confirm that mail is passing DKIM on the new selector and surface any source that didn’t make the switch cleanly. A rotation isn’t “done” when you flip the selector — it’s done when the reports show clean DKIM on the new key and you’ve safely retired the old one. That feedback is also how you catch the subtle failures, like a stream you forgot was signing with the old selector, before they turn into alignment problems.

Seen this way, rotation isn’t an isolated chore but the recurring checkpoint where you re-verify that your whole DKIM setup — key strength, selector layout, signing coverage, alignment — is still sound. Doing it on schedule is what keeps authentication from drifting out of date without anyone noticing.

The bottom line

DKIM key rotation keeps a long-lived signing secret from becoming a permanent liability, and the only real skill is doing it without a verification gap. Overlap selectors: generate a new 2048-bit key under a fresh selector, publish it alongside the old one, switch signing, verify a real message passes, let the old selector drain for a week or two, then remove it. Use 2048-bit RSA (strong and universally compatible), rotate every 6–12 months — sooner for sensitive mail — and rotate immediately on any suspected exposure.

Mind the details that bite: keep the old record live through the drain, never reuse selector names, watch for platform timing quirks, and remember that under p=reject a botched rotation drops mail rather than flagging it. Most of all, give rotation an owner and a calendar, because the real DKIM risk isn’t weak keys — it’s keys nobody ever rotates. If you’d rather not run the procedure by hand, the Auto PMTA Configurator generates 2048-bit DKIM per domain and publishes it through the Cloudflare API at deploy, making rotation a managed step rather than a scramble. Set it up once with strong keys and a clear selector scheme, give the recurring rotation an owner and a date, and DKIM quietly does its job year after year instead of becoming the stale, single-owner-less risk it is at most organisations — for legitimate, opt-in sending.