Rotate your DKIM keys on a schedule so a stolen or brute-forced private key has a short useful life. For most senders, every 6 months is the right default; drop to every 3 months if you are still on a 1024-bit key, and go monthly if you send high-value or high-volume mail. The trick to doing this without breaking delivery is to never overwrite a live key. You publish a new selector, keep the old one signing and resolvable for a bleed-off window, verify the new one in the wild, and only then retire the old key.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
Why rotate DKIM keys at all
A DKIM signature proves a message really came from your domain and was not altered in transit. The proof rests entirely on your private key staying private. If that key leaks (a backup left in a public bucket, a compromised mail server, a departed contractor with server access) an attacker can sign mail as you, and it will pass DKIM and DMARC alignment cleanly. Rotation is the control that limits the damage window. A key you retire every quarter is worth far less to an attacker than one that has signed your mail unchanged for five years.
There is a second reason: key strength ages. A 1024-bit RSA key was fine a decade ago and is now the floor, not the target. Rotation is your natural moment to move up to 2048-bit and to retire weak keys before they become a liability. If you have not confirmed your current key length, our DKIM setup guide walks through generating a 2048-bit key and publishing the record.
What "rotation" actually changes
Rotation replaces the key pair behind a selector. The selector is the label in your DKIM record (for example s1._domainkey.yourdomain.com) that tells a receiver which public key to fetch. You can rotate by reusing one selector and swapping its key, or by publishing a brand new selector. The new-selector approach is what makes zero-downtime rotation possible, because both keys can exist at once.
How often to rotate: a decision table by risk profile
There is no single correct interval. Match the cadence to what a compromise would cost you and to the key you are running today.
| Risk profile | Rotation interval | Why |
|---|---|---|
| Standard business sender, 2048-bit key | Every 6 months | Balances operational effort against exposure; the widely cited default. |
| Any 1024-bit key still in service | Every 3 months, and upgrade to 2048-bit at the next rotation | Shorter keys are cheaper to attack, so shrink the window while you migrate. |
| High-value or high-volume senders (banks, payment, large marketing streams) | Monthly, automated | A signing key here is a prime target; frequent rotation plus automation keeps the blast radius small. |
| Suspected or confirmed key compromise | Immediately, out of band | See the emergency procedure below. Do not wait for the calendar. |
The numbers matter less than the discipline. A team that rotates reliably every 6 months is in far better shape than one that set a monthly policy on paper and never automated it. Pick the longest interval you can commit to honoring, then tighten it as you build tooling.
The zero-downtime dual-selector runbook
The failure mode people fear is real: overwrite the key that is signing in-flight mail and receivers will start returning DKIM fail on messages already sitting in queues and forwarders. The fix is to overlap two selectors so no message is ever left with an unresolvable key.
Step 1: Publish the new selector
Generate a fresh 2048-bit key pair. Publish the public key under a new selector, leaving the current one untouched. If you are signing with s1, publish s2:
s2._domainkey.yourdomain.com IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...AB"
At this point nothing signs with s2 yet. You are just seeding DNS so the record has time to propagate everywhere before it is needed.
Step 2: Switch signing to the new selector
After the new record has propagated (wait a few hours to be safe, longer if your TTL is high), tell your mail platform to sign outbound mail with s2. New mail now carries the new signature. Crucially, you leave the old s1 public key published and live.
Step 3: Keep the old key resolvable for the bleed-off window
Mail already signed with s1 may still be in transit, queued at a receiver, or bouncing through a forwarder for days. Keep the s1 public record in DNS for 7 to 30 days so those messages can still be verified. Seven days covers normal delivery; 30 days is the safe choice if you send transactional mail that gets forwarded or archived and re-checked later.
Step 4: Verify, then retire
Before you remove anything, confirm the new selector is working in the real world. Check the Authentication-Results header on a test message to a Gmail and an Outlook account and look for dkim=pass referencing the new selector; our guide on reading the Authentication-Results header shows exactly what to look for. Once you are confident and the bleed-off window has passed, delete the s1 TXT record and securely destroy its private key.
Running two selectors on purpose is normal and safe. If you want to understand how receivers pick between them, see multiple DKIM selectors on one domain.
Automated rotation with CNAME-hosted keys
Manual rotation does not scale to a monthly cadence. The cleanest way to automate it is to stop hosting the public key in your own DNS as a TXT record and instead point a selector at your provider with a CNAME:
selector1._domainkey.yourdomain.com IN CNAME selector1.dkim.provider.example
Now the provider owns the key material behind that hostname. When they rotate, the record your selector resolves to changes on their side and you never touch your DNS. Microsoft 365 uses exactly this pattern with two published selectors so it can flip between them, and many ESPs offer it. The tradeoff is trust: you are delegating control of your signing identity to that provider, so use it only with senders you would already trust to send as you.
If you cannot use CNAMEs, script the TXT-record dual-selector flow against your DNS provider's API and alternate between two selector names on each run. The runbook above is the same; you are just letting a job do steps 1 through 4 on a timer.
Emergency rotation after a suspected compromise
If you believe a private key has leaked, the calendar no longer applies. Move immediately, and change the order of operations because speed beats grace.
- Generate a new key pair and publish it under a new selector right away.
- Cut all signing over to the new selector as soon as the record resolves.
- Remove the compromised selector's public record from DNS now, rather than waiting out a bleed-off window. Yes, this may cause some legitimately signed in-flight mail to fail DKIM, but that is the correct tradeoff: an exposed key is actively dangerous and must stop being trusted.
- Rotate any credentials that could have exposed the key (server access, API tokens, backups) and investigate how it leaked.
- Watch your DMARC reports over the following days for signs the old key is still being abused. If you are enforcing a policy, spoofed mail signed with the dead key will now fail alignment and be rejected, which is the protection working as intended. If you are not yet at enforcement, see DMARC policy: none, quarantine, or reject.
The reason emergency rotation feels risky is that it deliberately sacrifices a little clean mail to shut off a compromised identity fast. That is the right call every time.
Frequently asked questions
How often should I rotate DKIM keys?
Every 6 months is the sensible default for a standard 2048-bit sender. Rotate every 3 months if you are still running a 1024-bit key, and monthly if you are a high-value or high-volume sender and can automate it. Any interval you actually honor beats a shorter one you skip.
Will rotating my DKIM key bounce email?
Not if you overlap selectors. Publish the new selector, switch signing to it, and leave the old public key resolvable for 7 to 30 days so in-flight and forwarded mail can still verify. Only overwriting a live key in place causes failures.
Should I reuse the same selector or create a new one?
Create a new selector for scheduled rotation. Having both the old and new public keys published at once is what lets old mail keep verifying while new mail uses the new key. Reusing one selector forces an in-place swap with no overlap.
Do CNAME-hosted DKIM keys rotate automatically?
Yes. When a selector is a CNAME pointing at your provider, the provider rotates the underlying key and your DNS never changes. This is how Microsoft 365 and many ESPs handle rotation. The tradeoff is that you delegate control of your signing key to that provider.