DKIM keys should be rotated quarterly as part of routine email hygiene. This tutorial walks through the full rotation process — generating the new key, publishing in DNS alongside the old one, switching the signer over, and finally revoking the old selector. Covers on-premises mail servers and hosted platforms used by UK businesses.
DKIM keys are long-lived by design, but long-lived keys accumulate risk. Every day a private key sits on a server, the probability it has been exfiltrated creeps up slightly — through a forgotten backup, an improperly disposed-of host, a compromised admin credential, or a malicious insider. Rotating the key on a regular cadence caps the exposure window: even if a rotation-1 key has been stolen, the attacker's window to use it closes when the rotation switches the signer to the new selector.
NCSC Email Security guidance treats key rotation as part of routine hygiene. PCI DSS 4.0 references cryptographic key management for cardholder-data handlers. ISO 27001 cryptographic controls expect documented rotation procedures. For any UK business subject to these frameworks, a documented DKIM rotation cadence is an audit-ready control.
| Context | Recommended cadence |
|---|---|
| Modern UK business, 2048-bit RSA | Quarterly (every 90 days) |
| High-assurance (financial, healthcare) | Monthly to quarterly |
| Ed25519 keys | Quarterly (shorter keys are not faster to compromise, but hygiene norms apply) |
| After any suspected compromise | Immediately — emergency rotation |
| Legacy RSA-1024 (still present) | Immediately — rotate to 2048 and retire 1024 |
Annual rotation is acceptable for very small senders or where operational constraints make quarterly impractical, but it is not the modern best practice.
Rotation is not a cut-over; it is an overlap. The three states:
p=) or removed from DNS.The overlap exists because email in flight may still reference the old selector. Messages delivered to a mailbox a week ago, then later re-verified by the receiver (some archival systems do this), would fail if the old public key has disappeared.
The same mechanics as initial setup. Pick a new selector name — most UK teams use a date-based pattern like 2026q3 following the current 2026q2.
# RSA-2048
openssl genrsa -out 2026q3.private 2048
openssl rsa -in 2026q3.private -pubout -outform DER 2>/dev/null | openssl base64 -AFor Ed25519 keys, use the Ed25519 commands from the DKIM setup guide.
Add a new TXT record at 2026q3._domainkey.firm.co.uk with the new public key. Do not modify or remove the existing 2026q2._domainkey record yet — both must coexist during the overlap.
2026q3._domainkey.firm.co.uk. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqG..."Wait for DNS propagation. Verify with dig:
dig TXT 2026q3._domainkey.firm.co.ukUntil you see the new record being returned, proceed no further.
Update your mail server's DKIM configuration to use the new selector and private key. The exact change depends on your platform:
Edit /etc/opendkim.conf:
Selector 2026q3
KeyFile /etc/dkim/2026q3.privateReload OpenDKIM: systemctl reload opendkim.
Update the dkim_selector and dkim_private_key in /etc/exim4/exim4.conf and reload Exim.
In the admin console, under DKIM Signatures, edit the domain's configuration to reference the new selector and private key file. Save and the change is live immediately.
Both platforms handle rotation internally. You do not intervene — the platform rotates keys and updates the DNS references on its own schedule. For Microsoft 365, the two CNAMEs (selector1 and selector2) remain pointed at the tenant's dynamically-rotated keys.
Rotation is managed by the platform. Customers receive a notification ahead of each quarterly rotation with the new DNS records to publish, and the existing records to retain. After the switch-over, a second notification instructs when the old records can safely be revoked.
Send test messages from the newly-configured signer to an external mailbox. Inspect the Authentication-Results header:
dkim=pass [email protected] header.s=2026q3 header.b=abc123...The selector should be the new one. If it still shows the old selector, the signer has not picked up the new configuration — check the service was reloaded.
Also check that mail signed with the old selector still verifies, for the duration of the overlap. Send a deliberately-old archived message back to the inbox and watch the results.
After 30-60 days of overlap — enough for any in-flight and archived messages to have been re-verified — revoke the old selector. Two options:
2026q2._domainkey.firm.co.uk. IN TXT "v=DKIM1; k=rsa; p="An empty p= explicitly revokes the key. Receivers treat any signature against this selector as failed. This is the preferred pattern because it remains unambiguous about intent.
Simply remove the 2026q2._domainkey record entirely. Receivers performing verification get an NXDOMAIN or no answer, which they handle as dkim=permerror or dkim=none. Functional but less explicit than Option A.
After revocation, delete the old private key from the signer's filesystem (or move it to secure offline archive for forensic purposes).
Quarterly rotation is managed centrally. Customers receive advance notice with DNS records to publish and a cut-over schedule. No manual key handling required.
Microsoft rotates keys automatically. The two CNAME records in your DNS never change — the referenced keys behind them are rotated by Microsoft. You do not intervene.
Google rotates periodically but slower (roughly annually). You can manually trigger rotation via the admin console under Apps → Gmail → Authenticate email → Rotate selector.
Each platform has its own rotation schedule, usually internal. The CNAMEs you publish remain stable; the keys behind them are rotated by the provider.
If you suspect a DKIM private key has been exfiltrated — a stolen laptop, a compromised server, a disgruntled ex-employee — treat it as an incident and rotate immediately. The process is the same as scheduled rotation but compressed:
p=) immediately — do not wait 30-60 days, the compromise risk outweighs the in-flight-verification concern.If the compromise is confirmed (not just suspected), also assume the attacker has been signing messages in your name. Inspect DMARC aggregate reports for the preceding weeks for any IPs you do not recognise — they are the attacker's infrastructure.
Q: How long should the overlap between old and new selectors last?
A: 30 days minimum, 60 days typical, 90 days for high-assurance deployments. The risk during overlap is low — both keys are valid but the signer only uses the new one.
Q: What happens if I forget to revoke the old selector?
A: It continues to work indefinitely — which is bad. A forgotten old selector is an attacker's lottery ticket: if the old private key was ever leaked, messages signed with it continue to verify. Revocation is the security step.
Q: Can I rotate selectors without publishing a new one first?
A: No. There is a brief window after you switch the signer where verifiers are querying the new selector against DNS; if it is not published, verification fails during that window.
Q: Does rotation require mail server downtime?
A: No. Modern MTAs (Postfix with OpenDKIM, Exim, Axigen) reload configuration without dropping connections. A few seconds of elevated latency at most.
Q: Is it safe to rotate during a busy business day?
A: Yes, once you have verified the new selector's DNS is propagated and the test messages pass. Rotation is zero-downtime when done correctly.
Q: Should I automate rotation?
A: Larger UK enterprises commonly script the whole flow — generate new key, publish to DNS (via API), reload signer, verify, schedule revocation of old selector. Smaller businesses typically handle it manually on a quarterly calendar reminder.
Q: What happens to existing DMARC reports about old selectors after rotation?
A: Nothing special — DMARC aggregate reports continue to show whatever selectors signed each message, whether old or new. After revocation, any new reports referencing the old selector (unusual) show DKIM failures, which is the intended signal.
Q: If I use Ed25519 and RSA-2048 simultaneously, do both get rotated together?
A: Yes — rotate both selectors on the same quarterly cadence. Managing them together keeps the operational rhythm simple.
Q: Do I need to notify anyone when I rotate?
A: No — rotation is transparent to receivers and users. Internally, you may want to notify your IT team so that any monitoring systems pick up the change correctly.
Q: What is the single most common rotation mistake?
A: Forgetting to publish the new DNS record before switching the signer. The signer starts using a selector that is not yet findable in DNS, and every message fails DKIM for the length of the DNS propagation window. Always: publish first, switch second.