How often should you rotate DKIM keys?

When the rotation answer changes

A routine schedule is appropriate when you know which system controls the private key, who can change DNS, and which applications use the signing domain. The schedule should be short enough to limit the lifetime of a key and long enough that your team can perform a complete, verified transition without breaking mail.

The answer changes immediately when the private key may be compromised. Treat suspected exposure, unauthorized access to the signing system, or an unapproved transfer of key material as a reason to stop using the affected key and begin a controlled replacement. The protocol does not define an incident timetable, but waiting for a scheduled date leaves the potentially exposed key usable for longer.

Provider-managed DKIM can change the work you perform. Some providers ask you to publish account-generated TXT or CNAME records and control the private key themselves. Others require you to generate, activate, or rotate keys in their interface. Follow the provider's current documentation for that platform, and do not replace a provider-managed record with a value copied from another account.

Use this decision rule:

• If the current key is trusted and ownership is known, rotate on your documented schedule with a new selector.
• If the private key may be exposed, rotate immediately under an incident process.
• If the sending provider manages the key, confirm its documented rotation model before changing DNS.
• If you cannot identify the sender or selector owner, inventory the path before removing any key.

Do not delete an old selector as soon as the new record appears in DNS. Messages already signed with the old selector can still need the old public key for verification.

A worked DKIM selector transition

This illustrative DNS shape shows two public keys during a planned transition. The actual selector names and public-key values must come from your signing platform or controlled key-generation process. Do not publish example values as production records.

selector1._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=<current-public-key>"
selector2._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=<replacement-public-key>"

The first record remains available while existing production traffic may still carry s=selector1. After the outbound signer uses s=selector2, inspect real delivered messages from each sending path. When the old selector no longer appears in the agreed observation window and your rollback window has ended, remove or revoke the old public key according to the platform's procedure.

This sequence separates four kinds of evidence:

• DNS: Query the exact new selector through authoritative DNS and at least one public resolver.
• Vendor: Confirm the sending platform reports the new DKIM configuration as active, if it provides that status.
• Message: Send a real message through each production path and inspect its Authentication-Results header. RFC 8601 defines the Authentication-Results field.
• DMARC: Review aggregate-report data after it accumulates to see whether the expected sending paths authenticate and align.

Check the evidence you have

If you have a selector and domain, use the DKIM checker to inspect the public DKIM record. Compare the returned record with the selector your platform says it is using. This check can reveal a missing or malformed public record, but it cannot show whether a particular application is currently signing with that key.

If you have access to the sending platform, verify its current DKIM status and send a test message through the exact production route. Inspect the delivered message headers for the signing domain and selector. A passing DKIM result does not by itself prove DMARC alignment, because DMARC compares the DKIM signing domain with the visible From domain.

If you manage a provider-specific configuration, retain the provider's generated values and change history. For example, the Salesforce DKIM key setup guide covers the provider-specific DNS pattern used for Salesforce-managed keys.

For teams responsible for several domains or sending platforms, the ongoing gap is source inventory. A public check can show the record published today, but it cannot identify every production sender that still uses an old selector or show later authentication failures. Palisade analyzes DMARC aggregate-report data to identify sending sources and authentication or alignment issues, then proposes prioritized remediation work for human review.

Start with Palisade

Palisade does not change the DKIM key, alter your DNS, or prove every future message will authenticate. Review the evidence and apply any change through your approved process.