KoltrixRotating DKIM keys without dropping a single message
A selector-based DKIM rotation plan: publish the new key, switch signing, keep the old key long enough, then revoke it with an empty p= tag.
On this page(7 sections)
- Why rotate at all
- How selectors make rotation painless
- The rotation timeline
- Phase 1: generate and publish the new key
- Phase 2: switch signing to the new selector
- Phase 3: keep the old key published for a while
- Phase 4: revoke the old key
- Rotation with providers that host your keys
- Common mistakes
- A rotation checklist
- Key takeaways
DKIM keys are long-lived secrets that most teams set once and never touch again. Rotating them is straightforward if you use selectors the way they were designed, and the whole process can be done without a single message failing verification.
Why rotate at all
A DKIM private key lets anyone holding it sign mail that verifies as your domain. If it leaks, through a compromised server, a backup, a former vendor or a misconfigured repository, an attacker can send fully authenticated mail as you, and DMARC will pass it.
Regular rotation limits how long a leaked key stays useful. It also forces you to keep the rotation procedure working, which matters on the day you need to do it urgently. Common practice is to rotate every six to twelve months, and immediately when you suspect exposure, offboard a vendor that held the key, or decommission a signing server.
How selectors make rotation painless
A DKIM signature names its key with two values in the DKIM-Signature header: the signing domain d= and the selector s=. The verifier fetches the public key from DNS at:
<selector>._domainkey.<domain>Because the selector is part of the lookup name, you can publish many keys for one domain at the same time. Rotation is just moving from one selector to another. There is no moment where the old key must be replaced in place.
A common naming scheme encodes the date, which makes the age of a key obvious at a glance:
k2026a._domainkey.example.com
k2026b._domainkey.example.comThe rotation timeline
Phase 1: generate and publish the new key
Generate a new key pair. Use RSA with at least 2048 bits; RFC 8301 requires verifiers to support RSA keys of 1024 to 4096 bits and requires signers to use at least 1024, and 2048 is the widely recommended minimum today.
openssl genrsa -out k2026b.private 2048
openssl rsa -in k2026b.private -pubout -outform der 2>/dev/null | openssl base64 -APublish the public key at the new selector:
k2026b._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"A 2048-bit key exceeds 255 characters, so the TXT value must be split into multiple quoted strings. Most DNS providers do this automatically; check how yours behaves.
Do not start signing yet. Wait at least one full TTL so that resolvers everywhere can see the new record, then verify:
dig +short TXT k2026b._domainkey.example.com @8.8.8.8Phase 2: switch signing to the new selector
Update your signer (mail server, milter, provider configuration) to sign with the new private key and s=k2026b. Send test messages and check that the receiving side shows dkim=pass with header.s=k2026b.
From this point, newly sent mail uses the new key. The old public key remains published.
Phase 3: keep the old key published for a while
Messages signed with the old key may still be in flight or waiting to be verified later. Verification can happen well after sending:
- Messages stuck in retry queues for days because of deferrals.
- Forwarded messages re-verified at a second destination.
- Mailing list archives and compliance systems that re-check signatures.
Keep the old selector's key published for at least a week after you stop signing with it. Many operators wait several weeks. There is little cost to waiting.
Phase 4: revoke the old key
RFC 6376 provides an explicit way to revoke a key: publish the record with an empty p= value.
k2026a._domainkey.example.com. TXT "v=DKIM1; p="An empty public key tells verifiers the key has been revoked, which is clearer than deleting the record. A missing record produces a different, vaguer failure. After some months you can remove the record entirely.
Finally, destroy the old private key everywhere it was stored: servers, secret managers, backups you can reach, CI variables.
Rotation with providers that host your keys
Many sending services ask you to publish a CNAME at the selector that points to a record they control:
s1._domainkey.example.com. CNAME s1.domainkey.u1234.provider.example.This lets the provider rotate keys on their side without any DNS changes from you. If your provider works this way, rotation is mostly their job; confirm in their documentation how often they rotate and whether you need to do anything when they do. Some providers use two CNAMEs (for example s1 and s2) precisely so they can alternate between them.
Common mistakes
- Replacing the key at the same selector. Overwriting
k2026awith a new public key breaks verification for every message signed with the old key that has not been verified yet. - Switching signing before DNS propagates. Receivers that cannot find the new key fail the signature.
- Deleting instead of revoking. An empty
p=is the documented revocation signal. - Forgetting secondary signers. If several servers or services sign with the same key, all of them must switch before the old key is revoked.
- Losing track of which selectors exist. Keep a short register of selectors, what signs with each, when each was created and when each is scheduled for retirement.
A rotation checklist
- Generate a new 2048-bit key under a new selector name.
- Publish the public key and wait at least one TTL.
- Verify the record from public resolvers.
- Switch every signer to the new selector and private key.
- Confirm
dkim=passwith the new selector on test messages and in DMARC reports. - Keep the old public key published for one to several weeks.
- Revoke the old selector with
p=empty. - Destroy the old private key and update your selector register.
Key takeaways
- Selectors let you publish old and new keys side by side, so rotation never requires an outage.
- Publish first, switch signing second, revoke last, with waiting periods between each step.
- Revoke with an empty
p=tag rather than deleting the record. - Rotate on a schedule, and immediately when a key may have been exposed.
- Provider-hosted keys via CNAME shift rotation to the provider; confirm how they handle it.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
