The reason DKIM key rotation goes wrong is almost always ordering. A key pair has two halves living in two different places: the private key on your signing server, the public key in DNS. Rotation swaps both. If the signer starts using a new private key before its matching public key has propagated in DNS, every message you send in that window fails DKIM, because the receiver looks up a selector that does not resolve yet. The fix is not complicated, but it is strict about sequence.
Why Rotate at All
A DKIM key that never changes is a key that leaks quietly. It sits in backups, in configuration management, in the memory of a server you decommissioned two years ago. NIST and most compliance frameworks treat a long-lived signing key the same way they treat a long-lived password. Rotate on a schedule, quarterly or semi-annually for high-volume senders, and rotate immediately if a key is ever exposed.
There is a size dimension too. If you are still signing with a 1024-bit RSA key, rotation is your chance to move to 2048-bit, which is the current floor most large receivers expect. A 512-bit key is treated as no signature at all.
The Two-Selector Model
A selector is just a label that tells the receiver which public key to fetch. It appears in the DKIM-Signature header as the s= tag and maps to a DNS record at <selector>._domainkey.<domain>. Because you can publish more than one selector at a time, rotation is a handoff between two of them rather than an edit to one.
selector=aug2026 → aug2026._domainkey.example.com
selector=feb2027 → feb2027._domainkey.example.com
Here is the state of both selectors through a clean rotation:
| Phase | aug2026 in DNS |
feb2027 in DNS |
Signer uses | Result |
|---|---|---|---|---|
| 1. Publish | yes (live) | yes (new, unused) | aug2026 |
Old key still signs and verifies |
| 2. Propagate | yes | yes | aug2026 |
Wait out DNS TTL, both records resolvable |
| 3. Switch | yes | yes | feb2027 |
New key signs; old still resolves for mail in flight |
| 4. Retire | removed | yes | feb2027 |
Only the new selector remains |
The whole trick is that the new public key is resolvable in DNS before the signer ever produces a signature that references it, and the old public key stays resolvable after the signer stops using it, long enough for delayed and queued mail to clear.
Generating and Publishing the New Key
Generate the pair, then format the public half as a TXT record:
# generate a 2048-bit key pair
openssl genrsa -out feb2027.private 2048
openssl rsa -in feb2027.private -pubout -out feb2027.public
# strip the PEM headers and newlines for the DNS p= value
openssl rsa -in feb2027.private -pubout -outform DER 2>/dev/null \
| openssl base64 -A
Publish the new selector as a TXT record. Do this while the old selector is still the one signing your mail:
feb2027._domainkey.example.com. IN TXT (
"v=DKIM1; k=rsa; "
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..." )
The p= value is often longer than the 255-character limit for a single TXT string, which is why it is split into quoted chunks the resolver concatenates. Get that splitting wrong and the key parses as malformed, which reads to the receiver as a broken signature.
Verify Before You Switch
Do not trust the registrar's dashboard. Query the record the way a receiver will, and confirm it resolves everywhere before you touch the signer:
dig +short txt feb2027._domainkey.example.com
If that comes back empty or truncated, the switch is not safe yet. A DNS propagation check across multiple resolvers confirms the record is live globally, not just at the one resolver your workstation happens to use. Only once the new selector answers cleanly do you reconfigure the signer to use feb2027 and reload it.
Retire on the TTL, Not the Clock
The old selector has to outlive the last message that was signed with it. Mail sits in queues, gets greylisted, and retries for hours. Leave the old record in place for at least as long as your longest realistic delivery delay, and never shorter than the record's own TTL. A day is a safe floor; a week costs nothing. When you do retire it, delete the DNS record first, then destroy the old private key.
Watch the Whole Chain, Not Just DKIM
DKIM does not stand alone. A signature that verifies still fails DMARC if it is not aligned with your From: domain, so rotation is a good moment to confirm alignment end to end with an email health check that grades SPF and DMARC together. And the DNS records that carry your keys are only as reliable as the zone serving them: an expired certificate on the mail server itself is another quiet way delivery stops, which is where endpoint monitoring earns its place. Generator Labs certificate monitoring watches the TLS on your sending hosts so a rotation you did perfectly is not undone by a cert nobody was tracking. Start monitoring your endpoints.