How to Rotate DKIM Keys Without Breaking Your Mail

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.

What's in This Guide

• What Can Go Wrong With an Old DKIM Key?
• Whose Job Is DKIM Key Rotation?
• How Often Should You Rotate DKIM Keys?
• How Do You Rotate a Key Without Breaking Signing?
• How Do You Confirm the Rotation Worked?
• FAQ
• The Practical Takeaway

What Can Go Wrong With an Old DKIM Key?

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.

Whose Job Is DKIM Key Rotation?

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:

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.

How Often Should You Rotate DKIM Keys?

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:

• A suspected compromise means rotating immediately, and revoking the old key as soon as the new key is in use, instead of keeping it published for 7 to 30 days as in the overlap procedure below. Delayed legitimate mail signed with the old key will then fail DKIM, but so will forgeries signed with the stolen key.
• Offboarding a vendor or an employee who had access to signing infrastructure means rotating the keys they could have copied.

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.

How Do You Rotate a Key Without Breaking Signing?

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.

1. Generate the new key pair and publish the public key in DNS under a new selector. M3AAWG strongly discourages reusing selector names, and a name that includes the date, such as mail-202604, lets you sort your selectors by when each key went into use.
2. Wait until the new record is visible in public DNS: a DNS lookup of the new selector's name, for example 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.
3. Switch signing on your mail server to the new private key. New mail now carries the new selector in its s= tag, and receiving servers verify it against the new public key.
4. Keep the old key's record published for 7 to 30 days. Receiving servers can still verify mail signed before the switch, including delayed and queued deliveries, because the old public key is still published.
5. Revoke the old key by changing its record to 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.

How Do You Confirm the Rotation Worked?

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.

FAQ

Do you need a new selector name for every rotation?

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.

Does rotating keys break emails you already sent?

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.

Does key rotation change under DKIM2?

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.

The Practical Takeaway

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.