DKIM Key Rotation: A Zero-Downtime Runbook

Overview

DKIM key rotation replaces a domain's signing key without breaking verification for legitimate email. The safe pattern is not to overwrite a live DNS record in place. Create a new selector and key pair, publish the new public key, verify it from outside your authoritative DNS, move signers to the new selector in controlled stages, retain the old public key while delayed mail can still arrive, and retire the old selector only after monitoring confirms the migration.

A selector is the s= value in a DKIM-Signature header. Receivers combine it with the signing domain in d= to query selector._domainkey.domain. Because selectors let multiple public keys coexist, they are the mechanism that makes a zero-downtime rollover possible. Rotation should cover every sending service, region, stream, and fallback path—not just the provider used by the last test email.

Inventory the real signing estate first

Start with messages, not a DNS-zone guess. Sample raw headers from each transactional, lifecycle, newsletter, support, and sales stream. Record the visible From domain, DKIM d= domain, selector s=, algorithm, sending provider, environment, owner, and whether DMARC currently passes through DKIM alignment. Include secondary regions, disaster-recovery providers, and queue workers that may send only during failures.

RFC 6376 uses selectors specifically so a signing domain can maintain multiple keys and phase keys in or out. That flexibility also makes stale selectors easy to forget. Build one row per signer and selector, then reconcile it against provider consoles and DNS. An unknown active selector is an investigation item; an unused record is not proof that its private key is safely retired.

• Inspect raw headers from every mailstream
• Map each selector to a named system and owner
• Confirm the DKIM d= domain aligns with the intended From domain
• Treat undocumented production selectors as a security finding

Prepare a new selector instead of editing the live one

Generate the replacement through the sending provider or your controlled signing service. Choose a new selector that is operationally recognizable without embedding secrets—for example, a provider and rotation epoch. Publish only the public key in DNS; the private key remains in the signer or provider's protected key store. Do not paste private material into tickets, chat, source control, or the DNS record.

Use current cryptographic requirements rather than cloning a legacy key. RFC 8301 updates DKIM algorithm and key guidance, including treating RSA keys below 1024 bits as invalid for signing or verification. Provider support and DNS constraints vary, so follow the provider's supported configuration while ensuring the result meets the current standard. Rotation is the right moment to remove obsolete key material, not reproduce it under a new selector.

• Never overwrite or remove the current public key during preparation
• Keep old and new selector records available in parallel
• Account for negative caching if the selector name was queried before publication
• Document who can activate and roll back the signer

1. Create a new selector and key pair in the authorized signing system.
2. Publish the exact public-key record at the new selector name.
3. Query the authoritative nameservers and independent recursive resolvers for the new record.
4. Validate record syntax, selector name, d= domain, algorithm, and key value.
5. Wait through the applicable DNS caching window before making the new selector the only signing path.

Canary the new signature before broad cutover

Once DNS is visible, activate the new selector for a test or low-risk stream. Send to external mailboxes where you can inspect the received source. Confirm that the DKIM-Signature contains the expected s= and d= values, Authentication-Results reports dkim=pass, and DMARC still passes through an aligned path. A successful provider dashboard test is useful, but it is not a substitute for receiver-side verification.

Expand in stages by signer, region, or mailstream. Keep the old private key available for rollback and keep its public key published throughout the transition. Do not rotate every provider and domain in one maintenance window; independent batches make failures attributable and rollback manageable.

• Validate at the receiver, not only at the sender
• Canary both HTML and plain-text or multipart message paths
• Test mail modified by your normal link, footer, and tracking pipeline
• Record the exact cutover time for later DMARC and log analysis

Monitor by selector, then retire conservatively

During overlap, measure which selectors are still signing mail. Use sampled raw headers, provider logs, and DMARC aggregate data where available, while remembering that DMARC reports are delayed and aggregated. Segment failures by signing domain, selector, provider, mailstream, and recipient domain. A global DKIM pass rate can hide one old worker or fallback region that never moved.

Retire the old selector only when all authorized signers have stopped using its private key and the longest relevant queue, retry, and message-transit window has passed. DNS TTL alone is not the full waiting period: a delayed message signed before cutover may be verified after cutover. Keep the public key available during that overlap. After retirement, remove or securely destroy old private-key access, update the inventory, and use your DNS/key-management policy to decide whether to remove the record or publish a revoked-key value.

• Do not delete the old DNS key immediately after cutover
• Measure adoption per selector instead of relying on an account-wide pass rate
• Keep evidence from external receiver tests
• Close the work only after old private-key access is removed

1. Confirm new-selector signatures and aligned DKIM passes across every mailstream.
2. Search logs and sampled headers for any message still signed by the old selector.
3. Wait out DNS caches plus the maximum realistic queue, retry, and delayed-transit window.
4. Disable and securely retire the old private key before declaring the rotation complete.
5. Retire or revoke the old public-key record according to the documented DNS policy.
6. Update the selector inventory, evidence, owner, and next review date.

Separate routine rollback from emergency compromise response

For a routine rotation failure, rollback is straightforward because the old key remains valid: switch the affected signer back to the old selector, verify a new external message, and investigate the new key without deleting either DNS record. Define rollback triggers before cutover, such as receiver-side DKIM failures, wrong d= alignment, a missing selector in one region, or unexpected post-signing modification.

A suspected private-key compromise is different. Returning to the compromised key is not a safe rollback. Activate a known-good replacement selector, stop the affected signer, preserve evidence, revoke or remove the compromised key according to the incident plan, and assess unauthorized use. Coordinate DKIM action with DMARC monitoring, provider credentials, API keys, deployment secrets, and any system that could have copied the private key.

• Write rollback commands and owners before cutover
• Do not confuse a propagation problem with a cryptographic failure
• Treat compromise as an incident, not normal maintenance
• Preserve logs showing selector use and configuration changes

Make rotation a repeatable control

No internet standard gives every sender one universal calendar interval. Set a rotation policy from your security requirements, provider capabilities, key custody, audit obligations, and operational risk. Also define event-driven rotation triggers: suspected exposure, staff or vendor access changes, provider migration, deprecated algorithms, unexplained signing activity, or loss of confidence in key provenance.

Mailbase does not replace your provider's DKIM signer or DNS controls. Its relevant role is the workflow above delivery: sender-domain setup, scheduled campaigns, analytics, suppressions, and reply handling. When rotating a domain used by Mailbase or a connected useSend deployment, pause risky campaign changes, canary authenticated messages through the real path, and keep transactional and marketing streams separately observable.

• Assign named owners for signer, DNS, monitoring, and rollback
• Schedule rotations as controlled changes with evidence
• Trigger out-of-cycle rotation when key trust changes
• Review provider fallback paths during every rotation

Common Mistakes

• Skipping SPF, DKIM, and DMARC, or assuming they're a one-time setup.
• Sending real volume from a brand-new, un-warmed domain.
• Reusing a stale list without re-verifying, so bounces spike.
• Ignoring complaint rate until a single bad campaign sinks the domain.

Sources & Further Reading

Official docs for current setup details, pricing, and API behavior — verify specifics there, since they change.

Related guides

More on dkim key rotation and the surrounding deliverability workflow:

FAQ

Related reading