DKIM key rotation: switch selectors without stranding in-flight mail

Define the decision

Rotation is a sequence involving both the provider and DNS. Deleting the old public key immediately can prevent verification of delayed mail signed with the old private key. The overlap should follow your provider’s process and traffic behavior.

Work through the procedure

1. Generate the new key through the authorized sending service.
2. Publish its new selector and confirm public resolution.
3. Switch signing, then verify fresh messages from every affected stream.
4. Monitor delayed traffic before retiring the old selector under an approved change plan.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Stage 1: old selector active; new selector published
Stage 2: fresh messages use new selector and pass
Stage 3: overlap monitored for delayed old signatures
Stage 4: old selector retired after the documented gate

Read the result

The critical evidence is a fresh signature using the new selector, not merely the existence of its DNS record. Track services separately if they do not rotate together.

Check before moving on

1. Keep private-key material in the provider’s protected workflow.
2. Record rollback steps before changing the signer.

Limits and next action

A compromise may require a different retirement decision than routine rotation. Involve the security owner when an old private key is suspected to be exposed.

Source: RFC 6376: key management considerations