Prepare the rotation before touching either key
A DKIM rotation is a coordinated change to a signer, a selector and the public verification material receivers discover. Generating a new key or copying a DNS record does not complete it. The preparation should establish who holds the private key, how the service changes signing behavior, which messages may still require the previous public key and how the team will respond if verification fails.
The workflow below is proposed and product-neutral. It does not verify an EmailAuth key vault, rotation engine, provider integration or approval feature. No key was generated, imported, exported, revoked or published, and no signer or DNS setting was inspected. Preparing the plan must remain separate from those security-sensitive actions.
Build a selector and custody inventory
For each in-scope sending stream, record the signing domain, current selector, algorithm, public-key fingerprint and responsible service instance. Identify the private-key custodian without copying the private material into the inventory. Note whether a managed provider generates and holds the key or whether an organization-controlled signer does so. Ownership of DNS is not the same as custody of the signing key.
A selector identifies the verification key in the context of the signing domain. Different selectors allow distinct keys to coexist, which supports a staged transition where the implementation permits it. Avoid overwriting an existing selector merely because a short example calls it “default.” The old selector may still be needed by messages already signed with its key. RFC 6376, sections 3.1 and 3.6.
Apply current cryptographic requirements explicitly
RFC 8301 updates the older DKIM algorithm rules: rsa-sha1 is not acceptable for signing or verification; RSA signers must use keys of at least 1024 bits and should use at least 2048 bits. Record the chosen algorithm and size rather than describing an unspecified key as “secure.” Existing provider and organizational requirements may be stricter. RFC 8301, sections 3.1 and 3.2.
RFC 8463 adds Ed25519-SHA256 and describes using separate selectors when signing with both old and new algorithms. Its verifier requirement does not prove that every deployed receiver or managed sending service supports the intended configuration today. Any algorithm transition needs evidence from the actual service and relevant receiving paths. A smaller key is not a reason to skip interoperability checks. RFC 8463, sections 5 and 6.
Verify the provider sequence rather than assuming it
Determine whether the service supports preparing a new key without interrupting the current signer, how it exposes public material and what operation triggers cutover. A provider’s “generate” or “enable” action may have effects beyond preparing text. The agent should flag uncertainty before an administrator invokes it. Do not promise a zero-interruption rotation from the generic DNS sequence alone.
The Google Workspace DKIM setup page returned an inaccessible redirect during this research and was not retried. Community discussions are not used to establish its current rotation behavior. Separately available Gmail sender guidance describes receiver key-length expectations, but that is not evidence of a Google Workspace control-panel sequence. The actual provider procedure remains an applicability gate. Google sender guidelines.
Stage publication and signer cutover as separate changes
Where supported, the plan should separate authorized key creation, public-key publication, verification of published material and the change that makes the signer use the new selector. Each stage needs an expected result and a stop condition. An agent can assemble the preview and compare approved public values, but private-key generation or transfer belongs to the explicitly authorized custody workflow.
Record the complete proposed DNS owner and the exact public material, along with the current-state evidence and authorized tenant. A public key may be public, yet publishing it changes who can produce signatures receivers associate with that selector. Delegating a selector to a provider is also a control decision. Approval must cover the actual operation, not just the general intent to rotate.
Treat overlap as an evidence-based interval
A fictional rotation might move a service from selector r2026a to r2026b while retaining the former public key during an approved overlap. The team would need to establish when all signers stopped using the old selector and account for queued or delayed messages that already carry it. These selectors are illustrative labels, not deployed records or test results.
DNS cache behavior, message queue lifetime, signature expiration and provider operation are different considerations. No single TTL proves that the old key can be retired everywhere. Define the retirement decision from the relevant evidence and operational risk. If the old private key is suspected compromised, routine overlap and rollback assumptions must be reconsidered by the incident owner; restoring a compromised signer is not a safe default recovery action.
Define the evidence that can stop or complete the change
The proposed test should capture a controlled message signed with the intended domain and new selector, trusted receiver verification and its DMARC alignment. A valid signature from an unrelated domain does not close the intended alignment test. A DNS lookup showing the new key is only one prerequisite. RFC 9989, section 4.4.
Aggregate reports can provide later supporting observations, including DKIM information, but reporting periods and coverage limit what they establish immediately. Do not retire a selector simply because a dashboard has not shown it recently. Keep the controlled message, signer configuration evidence and reporting observations separately identified. RFC 9990, sections 3.1.3 and 3.3.
Hand over the tested plan and custody record
A tested key-rotation or incident plan with selector inventory, custody and recovery evidence. This exact requirement remains open. Before the plan becomes an execution recommendation, the key custodian and mail owner must approve the provider sequence, cutover conditions, retirement criteria and recovery path. Current product controls, real selector inventory, custody evidence and reproducible verification results have not been demonstrated here.