Do I Need to Rotate My DKIM Keys? When and Why It Matters

Yes, but only if you control the sending infrastructure or manage a client domain through a migration. If you use Google Workspace, Microsoft 365, or another major provider with CNAME delegation, they rotate automatically and you never touch the key yourself. The exception is a stale selector left in DNS after switching platforms, which breaks signing silently.

What is a selector?

A DKIM selector is a DNS label that tells receiving servers where to find your public key (valimail.com). It appears as the s= value in every outgoing email's DKIM-Signature header. When your mail server signs a message, it specifies a selector. The receiving server then queries selector._domainkey.yourdomain.com to retrieve the public key and verify the signature.

DKIM selectors make it possible to run multiple signing keys simultaneously across different ESPs like Microsoft 365, Google Workspace, HubSpot, and SendGrid (powerdmarc.com). Each platform can have its own selector, so both can coexist under the same domain without conflict. This also makes key rotation possible without downtime, since you can publish a new key under a different selector before retiring the old one.

Why do providers rotate on their own?

DKIM keys should be rotated at least every six months, reducing the risk of active keys being compromised, either by attackers cracking or stealing them. Most email vendors and third-party email service providers enable automatic DKIM key rotation for customers, such as Microsoft supporting automatic DKIM key rotation for their Office 365 users (powerdmarc.com).

Microsoft 365 manages the DKIM keys and handles key rotation automatically. The CNAME record delegates key management to Microsoft (learn.microsoft.com). Mailgun's Automatic Sender Security generates two 2048 bit DKIM selector records via TXT records, which are automatically rotated every 120 days by default (documentation.mailgun.com). Mailgun rotates every 120 days by default (mailreach.co).

The M3AAWG recommends six-month rotation because leaving keys unchanged increases the window an attacker can exploit if a private key leaks through a server breach or exposed configuration file. Providers automate this specifically so it happens on schedule without manual intervention or the risk of copy-paste errors during DNS updates.

When does a stale key silently break signing after a migration?

When you switch from one email service to another, the new platform generates a new private key and signs all outgoing messages with it. But the public key in DNS still belongs to the old provider. The receiving server tries to verify the new signature against the old key. It fails every time and will continue to fail until someone updates the DNS entry.

This happens when a domain migrates from Mailchimp to SendGrid, or from Google Workspace to Microsoft 365, or from any hosted mail platform to another. The new provider signs with a different selector or a different key under the same selector name. DNS still publishes the old provider's public key. Every outbound message fails DKIM, but the admin console may still show DKIM as enabled. Mail already signed with the old key, but delivered after the record disappears, starts failing for no reason anyone can see in the new configuration.

The signing mail server generates a new private key, but the DNS record is not updated simultaneously. An Email Service Provider (ESP) rotates their signing keys without updating your published TXT record or CNAME target. A domain is migrated to a new hosting platform while the email server continues signing with an old selector or retired key pair.

To catch this, check the s= value in the DKIM-Signature header of a test message sent through the new platform, then query selector._domainkey.yourdomain.com using dig or an online DNS lookup. If the record returns nothing, or if it returns a public key that belonged to the previous provider, update the TXT or CNAME record to match what the new platform specifies in its admin panel. The free AI-visibility check (/check) includes DNS record validation across SPF, DKIM, and DMARC, which surfaces mismatches like this before they accumulate into a deliverability problem.

Do you need to manually rotate if the provider does it automatically?

No. If you delegate DKIM to a provider via CNAME, they rotate the key behind that CNAME without requiring you to touch DNS again. Always create both CNAME records, even though only one selector is active at any given time. The inactive selector is needed for uninterrupted key rotation. Microsoft, for example, publishes selector1 and selector2. Only one signs at a time. When Microsoft rotates, it switches which selector is active and updates the key behind the inactive one. After you trigger rotation, Microsoft does not switch signing immediately. The new key activates over a period of up to 96 hours, during which both keys may sign mail.

If you manage your own mail server or use a platform that generates keys you manually publish as TXT records (not CNAME), you own the rotation process. That means generating a new key pair, publishing it under a new selector, updating the mail server to sign with the new key, running both selectors in parallel for at least a few days to account for mail in transit, and only then retiring the old DNS record. Always allow time for DNS propagation and mail flow completion before deletion.

For MSPs managing multiple client domains, ActiScore's pricing (/pricing) includes DNS health checks across all 10 security categories, surfaced in the same white-labeled report clients already receive for their website audit. You can audit DKIM, SPF, and DMARC alignment for every domain you manage without logging into each DNS provider individually. Clients sending 5,000 or more messages per day are subject to Google's bulk sender requirements, which mandate working DKIM authentication. A stale selector after migration is the most common silent failure that breaks compliance without triggering an immediate bounce or alert, especially when the domain owner receives mail normally and assumes outbound is fine.

Regular rotation matters most when you control the private key directly. If you do not, verify that CNAME delegation is in place and that both selectors resolve correctly. If you migrated platforms in the last 12 months, check the guide (/guide) for a step-by-step breakdown of how to verify your current signing configuration matches what is published in DNS, since that mismatch is the single most common cause of DKIM failure post-migration.