How to rotate a DKIM selector without breaking in-flight outbound email

Selectors make overlap possible

DKIM does not require a domain to have one global key. Each signature names a selector with s= and a signing domain with d=; the receiver combines them to find the public key. That design allows old and new selectors to coexist during rotation. The safest migration takes advantage of that capability instead of replacing a public key at the same selector and hoping every queued message has already arrived. If a delayed message still carries the old selector, the receiver needs the old DNS key to verify it.

Create the new identity before touching the old one

Generate or obtain the new key according to the provider’s current instructions and publish it under a new selector name. Query the record until it resolves correctly from outside your authoritative DNS. If the provider uses a CNAME, follow it and confirm the final key is reachable. If it uses TXT, verify the complete key was published and not truncated by the DNS control panel. Only after the new selector is visible should the signing system be configured to use it. This order avoids a window where signatures reference a key that recipients cannot yet retrieve.

Switch the signer and inspect real traffic

After enabling the new selector, send controlled messages to Gmail, Outlook, and any other receiver important to your audience. Inspect raw headers and confirm the new s= value appears, DKIM verifies, and the d= domain aligns with the visible From domain for DMARC. Provider dashboards can report that a DNS record is valid without proving that the production signer has actually switched. The received message is the truth about which selector left your system.

Leave the old selector available during the overlap window

Do not delete the old selector the moment the first new message passes. Mail can remain queued, be temporarily deferred, or arrive later through forwarding paths. Those messages were signed when the old key was active and cannot be retroactively changed. Keeping the old public key published for a reasonable grace period gives those signatures a chance to verify. The appropriate period depends on your mail path and queue behavior; the principle is to retire based on evidence that old-signed traffic has aged out, not on the minute you flipped the configuration.

Never publish two conflicting keys at one selector

Rotation should use different selector names. Publishing two separate DKIM keys at the same selector is not analogous to combining SPF includes. A receiver needs one coherent key record for the selector referenced in the signature. Similarly, a CNAME and a TXT record cannot coexist at the same DNS name. If your provider insists on a fixed selector, follow its supported rotation mechanism rather than improvising a second key at that label. New selector names are the cleanest way to make old and new verification overlap safely.

Use rotation to verify ownership and algorithm hygiene

A key change is also a useful inventory exercise. Confirm which system holds the private key, which DNS zone publishes the public key, and whether the signing algorithm and key size meet current DKIM guidance. RFC 8301 requires rsa-sha256 and sets minimum key-size expectations for RSA. You do not need to expose the private key to document the system; record the selector, provider, d= domain, activation date, and owner. That is enough to make the next rotation less dependent on memory.

Worked sequence for a two-mailbox domain

Assume both mailboxes sign with selector old2025. Publish new2026 first and verify it. Configure one test mailbox to sign with new2026 and send several messages. If authentication passes, switch the second mailbox. For the next several days, watch received headers and logs for any message still carrying old2025. Once no new old-signed messages appear and your maximum delivery-delay window has passed, remove the old record. This staged approach creates clear rollback points without forcing all traffic through an unverified key.

Record the retirement event

When the old selector is finally removed, update the DNS inventory and keep one example header from before and after the change. Future debugging becomes much faster when an operator can answer, “Which selector should a message dated August 22 have used?” If a receiver later reports a missing selector, the timestamp and signing history tell you whether the message was delayed from before retirement, routed through an unexpected signer, or generated by a system that never completed the migration.

Retire the old selector based on message lifetime, not a calendar guess

The dangerous part of DKIM rotation is deleting the old public key too soon. A message can be signed with the old selector, sit in a provider queue, be temporarily deferred by a recipient, and arrive after the signer has already switched to the new selector. The verifier only knows the selector carried in that message; it cannot use the new key as a substitute. Keep the previous selector resolvable for at least the longest realistic period in which old-signed mail may still be delivered or reprocessed in your environment. That period comes from your queue and retry behavior, not from a universal DKIM number.

A useful rotation log records four moments: new key published, new selector first observed on received mail, old selector last observed, and old DNS key retired. During the overlap, query both selector names and send tests through every system that signs for the domain. RFC 8301 also gives a good reason to review crypto hygiene during the change: DKIM signers use rsa-sha256, RSA keys must be at least 1024 bits, and 2048 bits is recommended. Rotation is therefore a chance to remove an obsolete selector and verify the replacement is strong, but the key-size upgrade should not be allowed to erase the operational evidence that old messages can still exist in flight.

Field checklist

• Publish the new selector before switching production signing.
• Verify the record externally, including CNAME targets if used.
• Confirm production messages actually carry the new s= value.
• Keep the old selector resolvable while delayed mail can still arrive.
• Do not place two conflicting keys at the same selector name.
• Document selector, provider, d= domain, activation and retirement dates.