DKIM key rotation
Updated ·5 min read
DKIM, defined by RFC 6376, signs outgoing mail with a private key and publishes the matching public key in DNS at a selector under _domainkey. Like any cryptographic key, a DKIM key benefits from periodic rotation: a key that has been in use for years is a larger prize if compromised, and rotating on a schedule limits how much mail any single compromised key could have signed.
The mechanic that makes rotation safe is the selector itself. Because the selector name is part of where the public key is published, a domain can publish a new key under a new selector while the old key, under its old selector, is still valid, avoiding the moment where signing switches to a key receivers cannot yet verify.
Check yours now
Why rotate at all
A DKIM private key that leaks, through a compromised server, a mishandled backup, or an employee's laptop, lets whoever has it sign mail that will pass DKIM validation for the domain indefinitely, until that specific selector is revoked. Rotation limits the value of a leak that has not yet been discovered, since an attacker with an old key can only use it until it is superseded, not forever.
Rotation also has a mundane but real benefit: it forces the signing configuration to be reviewed periodically, catching a selector that points at a decommissioned platform or a key length that fell behind current recommendations, such as a 1024-bit key that predates the now-standard 2048-bit recommendation.
How selectors make overlap possible
A DKIM public key is published at selector._domainkey.example, and the selector name is entirely up to the domain owner; there is no requirement that it stay the same over time. Rotating a key means publishing a new key at a new selector, for example dk202609._domainkey.example if using a date-based naming scheme, without touching the old selector's record at all.
Because both selectors exist in DNS simultaneously during the overlap, mail signed with the old key and mail signed with the new key both validate correctly at any receiver, regardless of when that particular message was actually delivered or when the receiving server happens to check it.
A safe rotation sequence
The sequence below avoids ever having mail signed with a key that is not yet, or no longer, published in DNS, which is the failure mode rotation exists to prevent.
- Generate a new key pair and publish the new public key at a new selector, without changing the signing configuration yet
- Wait for that new record to be visible via DNS from outside your own network, confirming propagation before it is relied on
- Switch the sending platform's signing configuration to sign with the new selector and key
- Leave the old selector's record in DNS, unchanged, for a period at least as long as your mail queue's maximum retry window, commonly several days to a couple of weeks, so any mail still in flight signed with the old key continues to validate
- Remove the old selector's DNS record only after that window has passed
Revoking a key immediately, rather than rotating on schedule
A confirmed key compromise is not a rotation; it calls for immediate revocation, since the overlap period that makes routine rotation safe is exactly the window an attacker with the compromised key would keep exploiting. Revocation means publishing an empty p= value at the compromised selector, for example v=DKIM1; p=, which is the standard way to make every signature under that selector fail validation immediately.
After revoking, publish a new key at a fresh selector as usual and switch signing to it. Some mail may briefly fail DKIM during the gap between revocation and the new key taking effect; that gap is the acceptable cost of shutting off a key known to be compromised, compared with leaving it valid for a full overlap window.
How often to rotate
There is no single mandated interval in RFC 6376, but a common practical cadence is once or twice a year for routine rotation, with immediate out-of-cycle revocation whenever compromise is suspected rather than confirmed beyond doubt. A shorter cadence has diminishing returns against the operational overhead of coordinating the rotation across every sending platform that signs on the domain's behalf.
Multiple sending platforms, such as a marketing tool and a transactional mail provider, each typically use their own selector and key, and can be rotated independently on their own schedules rather than requiring one synchronized rotation across every platform at once.
Coordinating rotation across multiple sending platforms
A domain sending mail through more than one platform, such as a primary mail server, a marketing tool, and a transactional email API, typically has a separate DKIM selector and key pair for each, since each platform manages its own signing independently. This is convenient for rotation: each platform's key can be rotated on its own schedule, coordinated with that specific platform's own key-management process, rather than requiring every sending source to rotate in lockstep.
The main risk in a multi-platform setup is losing track of which selector belongs to which platform over time, especially after a platform is decommissioned but its DKIM record is never removed. An unused selector left in DNS indefinitely is not itself a security problem as long as its private key stays secure, but a periodic audit of every published selector against the list of platforms actually still in use is worth doing alongside routine rotation, since a forgotten selector is easy to overlook until a DKIM checker or a DNS cleanup effort brings it back to attention.
Naming selectors with a date, such as dk202609 for a key published in September 2026, makes this audit considerably easier, since the selector name itself tells you roughly when it was introduced without needing to cross-reference a separate change log or ask whoever set it up originally.