Change management

Rotate a DKIM key without breaking verification

Plan DKIM selector overlap, protect private keys, verify new signatures and retire old keys deliberately.

Prepared with AI assistance. Read our editorial and corrections policy.

DKIM key rotation replaces signing material while allowing receivers to verify messages still in transit. A safe rotation uses a new selector, publishes its public key before signing changes and keeps the old public key available for a suitable overlap period. Changing the DNS record and the signer at the same moment is harder to recover from.

Identify the signer and current selector

Collect a received message from each sending system and inspect DKIM-Signature. Record the signing domain, selector and the service that owns the private key. Separate provider-managed keys from keys you manage yourself. A domain may have several selectors because different services sign its mail independently.

Verify the current public key with a DNS query to the exact selector name. Export the existing record and document who can change the signer. Never place the private key in DNS, a support ticket, a public repository or this site's contact message.

dig old2026._domainkey.example.com TXT
dig new2026._domainkey.example.com TXT

Publish the replacement before using it

Choose a new selector according to your provider's naming requirements. Generate or request the replacement key through the supported signing service. Publish the supplied public TXT key or delegated CNAME at the exact name requested. Do not convert one format into the other unless the provider explicitly supports it.

If you manage keys directly, follow current cryptographic guidance and your receiving ecosystem's support. A key's length alone does not establish a secure setup; protect storage, limit access and ensure backups do not expose signing material. Provider-managed rotation should use the provider's documented controls.

Verify DNS from both authority and caches

Query every authoritative nameserver for the new selector, then check recursive resolution. Compare the full value and watch for labels accidentally duplicated by an editor. Long TXT values may be split into strings within a single record; the parser joins them. A dashboard line wrap is not necessarily a malformed key.

Allow for any previously cached negative response for the new selector. Publishing a new label just before switching the signer can leave some receivers unable to retrieve the key temporarily. Keep the signer on the old selector until the replacement is visible through the resolution paths you test.

Switch signing and inspect real mail

  1. Enable the new selector in the signing system.
  2. Send a controlled message to a mailbox you own.
  3. Confirm the DKIM-Signature identifies the new selector and intended domain.
  4. Confirm the trusted receiving system reports a valid signature.
  5. Verify DMARC alignment with the visible From address.

A DNS checker cannot prove your live mail service adopted the key. Test each stream separately, including automated transactional systems. If the new signature fails, restore the prior signing configuration while investigating the label, key and message path. Keep the new public record during diagnosis so cached messages can still be evaluated.

Retain the old public key deliberately

Mail can remain queued and arrive after the signing change. Retain the old public key long enough for your systems' queue lifetime and expected delays, with a margin for operational uncertainty. There is no single overlap interval suitable for every service. Record the chosen retirement date and why it fits your delivery paths.

For routine rotation, remove the old key only after the overlap and verification period. A suspected compromise is different: continuing to publish a compromised key can permit forged signatures to verify. Follow an incident plan with the signer/provider, revoke where appropriate and accept that previously signed delayed mail may stop verifying.

Close the change with evidence

Retain the selector names, DNS publication time, signer switch time, redacted test headers and retirement decision. Keep private material out of that shared change record. Remove unused private keys from active signing configuration using the provider's procedure. Continue monitoring authentication reports for streams still using the retired selector.

Pair this workflow with DMARC monitoring and the DNS change checklist. Key rotation improves key hygiene; it does not replace permission-based sending or guarantee inbox placement.

Sources and further reading

Examples use reserved documentation names and addresses. Confirm current provider requirements before changing production systems.