DKIM key rotation: publish, switch, observe and retire

Begin with a complete message from each sending route in scope. Record the signing domain and selector it actually carries, then identify the team that controls the signer. A domain administrator may control DNS without controlling the service that generates signatures. A rotation cannot be scheduled reliably until both responsibilities are assigned.

DKIM uses d= for the signing domain and s= for the selector. Together they identify the public-key DNS name: selector._domainkey.domain. Different selectors allow keys to coexist. Follow the observed values; a selector name that sounds current does not prove it is active.

For the fictional example in this guide, the signing domain is example.org. The current selector is outreach2026a and the replacement is outreach2026b. These are illustrative operational labels, not keys or a configuration to deploy. The plan covers two routes owned by different teams, so each must supply evidence before the change is considered complete.

Use a distinct replacement selector so the old and new public keys can be addressed independently. NCSC guidance describes rotation with a new selector and notes that the available setup and automation depend on the email service. Record the process your actual service supports instead of assuming that every provider rotates on the same schedule.

For RSA signing, RFC 8301 requires at least 1,024-bit keys, recommends 2,048 bits or more, and prohibits rsa-sha1. These algorithm requirements do not establish a universal rotation interval. Confirm the supported signing configuration with the service owner as part of preparing the change.

The shared record should contain public operational information: domain, selector, record owner name, service reference, responsible people and evidence locations. Keep private key material and credentials out of the worksheet. If your organization manages keys directly, reference its controlled key-management record rather than copying the secret into a ticket.

Before scheduling, ask whether every route can be switched separately, whether a canary is possible and whether the old signer can be restored. Capture any service-imposed delay as a constraint of this specific change. That turns an apparently simple DNS edit into a plan the operating team can actually execute.

Google’s documented setup separates generating a key, adding its DNS record, turning on signing and verifying the result. Microsoft’s rotation guidance describes two selector records and scheduled rotation state. Both examples support a useful operational distinction: DNS publication and the signer’s use of the new key are separate checkpoints.

Ask the DNS owner to compare the published owner name, record type and value with the approved change. Record the observation time and the result of the organization’s normal DNS verification procedure. If the service uses an alias, confirm its supplied target as well as the alias itself. A screenshot of a saved editor form is evidence of an edit, not evidence of the answer a verifier can obtain.

Plan for the cache state that existed before the edit. A new selector may previously have returned a negative answer; an existing record may have an earlier TTL in caches. Record the applicable settings and the service’s readiness guidance. Do not declare universal readiness merely because one resolver returns the new record.

Leave the current signing route operating while the replacement is being prepared, unless the incident owner has identified a reason it must stop. The reviewer should receive a clear readiness statement, with unresolved dependencies called out, before the signing owner proceeds to the switch.

When the readiness checks pass, the signing owner uses the service’s supported switch or rotation process. Record the requested change and the service’s reported state separately. A queued operation or future activation time is not the same as evidence that the next message was signed with the replacement.

Use a controlled canary from each route where the service supports that approach. Inspect a complete received message and its trusted receiver authentication results. Record the actual d= and s= values and the outcome for the relevant signature. Google explicitly includes message-header verification in its setup procedure; use the equivalent evidence available for your sending service.

The extract below is schematic and cannot be cryptographically verified. It illustrates the two fields to record, not a valid signature. A real verification requires the full signed message and the appropriate key and verification process. Do not label a rotation successful from a truncated header, a generated sample string or the presence of a selector name alone.

If a message carries several DKIM signatures, identify the one belonging to the route under change. A passing signature from a different signer does not establish that this replacement works. Retain the relevant verification result with its message reference so the reviewer can connect the evidence to the intended route.

Define the observation plan before the change. In our fictional case, route A can hold already-signed messages in a queue, while route B signs at a later delivery stage. Those routes need different evidence. The relevant question is when a message carrying the old signature can still arrive, not simply when the operator clicked the switch.

Ask each route owner for a justified bound on queueing, retries and any controlled release process. Record the basis for that bound and any exceptions. If the team cannot explain how long already-signed messages may remain in its workflow, retirement is an unresolved decision. Assign that gap to an owner rather than quietly substituting an arbitrary waiting period.

TTL describes DNS cache behavior; it does not bound message delivery delay. Keep the DNS readiness interval and the old-message delivery horizon as separate entries in the plan. Retaining the old public key supports verification of messages still carrying its signature; the decision to stop using the old private key is a different step.

The event ledger below deliberately uses evidence gates rather than a universal number of hours. For this example, route A’s retained queue is the last unresolved item even after route B produces a passing replacement signature.

Retirement should be a separate, reviewable action. Confirm that every in-scope route has stopped creating old-selector signatures, representative replacement signatures verify, and the documented old-message delivery horizon has closed. Record any excluded route explicitly; silence from a route owner is not acceptance evidence.

The reviewer should be able to reconstruct the decision from the record: what changed, which messages were checked, which queues were considered and why the remaining risk was accepted. If an old-selector signature appears unexpectedly, reopen the route inventory. It may reveal an overlooked application, a delayed release or a signer that never switched.

Use the service’s documented retirement process. Some platforms manage key lifecycle steps themselves; others leave DNS removal and key disposal to the customer’s owners. Name the responsible party for each action and capture its completion evidence. Do not assume that deleting a public record destroys a private key, or that disabling a signer removes a record.

Keep the non-secret audit trail after retirement. Future operators need to know which selector replaced which, when the change was observed and who approved it. Archive message evidence according to your own retention rules. The operational record should remain useful without preserving private keys in a shared document.

A routine failure might be a replacement selector that does not resolve as intended, an incomplete switch or a route that no longer verifies. Pause further rollout, preserve the failing message and compare the actual selector and DNS answer with the plan. If the old private key remains secure, available and supported, restoring the old signer may be an option for the authorized owner.

If a rollback resumes the old signer, keep the replacement public key available for messages already signed with it. The overlap obligation runs in both directions: the decision must account for messages created during the attempted change. Capture the rollback time and add those messages to the observation record.

A suspected key compromise changes the objective. An old compromised key is not a safe fallback. Escalate to the incident owner, stop or isolate the affected signing path as appropriate, establish a secure replacement and coordinate revocation through the supported process. RFC 6376 defines an empty p= value as key revocation. Cached answers can limit how quickly a DNS change is visible, so do not describe publication as instantaneous containment.

Revoking a key can also prevent verification of legitimate messages that still carry its signature. The incident owner must weigh that disruption against continued trust in an exposed key. Record the decision, affected routes and recovery evidence. This emergency judgment is separate from the normal retirement criteria and should not inherit a routine waiting period by default.

Use this worksheet as the shared operational record. Store evidence references where the reviewer can access them, and keep private key material in its proper controlled system. Replace every placeholder before the planned switch or mark the missing answer as a blocker with an owner.

The handover is complete when another operator can explain the active selector, the status of both public-key records and the next authorized action. A date alone cannot provide that context.