DKIM key rotation is the scheduled replacement of the key pair that signs your email: you publish a new public key in DNS under a new selector, switch signing to the new private key, and retire the old pair.
The Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG), an industry association that publishes best practices for email operators, recommends rotating DKIM keys at least every six months, in case a key is stolen.
This guide is for teams that have DKIM passing and manage their own domains or client domains. It tells you everything you need to know about how to rotate DKIM keys, as well as what can happen if you don't.
If you are still working out which keys sign for your domain, start with our guide to finding your DKIM selector; this article picks up where that one leaves off.
A compromised key lets an attacker send messages that authenticate as your domain. The private key never appears in DNS: it is stored on the mail servers and sending platforms that sign your messages, and an attacker who breaches one of these can copy it.
The attacker then signs a message of their own with your private key. The receiving mail server fetches your public key from DNS and verifies the signature.
Because the signing domain matches the domain in your From address, the message also passes DMARC, the check that compares the authenticated domain with the From address. Receiving servers apply your DMARC policy only to mail that fails DMARC, so even at p=reject they deliver a message signed with your own key.
This risk is the reason M3AAWG gives for regular rotation: the shorter the time a key pair is in use, the shorter the time a compromised key remains usable.
You can tell whose job a rotation is from two things: the type of DNS record published for each selector, and whether the platform signing with each selector rotates keys on their own schedule. To see the record type, open your domain's DNS settings (at Cloudflare, GoDaddy, your domain registrar or wherever you manage DNS) and find the records whose names start with your selector followed by ._domainkey. The Type column next to each record says TXT or CNAME.
If someone else manages your DNS, check the DKIM setup page in each sending platform instead: it lists the records you were asked to add, either CNAME records or one TXT record holding a long key value.
A TXT record holds the public key itself, so every new key means publishing a new TXT record in your DNS. The rotation is therefore your work, even when the platform generated the key pair, as Google Workspace does.
A CNAME record at the selector's name is an alias that points to a record the platform controls. The platform holds the private key and can publish each new public key in this record, without any change to your DNS.
The record type tells you who is able to replace the key. It does not tell you when a replacement happens: some platforms rotate on their own schedule, others wait for you to start the rotation. Here is how four sending platforms handle rotation:
| Sending platform | Who holds the private key | How rotation happens |
|---|---|---|
| Microsoft 365 | Microsoft; your two CNAME records (selector1, selector2), published once, point to key records Microsoft controls | You start it, with "Rotate DKIM keys" in the Defender portal or the Rotate-DkimSigningConfig cmdlet in Exchange Online PowerShell. Microsoft switches signing to the new key four days (96 hours) after you start the rotation, according to their documentation. |
| Google Workspace | Google; you publish the public key as a TXT record | Manual. In the Admin console, you generate a new record under a new selector prefix, add it as a new TXT record at your domain host, then start authentication. |
| Salesforce (Sales Cloud) | Salesforce; your CNAME records point to key records Salesforce controls | Automatic. Salesforce rotates the key every 30 days. |
| Amazon SES (Easy DKIM) | AWS; AWS generates the key pair with Easy DKIM and signs your mail with it (2048-bit by default) | Nothing for you to schedule. AWS holds the key, and the Easy DKIM documentation describes no rotation step for the domain owner. |
Every key published as a TXT record, and every key whose platform waits for you to start the rotation, as Microsoft 365 does, is a key you rotate yourself. For a sending platform outside this table, check the same two things: the record type at its selector, and the provider's documentation on who starts a rotation. The Salesforce case, including the setup for each Salesforce product, is covered in our guide to DMARC with Salesforce-sent email.
If you manage DKIM for client domains, M3AAWG's guidance is that the rotation request comes from the domain owner. Agree each rotation date with your client, and make your DNS and signing changes on that date.
For the keys you rotate yourself, M3AAWG's recommendation is at least every six months. In their DKIM Key Rotation Best Common Practices, M3AAWG members compared rotation frequencies and chose this one as the balance between the risk of a compromised key and the work of replacing it. The document suggests fixed dates outside your busiest sales periods, e.g., April and October for an online store.
Rotate before the scheduled date in two situations:
Check the key length at every rotation. RFC 8301 requires signers to use RSA keys of at least 1024 bits and recommends 2048, so if the DNS record for a selector still contains a 1024-bit key, generate its replacement at 2048 bits.
With the two-selector overlap, you replace a key without a single failed signature, because the selector in every message points to a public key that is still published in DNS. During the overlap, both public keys stay published, each under its own selector, while you switch signing from the old private key to the new one.
The steps below assume your own mail server signs your mail. On a platform that generates the key pair for you, such as Google Workspace, you create the new key and switch signing in the platform's admin console, and you still publish and later revoke the DNS records yourself.
mail-202604, lets you sort your selectors by when each key went into use.mail-202604._domainkey.yourdomain.com, returns the new public key. Your mail server does not sign with the new key yet, so no signature can fail while you wait.s= tag, and receiving servers verify it against the new public key.v=DKIM1; p= (an empty p= value). RFC 6376 defines an empty value as a revoked key. M3AAWG recommends keeping the record in DNS rather than deleting it, so a receiving server that looks up the old selector finds a key that was retired on purpose instead of a missing record.Microsoft 365 runs the same overlap on their side: both selectors stay published, and Microsoft switches signing to the new key four days (96 hours) after you start the rotation.
If your domain's DMARC record has a rua= tag (the address that receives reports), receiving servers send DMARC aggregate reports to this address. These reports show the rotation: messages signed with the new selector start passing, and messages signed with the old selector stop appearing. M3AAWG recommends an audit about a week after each rotation: compare the selector receivers saw against the selector that was scheduled to be active.
A retired selector that keeps appearing in your reports means something is wrong. The two causes to check first are a service nobody rotated that still signs with the old key, and a key rotated on one side only. In the second case, the mail server signs with one key while the DNS record contains another, and receiving servers fail those messages' DKIM check.
DMARCeye reads the reports for you and lists the selectors your mail is signed with on each domain, so you can see a selector that should have stopped appearing. The free plan covers one domain.
For platforms that use common selector names, such as Microsoft 365's selector1 and selector2, the free DKIM checker below shows the key published under each selector and its key strength. Use it to spot a 1024-bit key that is due for replacement at 2048 bits. It does not look up custom names such as mail-202604.
Yes. M3AAWG strongly discourages reusing selector names: once the record under a reused name contains the new key, receiving servers fail the DKIM check of every message signed with the old key, including mail still in transit. A name that includes the rotation date, such as billing-202604, also shows when each key went into use.
No, as long as you keep the old key published during the overlap. Receiving servers verify a signature when the message arrives, and you keep the old key published for 7 to 30 days so that delayed mail signed with it arrives and passes before you revoke it. After the revocation, mail that was already delivered stays delivered, and only a later re-check of an old message fails.
Under the current DKIM2 drafts, you rotate keys the same way. The IETF is working on DKIM2, a planned rework of DKIM, and its DNS draft specifies the same key model: senders publish public keys under selectors in DNS and revoke a key with an empty p= value.
DKIM key rotation is a scheduled job, and your schedule only has to include the keys you rotate yourself. A compromised key then stays usable only until the next scheduled rotation, instead of until someone notices an incident.
Sort your sending platforms by the record type at each selector and by whether each platform rotates keys on their own schedule. Put every key you rotate yourself on a twice-a-year schedule, and rotate sooner after a suspected compromise or when someone with access to your signing keys leaves. Run each change as a two-selector overlap, so no message ever points at a missing key.
If you receive DMARC aggregate reports, they confirm each rotation: it is done when messages signed with the new selector pass and the old selector stops appearing, on the date you planned. DMARCeye shows which selectors your mail is signed with on each of your domains, so you can check every rotation as the daily reports arrive.