dkim key rotation and selector rollover with zero downtime
How to rotate DKIM keys using selector rollover without any authentication gap. Full process, TTL timing, rollback plan, and automation.
DKIM keys don't last forever. If you're sending email from a custom domain (whether for an AI agent or a traditional application), rotating those keys is a regular part of maintaining good deliverability. The technique that makes this painless is called selector rollover: you publish a new key alongside the old one, switch your signer, then retire the old key after a grace period. No authentication gap. No bounced mail.
Most rotation guides give you a happy-path walkthrough and skip everything that can go wrong. This one covers the full process, including rollback and failure recovery. If your agent sends email through LobsterMail, and DKIM rotation is handled automatically on your behalf. For everyone managing their own sending infrastructure, here's how to do it right.
How to rotate DKIM keys without downtime#
- Lower your current DKIM TXT record TTL to 300 seconds
- Generate a new 2048-bit RSA key pair with a fresh selector name
- Publish the new selector as a DNS TXT record
- Wait for full propagation and verify with a DNS lookup tool
- Reconfigure your mail server to sign outbound mail with the new selector
- Monitor DMARC aggregate reports for authentication failures
- After a 5-7 day grace period, delete the old selector TXT record
Each step exists for a specific reason. Skip one and you risk a window where receiving servers can't verify your signatures. The rest of this article explains why each step matters and what to do when things don't go as planned.
What DKIM selectors actually do#
A DKIM selector is a label that tells receiving mail servers where to find your public key in DNS. When your mail server signs an outbound message, it includes an s= tag in the DKIM-Signature header specifying which selector was used. The receiving server then queries selector._domainkey.yourdomain.com to fetch the corresponding public key and verify the signature.
This is why selector rollover works without causing downtime. You're not overwriting a single DNS record and hoping it propagates fast enough. You're publishing a second record under a new selector name. Both records coexist. Messages signed with the old key still verify against the old selector, while messages signed with the new key verify against the new one. There's never a moment where a valid signature can't be authenticated.
;; Old selector — still live during transition
s1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=OLD_PUBLIC_KEY..."
;; New selector — published before switching the signer
s2._domainkey.example.com TXT "v=DKIM1; k=rsa; p=NEW_PUBLIC_KEY..."
Microsoft 365 uses this exact pattern with selector1 and selector2, rotating between them automatically. If you're running your own sending infrastructure, you follow the same approach either manually or through API-driven DNS updates.
Lower your TTL before you start#
Before generating a new key pair, lower the TTL on your existing DKIM TXT record to 300 seconds (5 minutes). This ensures DNS resolvers worldwide will stop caching the old record within minutes of any change. If your current TTL is set to 86400 (24 hours), some resolvers might serve stale data for a full day after you remove the old selector.
Tip
Lower the TTL at least 24-48 hours before your planned rotation. This gives the lower TTL itself time to propagate across resolver caches. It's easy to forget and painful to troubleshoot after the fact.
The dual-selector grace period#
Once you've switched your mail server to sign with the new selector, don't delete the old DNS record right away. Messages already in transit, or sitting in retry queues on other servers, may still carry signatures referencing the old selector. If that DNS record is gone when the receiving server tries to verify, those messages fail DKIM authentication.
A grace period of 5-7 days is the standard recommendation. This covers delayed deliveries, retry queues, and DNS caches that have unexpectedly high TTLs baked in. For high-volume senders, extending to 10 days adds a safety margin that costs nothing.
During this overlap window, watch your DMARC aggregate reports. Any increase in dkim=fail results for your domain is a signal that something needs your attention. These reports are your early warning system for catching problems before they affect deliverability at scale.
Verifying propagation before you switch#
Don't reconfigure your signer until you've confirmed the new TXT record is globally visible. Use dig against multiple public resolvers:
# Check against Google's public DNS
dig +short s2._domainkey.example.com TXT @8.8.8.8
# Check against Cloudflare's resolver
dig +short s2._domainkey.example.com TXT @1.1.1.1
If any resolver returns an empty response or NXDOMAIN, the record hasn't propagated there yet. Wait. Switching your signer before propagation completes is the single most common cause of authentication failures during DKIM rotation. There's no penalty for patience here.
## When rotation goes wrong (and how to roll back)
If you see a spike in `dkim=fail` results in your DMARC aggregate reports after switching the signer, check whether the new TXT record is actually resolvable from the perspective of major receiving servers. Common causes include DNS publishing delays, formatting issues with long TXT records (they need to be split into 255-byte strings for some providers), and copy-paste errors in the public key data. The fix: reconfigure your mail server to sign with the old selector while you correct the DNS record. The old key is still valid, so rolling back is safe and causes no disruption.
If DNS propagation is delayed beyond your planned window, don't force the switchover. Keep signing with the old selector and extend your timeline. Nothing bad happens from waiting longer.
If you accidentally published the private key instead of the public key (it happens more often than people admit), generate a new key pair immediately. Delete the exposed record, publish the correct public key under a fresh selector name, and treat the compromised private key as permanently burned.
<Callout type="warning">
Upgrading from 1024-bit to 2048-bit DKIM keys isn't optional anymore. Google and other major providers flag 1024-bit signatures as weak, and 1024-bit RSA is within practical reach of well-funded attackers. If your current keys are 1024-bit, your next rotation should include a key-length upgrade.
</Callout>
## How often to rotate DKIM keys
M3AAWG (the Messaging, Malware and Mobile Anti-Abuse Working Group) previously recommended quarterly DKIM rotation but has since shifted to every six months for most senders. The reasoning: more frequent rotation increases operational complexity without proportional security benefit, especially for organizations already using 2048-bit keys.
Rotate immediately, regardless of schedule, if you suspect key compromise, if someone with access to the private key leaves your organization, or if you're upgrading key length.
The entire rotation process, from TTL lowering to old-selector cleanup, typically takes 7-10 days when done carefully. Rushing it to finish in a single day is how authentication gaps happen.
## Rotating across multiple domains
If you're managing DKIM for several sending domains at once (common for SaaS platforms, agencies, or agents operating across multiple identities), each domain needs its own independent rollover timeline. Propagation timing, signer configuration, and grace periods can't be shared across domains.
Doing this manually for 10+ domains is tedious and error-prone. This is where automation pays for itself, whether through your own tooling (Terraform modules, GitHub Actions, DNS provider APIs) or through a platform that handles it for you.
LobsterMail manages DKIM key generation, DNS record publication, and rotation automatically for any [custom domain](/blog/custom-domains-agent-email) connected to your account. New selectors are published, propagation is verified before any signer switchover occurs, and old records are retired after the grace period. Your agent sends email and the signatures are always current, with zero manual intervention required.
<FAQ>
<FAQItem question="What is the difference between DKIM key rotation and DKIM selector rollover?">
They describe the same process from different angles. DKIM key rotation means replacing the cryptographic key pair. Selector rollover is the technique used to do it without downtime: publish the new key under a new selector name, switch the signer, then retire the old selector after a grace period.
</FAQItem>
<FAQItem question="Why does using a new selector name guarantee zero downtime?">
Because both old and new DNS TXT records coexist during the transition. Messages signed with the old key still verify against the old selector, while new messages verify against the new one. There's never a window where a valid signature can't be checked.
</FAQItem>
<FAQItem question="What DNS TTL should I set before starting a DKIM key rotation?">
Lower your DKIM TXT record TTL to 300 seconds (5 minutes) at least 24-48 hours before rotating. This ensures resolvers stop caching the old record quickly once you eventually remove it.
</FAQItem>
<FAQItem question="How long should the dual-selector overlap grace period last?">
Keep both selectors active for 5-7 days after switching your signer. This accounts for messages in retry queues and DNS caches with high TTLs. High-volume senders should consider extending to 10 days.
</FAQItem>
<FAQItem question="How do I confirm a new DKIM TXT record is globally propagated before switching?">
Run `dig +short newselector._domainkey.yourdomain.com TXT` against multiple public resolvers like Google (8.8.8.8) and Cloudflare (1.1.1.1). If any returns empty or NXDOMAIN, wait before switching your signer.
</FAQItem>
<FAQItem question="Does DKIM key rotation affect DMARC alignment or break aggregate reports?">
No. DMARC checks DKIM alignment based on the signing domain (`d=` tag), not the selector. Rotating keys doesn't change your DMARC policy or disrupt aggregate reporting, as long as the signing domain stays the same.
</FAQItem>
<FAQItem question="What happens to emails already in transit if I delete the old DKIM selector too early?">
Messages carrying signatures that reference the old selector will fail DKIM authentication when the receiving server can't find the DNS record. This can trigger DMARC failures and cause those messages to land in spam or be rejected outright.
</FAQItem>
<FAQItem question="How often does M3AAWG recommend rotating DKIM keys?">
M3AAWG currently recommends every six months for most senders, revised from earlier quarterly guidance. Rotate immediately if you suspect key compromise or are upgrading from 1024-bit to 2048-bit keys.
</FAQItem>
<FAQItem question="Is 2048-bit always the right choice when generating a replacement DKIM key?">
For almost all senders, yes. 2048-bit RSA is the current standard. 1024-bit keys are considered weak by major providers. Some organizations use 4096-bit, but these can exceed DNS TXT record size limits and cause compatibility issues with certain resolvers.
</FAQItem>
<FAQItem question="How does Microsoft 365 use selector1 and selector2 for DKIM rotation?">
Microsoft 365 maintains two fixed selectors and rotates between them. When rotation triggers, the inactive selector gets a new key and becomes the active signer. The previous selector stays live as a verification fallback during the grace period.
</FAQItem>
<FAQItem question="Can the entire DKIM rotation workflow be triggered via an API call?">
Yes, if your DNS provider offers an API (Cloudflare, Route 53, etc.). You can script key generation, TXT record creation, propagation verification, signer switchover, and old-record cleanup. LobsterMail automates this entire workflow for custom domains.
</FAQItem>
<FAQItem question="What should I do if DNS propagation is delayed beyond my planned grace period?">
Don't force the switchover. Keep signing with the old selector until the new record is globally resolvable. The old key remains valid and there's no downside to extending your timeline.
</FAQItem>
<FAQItem question="What are the observable signs that a DKIM key rotation has failed?">
Watch for increased `dkim=fail` results in DMARC aggregate reports, bounces with authentication error codes, or recipient complaints about messages going to spam. If any appear, verify the new DNS record is correct and consider rolling back to the old selector.
</FAQItem>
<FAQItem question="Does rotating DKIM keys require any changes to SPF records or DMARC policy?">
No. SPF validates the sending server's IP address. DMARC defines how authentication failures are handled. Neither is affected by a DKIM key rotation. You can rotate keys without touching SPF or DMARC configuration.
</FAQItem>
<FAQItem question="Does LobsterMail handle DKIM rotation automatically for custom domains?">
Yes. When you connect a [custom domain](/blog/custom-domains-agent-email) to LobsterMail, DKIM keys are provisioned and managed automatically. Rotation happens on a regular schedule with no manual steps: new selectors are published, propagation is confirmed, signers switch over, and old records are retired.
</FAQItem>
</FAQ>
