DKIM key rotation: change the signer without losing the trail

A provider-managed DKIM setup and a manually managed signer are different systems. Amazon SES, for example, documents Easy DKIM and bring-your-own signing approaches. Read the instructions for the mode you use. Do not invent a manual private-key procedure for a service that manages rotation itself, or assume that a provider will maintain a key you supplied independently.

Write down the sending identity, signing mode, region or deployment context, relevant selectors, DNS owner, and secret-management owner. In our hypothetical service, two workers can send the same class of account message. Both need a known configuration source. A diagram saying ‘DKIM enabled’ is not sufficient evidence that every deployment uses the intended signer. Include older environments that can still run scheduled jobs, and retire unused sending credentials through their own reviewed process.

Reference: AWS: Authenticating email with DKIM

A DKIM signature identifies a signing domain and selector so a verifier can look up the corresponding public key. That public record is meant to be discoverable. The private signing material is not. Keep public DNS evidence in the change record while storing any manually managed private key in an approved secret system with narrowly scoped access.

Our maintenance record names a hypothetical old selector and a new selector without including their private values. It records who generated or activated the new configuration, how the signer receives it, and which services can read it. A reviewer should be able to approve the transition without seeing the secret. If an agent helps, give it public records and redacted message headers; exclude key values and unnecessary access to the secret store.

Reference: IETF: RFC 6376

Publishing the new public record is one step, not proof that the signer has changed. For a manually managed transition, make sure the new record is available before relying on it for production signing. Keep the previous public key for as long as your assessment of in-transit messages and provider behavior requires. DNS cache behavior and delivery delay make an arbitrary universal cleanup timer a poor runbook.

For a managed service, use its documented lifecycle and restrictions instead of translating this manual sequence into unsupported API calls. Amazon SES warns that overly rapid key changes can affect authentication of messages in transit. The useful planning question is which component owns the transition and what evidence shows it completed. Make the cleanup condition a reviewable observation rather than a reminder to delete a record regardless of what is still sending.

Send controlled messages through each active path and inspect the delivered source. Record the signing domain, selector, provider configuration revision, and observed authentication result. A dashboard status and a successful DNS lookup prove different pieces of the system. Neither alone proves that a particular production message used the intended key after the transition.

Include a job prepared before the change but dispatched afterward, an active background worker, and the normal application path. If one worker still uses the old configuration, investigate before interpreting that as a malicious signer. Record the results without storing the recipient’s private capability links. Keep acceptance, authentication, and placement as separate observations. A clean DKIM result is valuable evidence, but it should not become a fabricated statement that every message reached the inbox.

• The intended public record is available at the authoritative DNS source.
• Every active sending path uses the reviewed configuration.
• Controlled delivered headers identify the expected signer.
• Old-key cleanup follows the documented transition assessment.
• No private key appears in the review artifacts.

A scheduled change aims to preserve continuity while improving key hygiene. A suspected compromise may require stopping a signer, revoking credentials, assessing unauthorized messages, and involving the security owner. Do not blindly keep a compromised key active simply because the routine maintenance checklist calls for overlap. State which scenario you are handling before deciding what to preserve.

The incident record should distinguish known observations from suspicion. Explain which credential may have been exposed, which sending paths depended on it, and which containment steps are authorized. Changing the DNS record is not the same as removing access to the signing service or stored secret. Coordinate those layers deliberately and preserve appropriate evidence. A template or agent can help communicate the incident, but should not promise recovery or absence of abuse without supporting investigation.

At the end of maintenance, record which selectors remain, who owns them, and why each is still needed. Update the sender inventory and the monitored configuration revision. Remove stale operational assumptions from the runbook rather than accumulating a second set of instructions that contradicts the first. A future DNS cleanup should not have to guess whether an old selector belongs to a retired vendor or a delayed active worker.

Choose a Moosewave operational-email template if you need to announce planned maintenance or explain a verified issue. Keep the message calm and factual: what changed, what was checked, and how someone can get help. The technical record remains separate from the reader-facing copy. A successful rotation is a controlled transition with defensible evidence and no secret leakage, not a screenshot of a green status label.

• AWS: Authenticating email with DKIM. SES signing modes, inheritance, and transition considerations; check the mode used by your identity.
• IETF: RFC 6376. DKIM signing-domain and selector mechanics. Review the listed updates and current provider requirements for algorithms.
• AWS: Easy DKIM. The provider-managed setup; not instructions for a manually managed private key.

Sources checked 13 October 2026. Product behavior and documentation can change, so the linked primary source takes precedence if it differs from this article.