How Often Should You Rotate DKIM Keys? Recommended Schedule and Best Practices

If your DKIM signatures are passing today, it is tempting to leave everything alone. That is exactly how key rotation gets postponed for years.

The safer approach is to treat DKIM keys like any other production secret: rotate on a regular cadence, keep a clean change process, and rotate immediately when risk changes.

So what cadence should you use?

For most teams, a practical baseline is every 3 to 6 months.

That might sound aggressive at first, but with a repeatable runbook it becomes routine maintenance, not a risky event.

The short answer (with real-world context)

Use this schedule as a starting point:

• Low-complexity environment (one sender, good change control): every 6 months
• Typical multi-sender environment (workspace + marketing tool + ticketing): every 3 months
• Higher-risk environment (regulated, high-value targets, strict key policy): every 1 to 3 months

And regardless of your normal cadence, rotate immediately after:

• suspected private key exposure
• DNS or mail admin access incidents
• major vendor or platform migration
• offboarding events where key access was broad

This is less about chasing a perfect number and more about avoiding long-lived keys.

Why providers and standards point you in this direction

The DKIM cryptography update in RFC 8301 establishes the security baseline most operations teams already follow in practice: rsa-sha256, with 1024-bit as minimum and 2048-bit as the practical target.

Mailbox-provider guidance lines up with that:

• Gmail sender guidance requires DKIM for bulk senders and expects modern authentication posture; it also calls out 1024-bit as minimum and recommends 2048-bit keys where supported. See Google's email sender guidelines and Google Workspace DKIM setup.
• Microsoft 365 documents explicit DKIM rotation workflows and timing behavior. See Microsoft's DKIM configuration and rotation guide.
• Yahoo sender requirements also expect authenticated mail and a minimum 1024-bit DKIM key length. See Yahoo sender requirements and recommendations.

None of these documents says "rotate every 97 days." That is normal. Providers define security and deliverability expectations; you still need an operational cadence that your team can execute consistently.

A rotation policy that works in production

If your team is deciding policy this week, start with this:

1. Rotate DKIM keys every 90 days.
2. Use 2048-bit keys unless your platform has a documented exception.
3. Never reuse selector names for new key generations.
4. Keep old selector records published during a drain period.
5. Verify active selector and dkim=pass in real received headers before retiring old records.

That policy is conservative enough to reduce risk, but still manageable for small teams.

If 90 days is too heavy right now, move to 180 days first, then improve process and tighten later. A rotation plan you can actually execute beats an ideal plan that never ships.

Provider-specific details that are easy to miss

Two details regularly trip up otherwise solid teams:

• In Microsoft 365, when you trigger key rotation, the new key does not start signing immediately; Microsoft documents a delay of up to 96 hours.
• In Google Workspace, admins often keep the default selector naming forever. That works technically, but operationally you should still use distinct selectors over time so header forensics stay clear.

Also, if you run multiple sender systems, rotate by stream in small batches (transactional first, then marketing, then support), not all at once. Incident review gets much easier when blast radius is controlled.

A quick runbook you can adapt

Use this sequence to keep rotations boring (boring is good):

1. Generate new key material (prefer 2048-bit).
2. Publish under a new selector in DNS.
3. Wait for DNS propagation and cache expiry.
4. Switch signer config to the new selector.
5. Send test traffic and confirm DKIM-Signature shows new s= value.
6. Confirm Authentication-Results shows dkim=pass.
7. Keep prior selector published through a drain window.
8. Remove old selector after delayed traffic has cleared.

For message-header troubleshooting patterns, keep DMARC troubleshooting with Authentication-Results headers bookmarked.

Common schedule mistakes

Most DKIM rotation pain comes from operations mistakes, not cryptography:

• rotating only after incidents
• reusing selector names
• deleting old DNS records too quickly
• rotating all sending systems at the same time
• not recording key creation and next rotation dates

A tiny tracker (domain, selector, created date, next rotation date, owner) prevents most of this.

Bottom line

If you need one decision today, set DKIM rotation to every 90 to 180 days and put it on the calendar now.

Then improve from there: unique selectors, overlap windows, and header-based verification on every change.

If you want a deeper selector process, read DKIM selectors and key rotation playbook and DKIM Key Rotation: Is Rotating Selectors Important?.