Introduction
Rotating DKIM keys is one of those security hygiene tasks that everyone agrees should happen and almost no one schedules. The fear is breaking signing for a day; the actual procedure is safer than that. This article walks the four-step playbook: dual-publish, switch, verify, retire.
Why this topic matters
DKIM keys, like any cryptographic key, benefit from periodic rotation. The exposure of a stale key — a former employee with access to the SaaS account, a leaked CI variable — is mitigated by rotation. Annual rotation is a defensible baseline; quarterly for high-stakes domains.
The job is easy once you know the pattern. The pattern is dual-publish.
The four-step playbook
Step 1: Dual-publish
Generate a new key pair (or have the sending platform generate one). Publish the new public key at a new selector — for example, if you're currently at s1._domainkey.yourdomain.com, publish the new one at s2._domainkey.yourdomain.com.
Both old and new public keys now exist in DNS. The platform is still signing with the old private key.
Step 2: Switch
In the sending platform, switch the active signing key to the new private key (with s2 selector). Newly sent messages start signing with the new key; in-flight messages still use the old.
Step 3: Verify
Send a test message. Inspect the DKIM-Signature header — confirm s=s2. View the receiver's authentication results — confirm dkim=pass. Look at aggregate reports over the next 24-48 hours; pass rate should remain at expected level.
Step 4: Retire
After 7-14 days of clean verification with the new selector, delete the old TXT record at s1._domainkey.yourdomain.com. The old key is now revoked.
Step-by-step approach with specific commands
For a typical Microsoft 365 setup:
- Microsoft 365 admin center → Email authentication → DKIM → Generate new keys (creates new selector automatically).
- DNS: publish the new CNAME records Microsoft provides.
- Wait 1 hour for DNS propagation.
- Switch active signing in Microsoft 365 to the new selector.
- Send test from a 365 mailbox. Inspect the DKIM-Signature header.
- After 7-14 days, delete the old CNAME records.
Other platforms follow a similar pattern; the specifics live in their docs.
Best practices
- Schedule rotation. Annual at minimum. Calendar it.
- Use distinct selector names per rotation. Don't reuse old selector names; they create confusing diagnostics.
- Keep both keys live for at least a week. Catches edge cases like delayed-delivery mail.
- Document the rotation. Note the date, selectors involved, and outcome.
- Coordinate with platform support if needed. Some platforms (especially older ones) have quirks.
What can go wrong
Three failure modes:
- Forgot to publish the new public key before switching. Mail starts failing DKIM immediately. Fix: publish the key. Wait for propagation.
- Old key deleted too early. Some in-flight mail might still be signed with the old key. Fix: republish the old key briefly.
- DNS propagation delay. Some receivers cache the old key. Usually self-resolves within hours.
All are recoverable. The dual-publish window is what prevents any of these from being more than a temporary blip.
Recommended next step
Calendar your next DKIM rotation. If you've never rotated, do one rotation in the next 30 days to learn the procedure. Annual cadence after that is fine for most domains.
FAQ
How often should DKIM keys be rotated?
Annually for most domains. Quarterly for high-stakes financial or healthcare domains.
Will rotation cause mail to bounce?
No, if you follow the dual-publish pattern. Old mail verifies against the still-published old key; new mail verifies against the new key.
Can I use the same selector name after rotation?
Technically yes, but it's confusing. Use new selectors to keep audit history clean.
What key size should I use?
2048-bit RSA at minimum. 1024-bit is breakable; 4096-bit doesn't fit cleanly in some DNS providers' TXT length limits.
Can I rotate multiple senders at once?
Yes, but one at a time is easier to validate. Stagger them.
Final thoughts
DKIM key rotation is one of the easiest security hygiene wins available. The dual-publish pattern makes it low-risk; the operational gain is real. The reason most teams skip it is unfamiliarity, not difficulty — once you've done one, the rest are routine.
Calendar annually, follow the pattern, document the result. Stale DKIM keys are a low-priority risk that compounds quietly; this is the simplest way to keep that risk at zero.