A planned DKIM rotation changes which private key signs new mail while preserving the verification material needed for messages already in transit. Publishing a new public key, switching the signer and retiring the old selector are separate stages.
Start with the signing service and its supported rotation procedure. A provider-managed selector delegation has a different operating model from a key pair controlled directly by your organisation.
Establish the current signing state
Use original received messages to identify the actual d= signing domains and s= selectors. Correlate them with the signing service, key-management model and business owner.
A DNS record can exist without being used by current messages. Conversely, an old message can refer to a selector that is no longer the active choice for new mail.
Save the relevant public answers and configuration state. Keep private signing keys in the authorised signing system, not in a ticket, inventory spreadsheet or public DNS record.
Confirm the algorithm and provider requirements
Review current cryptographic guidance and supported verification behaviour. RFC 8301 §3 rules out rsa-sha1 and sets RSA key-size requirements; it recommends RSA keys of at least 2048 bits. RFC 8463 §5 defines Ed25519-SHA256 as an additional method.
An algorithm's specification and the actual support of the senders, providers and receivers involved are different evidence. Do not change a production service to a method its supported configuration cannot use.
For provider-managed signing, follow its generated values and rotation process. A DNS alias can delegate key management without giving your team the private key or a manual cutover control.
Publish new verification material before cutover
Where the supported design uses a new selector, publish its correct public verification material first. Confirm the final owner name, answer and any delegation chain.
Use a different selector for a new key where the supported procedure allows it. Replacing the key under one selector can leave messages signed with the old key unable to verify against the replacement.
Do not remove the old key merely because the new DNS answer looks correct. At this stage you have established publication, not that the signer has switched or every receiver can retrieve the intended material.
Switch signing and verify new messages
Use the authorised signing procedure to begin signing with the new key. Send representative messages through important routes and inspect the original received signatures and trusted results.
In a synthetic rotation, earlier mail uses s=old2026 and new mail uses s=new2026. Both public verification names remain available during the planned overlap, while new received messages demonstrate the intended selector and a passing signature.
If a gateway modifies the message after signing, a direct test before that gateway is incomplete. Check the complete business route and DMARC alignment as well as the raw signature result.
Choose retirement from the delivery conditions
RFC 6376 §3.1 describes concurrent publication during the transition in which mail may still be in transit. It does not supply one universal overlap duration for every organisation.
Assess queues, retry behaviour, expected delivery delays, DNS cache behaviour, relevant signature expiry and verification needs. Record the reason for the chosen overlap and any provider constraints.
Retire the old verification material under the supported process only when that assessment justifies it. A later check of a saved message can differ from its original delivery-time result after key retirement.
Treat suspected compromise as a different decision
Routine rotation aims for continuity. A suspected private-key compromise can require urgent restriction or retirement despite potential verification impact on older mail.
Follow the organisation's incident process and the signing provider's supported response. Preserve the evidence and explain the trade-off. Do not promise that an overlap suitable for routine maintenance is suitable during an active compromise.
Close with a verifiable signing record
Retain the service, owner, old and new selectors, publication evidence, cutover observation, overlap rationale, retirement decision and representative received results.
The selector guide explains the identity lookup. For Microsoft 365 or Workspace, use their tenant-specific or selected-domain configuration guidance. A rotation is complete when the new signing route is verified and the old dependency has been retired for a documented reason.
Use three separate acceptance checks
This proposed checklist is not a record of completed rotation. Before cutover, confirm the new selector resolves to the generated public value while the old selector remains available. After cutover, a newly received application message should show s=new2026 and the intended d domain with a trusted pass. Before retirement, confirm the agreed queue/retry and verification conditions are met and record the decision. A pass from an unrelated application does not close the affected route. Do not turn an example interval into a universal wait time.