DKIM Selector Rotation During a Provider Change
Roll DKIM selectors during an ESP migration with overlap, DNS verification, header checks, retirement, and rollback.
Product & Engineering · September 25, 2026 · 2 min read
During an email provider change, rotate DKIM selectors as a controlled rollover. A selector points receivers to a public key while the provider signs with the matching private key. Because selectors are separate names, an old and new selector can often coexist during a migration; confirm the provider’s limits and workflow before relying on overlap.
Plan the overlap
Inventory current selectors, DNS TTL, From domains, DKIM d= values, provider accounts, and rollback criteria. Choose a new selector name that will not collide with an active key. Publish the new public key before switching traffic, and record the authoritative answer. The DKIM guide explains the basic lookup; this runbook adds the migration sequence.
Keep the old key available while old messages, queues, or rollback traffic may still be signed with it. Do not publish a private key in tickets or logs. If the provider generates keys, document where the provider confirms activation and what status it exposes.
Switch and verify
Move a controlled stream first. Inspect raw headers for DKIM-Signature selector s= and signing domain d=. Then inspect Authentication-Results for dkim=pass and verify DMARC alignment between d= and the visible From domain. Use authentication change management to coordinate DNS, provider, and owner approvals.
Verify messages from every important stream, not just one test. Check provider event IDs, timestamps, retries, and complaints in the normal migration runbook when available. A key resolving in DNS proves discoverability; it does not prove the application is signing with it.
Retire and roll back
After the old selector has no active traffic and the rollback window is closed, remove or disable it through the approved process. Keep the change record and evidence. If signatures fail, revert traffic to the old provider or selector, restore the prior configuration, and preserve the failing headers before trying a second change. Do not prescribe a universal key lifetime; set retirement from observed traffic and your risk policy.
Related resources
Use the Email Infrastructure academy for provider-change context.
This workflow should be checked against the cited standards and current provider documentation 1.
References
Resources in this guide
Frequently asked questions
Can old and new DKIM selectors coexist?
They can often coexist because each selector is a separate DNS name, but confirm provider behavior, key policy, and the receiving path before using overlap.
What header proves the new key is active?
A representative message should show the new selector in `s=`, the expected signing domain in `d=`, and a passing DKIM result in Authentication-Results.
When should the old key be removed?
After traffic, queued mail, and rollback requirements are reviewed and no legitimate messages depend on it. Record the evidence and approval.
Continue learning
Use the email platform migration runbook
Continue with the closest operational guide.