# How to rotate DKIM keys without breaking email

URL: https://iblockspam.com/blog/dkim-key-rotation
Last updated: 2026-10-09
Published: 2026-10-09
Topic: SPF, DKIM & DMARC
Author: iBlockSpam Team

> How often to rotate DKIM keys, which key length to use, how to name selectors, and how to rotate in Microsoft 365, Google Workspace and on your own server.

## Short answer

Rotate DKIM keys at least every six months, as M3AAWG recommends, and use 2048-bit RSA keys. Publish the new key under a new selector first, switch signing to it once DNS has updated, keep the old public key published for at least seven days, then revoke it with an empty p= value. Microsoft 365 automates most of this.

A DKIM key that never changes is a key an attacker has unlimited time to steal or crack. Rotation replaces it on a schedule, so any compromise is short-lived and your team stays practiced. This guide covers how often to rotate, which key length to use, how to name selectors, and the exact steps for Microsoft 365, Google Workspace and a self-managed mail server.

If you haven't set up DKIM yet, start with our [DKIM setup guide for Microsoft 365 and Google Workspace](https://iblockspam.com/blog/dkim-setup-microsoft-365-google-workspace), then come back here.

## Why rotate DKIM keys at all?

DKIM ([RFC 6376](https://www.rfc-editor.org/rfc/rfc6376.html)) signs your outgoing mail with a private key. Receivers check the signature with the public key published in DNS. Anyone who gets the private key can sign mail that passes DKIM as your domain, and that can carry a DMARC pass too.

The [M3AAWG DKIM Key Rotation Best Common Practices](https://www.m3aawg.org/DKIMKeyRotation) give three reasons to rotate:

- **Limit exposure.** "Minimizing the amount of time a key pair is in use ensures that, even if the key is compromised, the damage can be contained to a reasonably short period of time."
- **Keys can be stolen, not just cracked.** Long keys are harder to crack, but a private key is "still vulnerable to being stolen if an attacker is able to compromise the system in which it is stored."
- **Practice.** Regular rotation keeps the know-how alive, so an emergency rotation after a compromise is routine, not a scramble. M3AAWG calls frequent rotation "a useful drill."

## How often should you rotate DKIM keys?

M3AAWG's answer is plain: "DKIM keys should be rotated at least every six months." Its April 2018 revision changed the earlier quarterly recommendation to six months, to balance risk against operational effort. It suggests fixing the dates, for example "rotating keys each April and October," and notes that less complex mail flows can rotate more often.

Rotate outside the schedule when:

- a server that held a private key may have been compromised
- someone who had access to the private keys leaves
- you end a contract with an email service that signed as your domain
- you find a key shorter than 2048 bits

## What key length should DKIM use?

Use 2048-bit RSA. [RFC 8301](https://www.rfc-editor.org/rfc/rfc8301.html) sets the rules:

| Rule (RFC 8301) | Requirement |
|---|---|
| Signers, minimum | "MUST use RSA keys of at least 1024 bits" |
| Signers, recommended | "SHOULD use RSA keys of at least 2048 bits" |
| Verifiers | "MUST be able to validate signatures with keys ranging from 1024 bits to 4096 bits" |
| Short keys | Verifiers "MUST NOT consider signatures using RSA keys of less than 1024 bits as valid" |
| Hash algorithm | "Signers MUST sign using rsa-sha256"; "rsa-sha1 MUST NOT be used" |

M3AAWG's 2018 document described 1024-bit keys as "currently at the edge of attack for general purpose computer systems," and said 2048-bit keys were "considered to be immune to cracking in today's computing environment." That's a strong reason to move to 2048 bits at your next rotation.

Larger keys mean longer DNS records. A 2048-bit key is longer than the 255 characters allowed in one TXT string, so many DNS hosts need it split into several quoted strings in the same record. M3AAWG also notes that your DNS servers need to "support EDNS0 or TCP-based record fetches" for long keys. Our [DKIM setup guide](https://iblockspam.com/blog/dkim-setup-microsoft-365-google-workspace) shows how to split a key.

## How should you name DKIM selectors?

The selector (`s=` in the signature) is the label in front of `._domainkey`. Rotation works by moving to a new selector, so plan the names. To see which selector you're signing with today, follow [how to find your DKIM selector](https://iblockspam.com/blog/find-dkim-selector).

- **Never reuse a selector.** M3AAWG says reuse is "strongly discouraged": it "will cause old messages to fail any re-validation attempts when checked against the new key value," and receivers may hold stale cached values.
- **Put a date in it.** M3AAWG suggests names that show the stream, the date the key goes live and its length, such as `sales-201309-1024`. A simple version for a small business is `s202610` (October 2026).
- **One stream, one key.** M3AAWG says it is "not recommended to share the same DKIM keys across several entities." Give each sending service its own selector.
- **Keep an inventory.** List each domain, sending service, selector, key length and go-live date. It makes audits easy.

## The general rotation process

M3AAWG's workflow keeps two keys published at all times, so you're never signing with a key receivers can't find:

1. **Publish the next key early.** Generate a new key pair and publish the public key under a new selector. Don't sign with it yet.
2. **Wait for DNS.** Confirm the new record resolves from public DNS. The [DKIM Checker](https://iblockspam.com/tools/dkim-checker) shows the key and its length.
3. **Switch signing.** Point your mail server or service at the new private key and selector.
4. **Keep the old public key.** Leave it unchanged "for a minimum of seven days, and up to 30 days," so receivers can still verify mail sent before the switch. RFC 6376 gives the same advice: the old public key "should be retained for a reasonable validation interval."
5. **Revoke, don't delete.** Replace the old record with an empty key (`p=`). RFC 6376 says "an empty value means that this public key has been revoked." M3AAWG says: "Do not delete the selector entry."
6. **Audit.** About a week later, check the `s=` and `d=` values on fresh messages. The [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer) shows both.

M3AAWG also recommends pre-publishing the next public key so that an emergency rotation only needs the mail administrator.

## How to rotate DKIM keys in Microsoft 365

Microsoft 365 handles most of this for you. Its two CNAME records (`selector1` and `selector2`) point to keys Microsoft hosts, and only one is active at a time. Of the inactive one, Microsoft says: "It's activated and used only after any future DKIM key rotation" ([Microsoft Learn](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure)). You don't edit DNS to rotate, but both CNAMEs must exist.

### In the Defender portal

1. Go to `https://security.microsoft.com/authentication` (**Email & collaboration** > **Policies & rules** > **Threat policies** > **Email authentication settings**) and open the **DKIM** tab.
2. Select the domain. It must show **Enabled** with a status of **Valid** or **CnameMissing**.
3. In the details flyout, select **Rotate DKIM keys**.
4. The status changes to "Rotating keys for this domain and signing DKIM signatures."
5. Wait. Microsoft says: "After four days (96 hours), the new DKIM key signs outbound messages for the custom domain. Until then, the current DKIM key is used."

### In Exchange Online PowerShell

Check the current state first:

```powershell
Get-DkimSigningConfig | Format-List Name,Enabled,Status,Selector1KeySize,Selector2KeySize,KeyCreationTime,RotateOnDate,SelectorBeforeRotateOnDate,SelectorAfterRotateOnDate
```

Then rotate, moving to a 2048-bit key at the same time:

```powershell
Rotate-DkimSigningConfig -Identity example.com -KeySize 2048
```

Leave out `-KeySize` to keep the current length. Points to know, all from [Microsoft Learn](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure):

- `RotateOnDate` shows when the new key takes over. `SelectorAfterRotateOnDate` shows which selector it uses.
- If you change from 1024 to 2048 bits, "the update applies only to the next active selector during the first key rotation." The other selector moves to 2048 at the following rotation, so rotate twice to upgrade both.
- "While the key rotation is in progress, you can't do another key rotation."
- `New-DkimSigningConfig` creates 1024-bit keys by default, so check older domains.
- The [Rotate-DkimSigningConfig](https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/rotate-dkimsigningconfig) reference says only RSA keys are supported, not Ed25519.
- "There's no automatic DKIM key rotation for the \*.onmicrosoft.com domain."

To confirm the switch, look at the `s=` value in a new message's `DKIM-Signature` header.

## How to rotate DKIM keys in Google Workspace

Google's [Set up DKIM](https://knowledge.workspace.google.com/admin/security/set-up-dkim) help doesn't describe a separate rotation feature. You rotate by generating a new key with a new prefix (selector), which Google allows: if a prefix is already in use, "enter a different prefix in this field." This matches the approach in our [setup guide](https://iblockspam.com/blog/dkim-setup-microsoft-365-google-workspace).

1. In the Admin console, go to **Apps** > **Google Workspace** > **Gmail** > **Authenticate email** and select the domain.
2. Click **Generate New Record**. Choose **2048** bits if your DNS host supports it.
3. Enter a new prefix selector, for example `google202610`, instead of the one in use.
4. Publish the TXT record Google shows at your DNS host. Leave the old record in place.
5. Wait for the new record to resolve, then click **Start authentication**. Google says DKIM can take up to 48 hours to start working after you add a key.
6. Send a test to an outside mailbox and confirm `dkim=pass` with the new selector.
7. Keep the old TXT record for at least seven days, as M3AAWG advises. Then replace its value with `v=DKIM1; p=` to revoke it.

Each domain in your Google Workspace account needs its own key.

## How to rotate DKIM keys on your own mail server

On a self-managed server, you own the whole process. The exact signing configuration depends on your software, but the steps are the same.

1. **Generate a 2048-bit key pair** on the signing server:

   ```
   openssl genrsa -out s202610.private 2048
   openssl rsa -in s202610.private -pubout -out s202610.public
   ```

   If you'd rather not use the command line, the [DKIM Key Generator](https://iblockspam.com/tools/dkim-generator) creates a 2048-bit key pair in your browser and formats the TXT record for your new selector.

2. **Publish the public key** as a TXT record. Strip the header and footer lines and join the base64 into one value:

   ```
   s202610._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..." "...IDAQAB"
   ```

3. **Wait and verify** that the record resolves, using the [DKIM Checker](https://iblockspam.com/tools/dkim-checker) with selector `s202610`.
4. **Switch the signer** to the new private key and selector, then reload the mail service.
5. **Send a test** to an outside mailbox and confirm `dkim=pass` and `s=s202610` in the headers.
6. **After seven to 30 days**, set the old selector's record to `v=DKIM1; p=`.
7. **Protect the private key.** Restrict file permissions to the signing service. M3AAWG warns never to send a private key by unencrypted email.

If a third party signs mail for you, M3AAWG describes options that avoid sending the private key between companies: the provider generates the key pair and gives you only the public key to publish, or you delegate selectors to the provider by CNAME, the model Microsoft 365 uses. Either way, agree in advance when each key will be rotated out.

## DKIM rotation checklist

| Step | Microsoft 365 | Google Workspace | Own server |
|---|---|---|---|
| New key published before signing | Automatic (second selector) | You publish a new TXT | You publish a new TXT |
| Key length | `-KeySize 2048` | Choose 2048 | `openssl genrsa ... 2048` |
| Switch-over time | Four days (96 hours) | Up to 48 hours | When you reload the signer |
| Old key retirement | Managed by Microsoft | Empty `p=` after 7+ days | Empty `p=` after 7+ days |
| Verify | `s=` in DKIM-Signature | `dkim=pass` and new selector | `dkim=pass` and new selector |

## Next steps

1. List every service that signs mail as your domain, with its selector and key length. The [DKIM Checker](https://iblockspam.com/tools/dkim-checker) shows key lengths.
2. Upgrade any 1024-bit key to 2048 bits at the next rotation.
3. Book two rotation dates a year in your calendar, such as April and October.
4. Make sure DKIM aligns with your From domain so DMARC can rely on it. Our [SPF vs DKIM vs DMARC](https://iblockspam.com/blog/spf-vs-dkim-vs-dmarc) guide explains alignment, and iBlockSpam's [outbound relay](https://iblockspam.com/features/outbound-relay) signs relayed mail with DKIM.

Browse our other [SPF, DKIM and DMARC guides](https://iblockspam.com/blog/topic/authentication).

## Frequently asked questions

### How often should DKIM keys be rotated?

M3AAWG recommends rotating DKIM keys at least every six months and suggests fixed dates, such as April and October. Simpler mail setups can rotate more often. Rotate immediately, outside the schedule, if you think a private key has been exposed, for example after a server compromise or when a sending vendor relationship ends.

### Will rotating my DKIM key break email delivery?

Not if you overlap the keys. Publish the new public key and wait for DNS to update before signing with it. Then keep the old public key published so messages already in transit can still be verified. M3AAWG suggests keeping it for at least seven days and up to 30 days.

### Should I delete the old DKIM record after rotation?

M3AAWG advises against deleting it. After the overlap period, retire the key by publishing the selector with an empty p= value. RFC 6376 says an empty p= means the key has been revoked, which tells receivers the key was retired on purpose rather than missing by mistake.

### Can I reuse an old DKIM selector name?

Avoid it. M3AAWG strongly discourages reusing selector names, because old messages will fail re-validation against the new key and receivers with stale cached values can fail current mail. Use a naming scheme with a date, such as s202610, so every key gets a fresh selector.

### Does Microsoft 365 rotate DKIM keys automatically?

Microsoft manages the keys behind its two CNAME selectors, so you never edit DNS to rotate. You start a rotation in the Defender portal or with Rotate-DkimSigningConfig, and Microsoft says the new key starts signing after four days (96 hours). There's currently no automatic rotation for the onmicrosoft.com domain.

## Sources

- [M3AAWG: DKIM Key Rotation Best Common Practices (revised April 2018)](https://www.m3aawg.org/DKIMKeyRotation)
- [RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM](https://www.rfc-editor.org/rfc/rfc8301.html)
- [RFC 6376: DomainKeys Identified Mail (DKIM) Signatures](https://www.rfc-editor.org/rfc/rfc6376.html)
- [Microsoft Learn: How to use DKIM for email in your custom domain](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure)
- [Microsoft Learn: Rotate-DkimSigningConfig](https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/rotate-dkimsigningconfig)
- [Google Workspace Admin Help: Set up DKIM](https://knowledge.workspace.google.com/admin/security/set-up-dkim)

## Free tools for this guide

- [DKIM Key Generator](https://iblockspam.com/tools/dkim-generator): Create a DKIM key pair and the DNS TXT record for your selector — keys are generated in your browser.
- [DKIM Checker](https://iblockspam.com/tools/dkim-checker): Validate DKIM keys by selector, including key type and strength.
- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.
- [DMARC Checker](https://iblockspam.com/tools/dmarc-checker): Check your policy, reporting and the safe path from p=none to reject.

---

Source: iBlockSpam, https://iblockspam.com/blog/dkim-key-rotation (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt