How to rotate DKIM keys safely

22 June 2026 · 5 min read

To rotate a DKIM key without failures, publish the new public key under a new selector, confirm it resolves, switch signing to it, and leave the old public key published until mail signed with it has been delivered. Never overwrite the key under the selector you are signing with. M3AAWG's DKIM Key Rotation Best Common Practices recommend rotating at least every six months.

Why rotate at all

Anyone who obtains your private DKIM key can sign mail that passes DKIM, and DMARC, as your domain. The longer a key is in use, the more backups, server migrations and former staff it has been exposed to. Rotating limits how long a leaked key stays useful. M3AAWG's guidance is to rotate at least twice a year, and immediately if you suspect a key has been exposed.

Rotation is also when you move from a 1024-bit key to 2048 bits, which RFC 8301 recommends. DKIM key length: 1024 versus 2048 bits covers publishing the longer key.

Why selectors make it safe

The public key lives at <selector>._domainkey.<domain>, and each signature names its selector in the s= tag (RFC 6376):

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s202610; ...

The receiver looks up s202610._domainkey.example.com to verify. Two selectors are two independent DNS records, so an old key and a new key can be published side by side, and every message is checked against the key it was actually signed with.

If you instead replace the key under the selector you are signing with, mail signed with the old private key, and resolvers still caching the old public key, both produce verification failures until everything catches up.

The procedure

1. Generate a new key under a new selector

Use a name that tells you when it was made, such as s202610, rather than default. Use a 2048-bit RSA key.

If your provider manages DKIM for you, it handles the key and the selector; see the provider notes below.

2. Publish the new public key

Add the TXT record (or the CNAME your provider gives you) at the new selector. Leave the old record alone. Two selectors published at once is the intended state.

s202610._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

3. Check it before you sign with it

dig +short TXT s202610._domainkey.example.com

You should see the complete p= value. A truncated value, a record split into two separate TXT records, or a record that has not appeared yet will make every signature fail as soon as you switch. The DKIM checker confirms the key parses and reports its size. Wait at least the record's TTL so resolvers everywhere see it.

4. Switch signing to the new selector

Change your mail server or provider to sign with the new private key and selector. New mail now verifies against the record you just checked.

5. Keep the old public key, then retire it

Mail signed with the old key may still be queued, retried or delayed. M3AAWG's example keeps an old public key available for 7 to 30 days so in-transit mail still validates. Once your DMARC reports show no more traffic under the old selector, remove its record, or revoke it by publishing an empty key, which RFC 6376 defines as meaning the key has been revoked:

s202604._domainkey.example.com.  TXT  "v=DKIM1; p="

A worked timeline

Providers that manage the key

• CNAME-based providers (Microsoft 365, and many sending platforms) host the keys behind CNAME records you publish once. Microsoft 365, for example, uses two selectors and a Rotate DKIM keys button in the Defender portal; Microsoft says a rotation takes four days to complete, and no DNS change is needed as long as both CNAMEs stay published. DMARC for Microsoft 365 covers the details.
• TXT-based providers generate a new key and give you a new record to publish. Follow the same order: publish, verify, then activate in the provider's console.

M3AAWG notes that with third-party senders, the rotation request must come from the domain owner. If a platform signs as your domain, ask it how it rotates.

Confirming success in your reports

DMARC aggregate reports list, for each source, the DKIM result with the signing domain and selector. After a rotation you want to see:

1. DKIM passing, aligned, under the new selector for every source that should be using it.
2. The old selector's volume falling to zero before you retire it.

The DMARC report analyser shows which selector signed what. Set up reporting before you rotate, so a failure shows up in data rather than in complaints.

Mistakes that cause failures

• Overwriting the key under the active selector. Always add a new selector.
• Switching before the new record resolves everywhere. Check, and wait out the TTL.
• Removing the old key straight away. Mail in transit still needs it.
• A truncated or wrongly split key. Re-fetch the published record and check the end of the p= value.
• Forgetting other senders. Each platform that signs as your domain has its own selector and its own rotation. Keep a list of every selector you publish.
• Changing the signing domain by accident. Rotation changes the selector, not d=. If a new provider signs with a different domain, check that it still aligns with your From address.

Making it routine

• Rotate at least every six months, and immediately after a suspected exposure.
• Use dated selector names so each record documents itself.
• Keep an inventory of every selector and the system that signs with it.
• Script the key generation where you can; M3AAWG recommends automation to reduce mistakes.

Hosted DKIM generates keys, manages selectors and handles rotation for the services that sign as your domain.