Context
Replacing a DKIM key affects a signing system, a DNS record and the receivers checking delivered messages. A rotation plan should describe how those components overlap. The objective is to update the signing material without creating an unexplained authentication gap for legitimate business mail.
Identify every signer and selector
Inventory the platforms signing messages for the domain and the selectors they use. Record the owner of the sending service and the administrator of the authoritative DNS zone. Different providers can use different selectors and operational procedures. Confirm whether the organization manages the private key or the provider handles it. Keep private signing material out of change tickets and shared documents. A DNS record alone does not establish which active system is currently using the corresponding selector.
Review the provider's rotation procedure
Check the supported steps and prerequisites for the actual platform rather than applying one provider's console sequence to another service. Google Workspace, for example, documents its own DKIM configuration process and DNS publication requirements. Determine how the new selector is introduced and when signing switches. Consider cached DNS answers and messages already in transit when deciding how long prior public verification records should remain available. Avoid removing the old record simply because the new key has been generated.
Verify messages through representative routes
Send controlled messages before and after the signing change and inspect the selector, signature result and domain alignment relevant to the organization's policy. Include important application or forwarding paths where they are part of the mail architecture. Distinguish a DKIM failure caused by message modification from a key-publication problem. Record the identifiers and authentication results without distributing real customer message bodies. Confirm that monitoring can detect a rise in failures during the transition.
Complete retirement with an accountable review
Retire previous material according to the supported procedure and the agreed overlap policy. Update the signer inventory and remove temporary administrator permissions used for the change. Document who owns the next rotation and how an urgent signing incident would be escalated. Re-test critical senders after other email-platform changes, because a successful rotation does not permanently validate every mail path. The handover should connect the active selector, tested message evidence and ownership of the DNS and signing components.
Discuss the environment, constraints and acceptance criteria with Clouvenix email security specialists before scheduling production changes.
Technical reference
Official platform documentation. Confirm options, support status and operational behavior for the installed release. The workflow above is an engineering review approach, not a universal configuration recipe.