The case nobody makes.
DKIM key rotation is the email authentication hygiene task that almost nobody does, and almost nobody talks about. The protocol does not require it. Receiving mailbox providers do not enforce it. No DMARC policy depends on it. You can run a single DKIM key from 2018 in production indefinitely and never get a complaint from Google or Microsoft. The mail flows. The signatures verify. The deliverability dashboards stay green.
This is precisely why rotation matters. A DKIM private key that has been in the same place on the same MTA filesystem for seven years has been backed up dozens of times, replicated across staging environments, copied during disaster recovery drills, and exposed to whichever subset of your operations team has had production access at any point during those seven years. The key itself never expires. The trust surface around it inflates without limit.
The cryptographic argument for rotation is the standard one. RSA 1024-bit keys, still in production at a surprising number of senders, are computationally tractable for state-level adversaries now and likely tractable for organised attackers within five years. Even 2048-bit keys, which are the current floor, have an expected useful life that does not match the indefinite lifetime most senders give them. The operational argument is more immediate: rotating the key forces the team to re-verify that they actually control the rotation process, that DNS is reachable from the MTA, that the selector publishing pipeline works end to end. A rotation drill is a fire drill for the part of the email stack that nobody touches until it breaks.
What we actually do.
The rotation playbook we run for managed clients takes four weeks. The temptation is to compress it. Senders who have not rotated before look at the procedure and ask why they cannot just generate a new key on a Tuesday and switch over by Friday. The answer is that DKIM key transitions are governed by DNS caching behaviour at receiving MTAs, and the receiving MTAs are not in your control. Receivers cache DKIM public keys for the TTL the publisher set, plus an unpredictable margin that depends on the receiver's own infrastructure decisions. Four weeks is the conservative window that accommodates the worst-case receiver cache and the typical disaster — a malformed DNS publish that you do not catch immediately.
Week one is preparation. The operator generates the new key pair, typically 2048-bit RSA, occasionally Ed25519 if the receiving population is known to support it (most do, but the long tail of older Postfix installs does not). The private key is staged on the MTA but not yet active for signing. The public key is published to a new selector — we typically use the year-month as the selector name, so the April 2026 rotation goes to a selector like br202604. The selector publishing is verified using our DMARC inspector and three independent DNS lookups from different geographic locations.
Week two is the parallel period. The MTA is reconfigured to sign with the new selector while still presenting the old selector's public key in DNS. Some senders skip this and switch directly to the new selector on the signing side, leaving the old public key in DNS as a transition fallback. This works for most receivers but creates a small percentage of failures at receivers who cache the signing selector mapping per-sender rather than per-message. The parallel period eliminates those edge cases at the cost of two weeks of additional operational complexity.
Week three is observation. Aggregate DMARC reports start showing DKIM authentication results against the new selector. The operator verifies that the receiver coverage is in line with the previous selector — same percentage of mail aligning, same set of major receivers reporting positive verification. Any drop in alignment percentage during week three is a signal that the new selector is misconfigured or that the public key publishing has a propagation issue.
Week four is decommissioning. The old selector's public key DNS record is removed, after the operator verifies via DMARC reports that no receivers are still attempting to verify against the old selector. The old private key is destroyed from the MTA. The rotation is complete, and the calendar entry for the next rotation goes in at month plus twelve.
Where rotations break.
The five failure modes, in descending order of frequency.
First, DNS propagation longer than the publisher expects. The operator publishes the new public key DNS record with a 300-second TTL and assumes propagation is complete five minutes later. Receivers in regions served by certain large public DNS resolvers see the new record within seconds. Receivers served by ISP-operated resolvers, particularly in Asia-Pacific and Latin America, may not see the new record for hours. If the operator switches signing to the new selector before global propagation is complete, those receivers will reject the signed mail because the public key they are still serving from cache does not match.
Second, malformed DNS publishing that survives initial validation. The new public key record is published as a TXT record with the key material concatenated. If the concatenation introduces extra whitespace, the record validates as DNS but the key material fails RSA parsing at the receiver. Our DMARC inspector catches this. Many publishing tools do not. A surprising number of senders we have audited have one or more selectors with malformed key material that has been technically published for years.
Third, MTA configuration that signs with the new selector but does not strip the old selector header. Some MTAs allow multiple DKIM-Signature headers per message. If the operator configures the new selector for signing without removing the old selector's signing configuration, both signatures appear on the message. Some receivers verify both and treat any failure as failure of the message. Others verify only the first and ignore the second. The behaviour is receiver-specific and undocumented.
Fourth, DNS publishing that fails silently at the registrar. The operator publishes the new public key record to the DNS provider but the change does not propagate to the authoritative nameservers because the DNS provider has a propagation delay the operator did not know about. The record appears correct in the provider's UI but is not actually served to queries. The operator's local DNS lookups, which hit the provider's API rather than the authoritative servers, return the correct record. The mismatch is only visible from outside the provider's network.
Fifth, signing-side configuration that uses the wrong selector name. The operator publishes the new public key under the selector br202604. The MTA configuration uses br20264 or br-2026-04 or some other minor variant. The signature header on outbound mail references the wrong selector, the receiver attempts to fetch a public key under a selector that does not exist in DNS, and verification fails for every receiver. This sounds avoidable. It is the most frequently reported rotation failure in the operator community we are part of.
Rotate annually.
For production senders pushing meaningful volume, the right rotation cadence is annual. Twelve months is short enough that the rotation procedure stays fresh in the operations team's memory, and long enough that the operational overhead does not dominate the team's calendar. Quarterly rotations are theoretically more defensible from a cryptographic posture standpoint but introduce too much operational risk in environments where the rotation procedure has not been automated end-to-end.
The single most important thing you can do if you have never rotated is do it once. The first rotation will surface every fragile assumption in your DKIM pipeline. The second rotation will be roughly half the work. By the third, you have a routine. The senders who get into trouble are the ones whose first rotation happens during a compromise, when they urgently need to retire a key that has been exposed, and they discover for the first time that their DNS provider has a six-hour propagation delay or that their MTA configuration references a selector name nobody on the current team remembers setting.
If you want help running the first rotation, we do this as a fixed-scope four-week engagement at €1,200. The engagement includes the rotation itself, documentation of your team's specific DKIM pipeline, and the calendar setup for future annual rotations. After that, your team runs the playbook independently. We are not trying to sell you a recurring service. The point of the engagement is to make sure the next twelve rotations after this one happen without us.