Is rotating every 90 days required by DKIM?

No. DKIM does not mandate that universal interval. An organization can choose it as policy if platforms and operations support it.

Can I keep the same selector and replace the key?

No. RFC 6376 advises against selector reuse for new keys. A new selector makes old and new signatures distinguishable during transition.

How long should the old key remain in DNS?

Long enough for messages already in transit or deferred verification, plus the organization's rollback window. The protocol does not prescribe one duration for every mail system.

Should I rotate a provider-managed CNAME?

Only when the provider's documented model requires it. A stable CNAME may let the provider rotate keys behind its target, while another platform requires a new selector record.

What if a private key is exposed?

Treat it as an incident. Stop signing with it, deploy a new selector and key, revoke or remove the compromised key, and investigate unauthorized use.

How often should you rotate DKIM keys?

DKIM does not define one universal rotation interval. Set a risk-based schedule that your sending platforms and DNS process can support, and rotate immediately after suspected private-key exposure, unauthorized access, or a provider transition. Use a new selector for the new key, publish it before switching production signing, keep the old public key available during the verification window, then retire it. Key strength, inventory, and evidence of successful production signing matter more than an arbitrary calendar number.

Quick takeaways

No DKIM RFC mandates one rotation interval for every sender.
Use new selectors instead of replacing key material behind an old selector.
Publish the new public key before production starts using it.
Keep the old public key during the transition so delayed verification can succeed.
Rotate immediately when a private key may be compromised.

Rotate DKIM keys without a signing gap, shown as a four-step technical sequence.

This diagram summarizes the article's diagnostic sequence. Use the linked standards, current provider documentation, and production evidence for exact decisions. Open the full-size diagram.

Who is affected?

Every domain that authorizes a mailbox provider, ESP, gateway, or internal MTA to sign with DKIM owns some part of the key lifecycle. In hosted systems, the provider may generate and store the private key while the customer publishes CNAME or TXT records.

MSPs need an inventory that ties each client, sending service, signing domain, selector, owner, and last verified production use together. The DKIM overview explains how those fields appear in a message.

What are the requirements?

RFC 6376 uses selectors to support routine replacement. During a transition, old and new public keys can coexist. Outbound systems switch to the new selector, and the old key remains published until messages signed with it have had a reasonable opportunity to be verified.

The RFC advises against reusing a selector with new key material because a verifier cannot distinguish a message signed by the old key from a forgery after the replacement. New key, new selector is the clearer operational rule.

RFC 8301 requires RSA keys of at least 1024 bits and recommends at least 2048 bits. That strength requirement does not create a fixed rotation interval. Use provider capability, exposure risk, access control, cryptographic policy, and incident history to set cadence.

When does the requirement take effect?

The transition rules apply whenever a key is replaced. Scheduled rotation should occur before a key exceeds the organization's documented lifetime. Incident rotation begins as soon as compromise is suspected and should not wait for the ordinary calendar.

Provider-managed rotation can follow a different workflow. Confirm whether a CNAME delegates the selector to the provider or whether a new account-generated TXT value must be published.

How do I implement the requirement?

1. Inventory active selectors and owners

Map each selector to its signing domain, platform, key type, strength, DNS owner, private-key custodian, and current message stream. Remove unknown ownership before automating changes.

2. Generate a new key under a new selector

Use the provider's account-specific workflow or a controlled signing system. Do not reuse another tenant's value or expose private material in tickets and documentation.

3. Publish and verify the new public key

Allow DNS to propagate and confirm the exact selector from more than one resolver. Keep the current key in place.

4. Switch signing and observe production

Change outbound signing to the new selector. Inspect new delivered messages and DMARC data for every route that service uses.

5. Retire the old selector safely

After the transition window and rollback period, stop publishing the old key or explicitly revoke it according to the platform's procedure. Record the change and next review date.

How do I validate compliance?

Check the new selector in DNS, then inspect messages delivered through each production path. Confirm the signature passes, uses the intended signing domain, and aligns for DMARC where expected. Search recent traffic for unexpected continued use of the old selector before removal.

Use the DNS lookup tool for selectors and Email Security Score for the surrounding public configuration. Key custody and production use still require internal and message-level evidence.