DKIM key rotation without breaking your mail
A DKIM private key that leaks lets an attacker sign perfectly authenticated mail as your domain — and keys leak through compromised servers, departing vendors and forgotten test setups. Rotation caps that risk. Done with two selectors, it is a non-event.
Cadence: what is actually reasonable
Big providers rotate quarterly; M3AAWG recommends at least every 6 months. For an SMB using hosted providers (Google, Microsoft, ESPs), a pragmatic policy is: rotate any key you host yourself every 6–12 months, rotate immediately on any suspicion of compromise or when an employee/vendor with key access leaves, and let managed providers rotate their own keys (Microsoft 365 does automatically; Google lets you regenerate).
More important than the calendar: know your key inventory. Most companies cannot list which selectors publish keys for their domain — audit that first (our free DKIM Inspector scans the common ones).
The zero-downtime procedure
DKIM selectors make rotation safe because old and new keys can coexist: 1) Generate the new 2048-bit key pair. 2) Publish the new public key under a NEW selector (mail2026a._domainkey…) alongside the old one. 3) Wait for DNS propagation (one TTL). 4) Switch your signer to the new selector. 5) Keep the old record up for at least a week — mail signed before the switch is still in queues and forwarders. 6) Then revoke the old selector by publishing an empty p= (better than deleting: an explicit revocation).
The failure mode to avoid is replacing the key under the SAME selector: every message signed in the propagation window fails verification at receivers with the stale record cached. MonitorBase monitors your selectors daily and alerts if a key disappears, weakens or enters test mode — including mid-rotation mistakes.
Free tools that help
- DKIM Inspector: Find published DKIM keys across common selectors and analyze key strength.
- DKIM Validator: Paste a raw email and verify its DKIM signature cryptographically.