DKIM keys are supposed to be rotated periodically. Almost nobody does it. The ones who try often break their email for a few hours doing it. There's a correct procedure that avoids both problems, and it's surprisingly unglamorous.
DKIM keys are supposed to be rotated periodically. Almost nobody does it. The ones who try often break their email for a few hours doing it. There's a correct procedure that avoids both problems, and it's surprisingly unglamorous.
This is a walkthrough of how to rotate a DKIM key with zero mail interruption, what the timing constraints actually are, and the specific failure modes to avoid.
Three reasons, in order of realism.
Compliance. Some security frameworks and cyber insurance questionnaires ask about DKIM key rotation cadence. "We rotate annually" is the expected answer. "We've never rotated" is the answer that raises follow-up questions.
Key compromise. If your DKIM private key leaks — through a compromised mail server, a stolen backup, an accidentally-published config file — you need to rotate. An attacker with your DKIM private key can sign mail as you, and that mail will pass DKIM validation everywhere. This is rare but catastrophic when it happens.
Key strength upgrades. Old DKIM keys were commonly 1024-bit RSA. The RFC minimum is 1024 but the realistic minimum for today's threat environment is 2048-bit. Some organisations are moving to Ed25519 for smaller, faster signatures. Rotating is how you upgrade.
The first two are why you should have a rotation capability. The third is the most common reason to actually use it.
Here's what people do the first time they try to rotate:
This breaks. Specifically, every in-flight message that's sitting in a spool somewhere — messages that were signed with the old key but haven't yet been delivered to receivers — will fail DKIM validation, because the public key in DNS no longer matches the key that signed those messages.
For high-volume senders this can mean thousands of messages failing DKIM over the course of a few hours as mail systems work through their queues. For receivers running strict DMARC enforcement against your domain, those messages get quarantined or rejected.
The failure is temporary — once the old messages work through — but it's messy and unnecessary.
DKIM has a feature specifically designed for this: selectors. A selector is an arbitrary identifier in the DKIM signature (s=selectorname) that tells the recipient which DNS record to look up for the public key. You can have multiple selectors active simultaneously.
The rotation procedure uses two selectors that leapfrog each other:
Before you need to rotate, set up two selectors for normal operation:
selector1._domainkey.yourdomain.com — active, signing mailselector2._domainkey.yourdomain.com — published but not signingPublish both public keys in DNS. Configure your mail server to sign outgoing mail with selector1.
When you want to rotate (annually, or in response to a compromise):
Generate the new keypair for selector2. Do this offline, on a secure machine, not on the mail server.
Update the DNS record for selector2._domainkey.yourdomain.com with the new public key. Wait for DNS propagation — at minimum your TTL, plus a safety margin. If your TTL is 3600 (one hour), wait at least 2 hours. Most well-run organisations keep DKIM record TTLs at 300-3600 seconds specifically to keep this rotation window manageable.
Deploy the new private key to the mail server but don't switch signing yet. The key is installed; it's just not being used.
Switch the mail server configuration to sign with selector2 instead of selector1. This is usually a single config change (in Postfix + OpenDKIM, in M365, in SendGrid, etc.) and should take effect without restarting mail services — just a config reload. New outbound mail is now signed with selector2.
Wait. This is the critical step everyone wants to skip. You need to wait long enough for every message signed with the old selector to have been delivered. For most organisations this is 24-48 hours. For anyone running their own mail server with deep queues, longer. For anyone using ESPs that hold messages for scheduled campaigns, longer still.
Retire the old selector. Remove the selector1 DNS record. The old key is gone. Nobody can validate signatures made with it (which is fine because there shouldn't be any in flight anymore).
Prepare the next rotation. Generate a fresh keypair for selector1, publish the public key in DNS, leave it sitting idle. Next year you'll flip back from selector2 to selector1.
Because DKIM TXT records are surprisingly fat — a 2048-bit RSA public key in base64 is around 400 characters, which requires string-splitting in many DNS implementations. Having 15 historical selectors accumulating in DNS is messy and wastes record space. Two selectors alternating is cleaner.
The gap between "new selector starts signing" and "old selector is removed" is the thing people get wrong. Too short and you break mail in flight. Too long and you defeat the purpose of rotation.
For a typical SMB with no deep mail queues:
For an enterprise with mailing lists, scheduled marketing campaigns, and possibly third-party senders:
The enterprise timeline sounds absurd but is correct. The cost of removing the old selector prematurely is measured in customer support tickets; the cost of waiting an extra week is zero.
If you send mail through several ESPs (Mailchimp for marketing, SendGrid for transactional, Google Workspace for staff email, etc.), each ESP manages its own DKIM signing and has its own selector.
google._domainkey.yourdomain.com (or similar; they've changed the default over the years).k1._domainkey.yourdomain.com and k2._domainkey.yourdomain.com.s1._domainkey.yourdomain.com and s2._domainkey.yourdomain.com for their custom signing setup.mandrill._domainkey.yourdomain.com.Each of these is independent. Rotating your own mail server's DKIM key has no effect on your ESPs' DKIM keys. For most SMBs, "your DKIM" is actually five different DKIM configurations at five different providers, and a proper rotation strategy has to account for all of them.
The good news is that the major ESPs handle rotation for you, automatically, behind the scenes, on their own schedule. You don't need to rotate SendGrid's keys — they rotate them themselves when they feel the need and the DNS CNAME you've published points at whatever they're currently using. The only keys you need to manage rotation for are the ones you control directly.
Three checks, in order:
Send yourself an email from the mail server that's now using the new selector. Check the raw headers in Gmail or wherever. Look for the DKIM-Signature: header. Verify the s= tag matches the new selector.
Validate the DKIM signature against the live DNS record. Most mail clients will show "signed by yourdomain.com" in the sender details if the signature validates. You can also use opendkim-testmsg or similar tools to check programmatically.
Monitor your DMARC aggregate reports over the next week. DKIM pass rate should stay constant throughout the rotation. If it drops, something's wrong — usually the new selector's DNS record has a typo or the mail server is signing with a key that doesn't match the published public key.
The free audit tool at dmarcsentinel.com probes common DKIM selectors — around 60 of the most common ones used by major ESPs — and reports which ones are configured, what key algorithms and lengths they're using, and flags weak keys (under 2048-bit RSA). It can't tell you when you last rotated, but it can tell you if your keys are too old to be considered secure by current standards.
If you're running 1024-bit RSA keys, the audit will flag them as weak. That's your cue to do the rotation dance above and upgrade to 2048-bit. Once you've done it once, subsequent rotations take about 10 minutes of active work plus the 48-hour wait.
DKIM rotation is a leapfrog between two selectors with a 48-hour wait between switching the signing selector and removing the old one. It's boring, slow, and the only procedure that doesn't break mail.
Jon Morby has run email and DNS infrastructure since the early 1990s. He built DMARC Sentinel after watching too many agencies discover their clients' email was going to spam the hard way.
Founded by Jon Morby, whose team has been running UK servers since 1992. Hosting built by engineers who care about deliverability and uptime.
Get in touch →Selling DMARC monitoring to a client who's never heard of it is one of the easiest sales conversations you can have in professional services, assuming you frame it correctly. The problem is that most agencies frame it wrong.
In October 2023, Google and Yahoo jointly announced new requirements for anyone sending more than 5,000 emails a day to their users. The rules were to take effect in February 2024. They were, at the time, the biggest change to bulk email deliverability in more than a decade.
The domain owner is baffled. Everything is "correct." Nothing is working. Legitimate transactional mail is being rejected by receiving servers and landing in nobody's inbox.