Microsoft 365 DKIM 2048-bit: why you run it twice

Microsoft 365 rotates DKIM keys without you touching DNS. One cmdlet does it. There is no TXT value to copy and no propagation to wait out.

Upgrading from 1024-bit to 2048-bit is where people come unstuck. It takes two runs of that cmdlet, four days apart. After the first one the config reports healthy and nothing complains, but half your DKIM is still 1024-bit.

How Microsoft 365 holds two selectors

Every custom domain signing with Microsoft 365 has two selectors, selector1 and selector2. Both are published as CNAME records pointing at keys Microsoft holds. You never see a private key and you never paste a public one.

Only one of them signs. Microsoft's own documentation1:

Only one selector is active and used when DKIM signing using a custom domain is enabled. […] The other selector is inactive. It's activated and used only after any future DKIM key rotation, and then only after the original selector is deactivated.

The second selector is there so a rotation has somewhere to go. Its CNAME is already published and already resolving. That record has been in your zone since the day you set DKIM up, so a rotation needs no DNS change from you.

Microsoft 365 keeps two selector records published and signs with one of them. Rotation moves signing to the other one. That is why there is no DNS edit and no gap. The selector that signed a message is in the s= value of its DKIM-Signature header.

Google Workspace works differently. You generate the key in the Admin console and publish the TXT record at your own DNS host11. The Google Workspace version of this job has its own failure modes.

Why 2048, and why every six months

Two recommendations, from two places. Keep them apart.

The key size comes from the standard. RFC 8301 says signers MUST use RSA keys of at least 1024 bits, and SHOULD use at least 20482. So a 1024-bit key still conforms. It is the weaker of the two options on offer, and our own DKIM checker flags it on that basis.

The rotation interval comes from M3AAWG, which says to rotate DKIM keys "at least every six months"3. The same document, last revised in March 2019, still calls 1024 bits "the current recommended length". So if you have seen 2048 credited to M3AAWG, including on this site before today, that credit was misplaced. RFC 8301 is the source for 2048.

A key that has signed your mail untouched since 2019 has had years to leak. The upgrade and the rotation are the same cmdlet, so do both at once.

Before you start

Rotation needs a domain that already works. Microsoft requires the DKIM toggle set to Enabled and a status of Valid or CnameMissing4. If yours is disabled, or its CNAMEs were never published properly, fix that first as its own job. Enabling DKIM and changing its key size on the same afternoon means two changes and one set of symptoms.

The commands

Check every cmdlet below against Microsoft's own documentation before running it against a live tenant. Ours included. The Exchange Online PowerShell docs are one search away.

Connect to Exchange Online. The module is ExchangeOnlineManagement, and -UserPrincipalName takes the account you sign in with12:

Connect-ExchangeOnline -UserPrincipalName [email protected]

This one is read-only. Look at what you have before you change anything. It is Microsoft's own verification command. The property names matter: it is Selector1CNAME, not Selector1CnameValue5:

Get-DkimSigningConfig -Identity yourdomain.com | Format-List Name,Enabled,Status,
    Selector1CNAME,Selector1KeySize,
    Selector2CNAME,Selector2KeySize,
    KeyCreationTime,RotateOnDate,
    SelectorBeforeRotateOnDate,SelectorAfterRotateOnDate

Four of those fields tell you where you are in a rotation:

• RotateOnDate is the date and time of the previous or the next rotation.
• SelectorBeforeRotateOnDate names the selector DKIM uses before that date and time.
• SelectorAfterRotateOnDate names the one it uses after.
• KeyCreationTime is the UTC date and time the current key pair was created, which is the number the six-month rule turns on.

The two selector fields are defined relative to RotateOnDate, not to now. While a rotation is pending, SelectorBeforeRotateOnDate is the one signing your mail; once RotateOnDate has passed, SelectorAfterRotateOnDate is.

Read the two KeySize values. If either says 1024, you have work to do.

This next command is a write. It generates new keys and switches to the alternate selector. -KeySize takes 1024 or 2048 and nothing else6. While a rotation is in progress you cannot start another one13:

Rotate-DkimSigningConfig -Identity yourdomain.com -KeySize 2048

The gotcha, straight from Microsoft's own docs

You would expect both selectors to be 2048-bit after that. Only one of them is. The cmdlet's own reference page says so7:

Upgrading the key size to 2048 only upgrades the selector that isn't currently active. After key rotation has taken place, you need to run the command again to upgrade the key size of the other selector.

One run upgrades the inactive selector and hands signing over to it. The selector that had been signing keeps its old 1024-bit key, ready for next time. Half your DKIM is upgraded, the config reports healthy, and nothing tells you otherwise.

The second run is the same command:

Rotate-DkimSigningConfig -Identity yourdomain.com -KeySize 2048

Not straight away, though. Microsoft takes four days (96 hours) before the new private key starts signing, and the existing key carries on until then14. You cannot hurry it, because a rotation already in progress blocks another one. Run it, wait the 96 hours, confirm RotateOnDate has passed and that the s= value on a message that has just arrived names the selector in SelectorAfterRotateOnDate, then run it again.

Put the second run in the calendar as soon as you finish the first. Four days is long enough to forget.

"Both my selectors already say 2048, can I rotate now?"

Yes, and one run is enough.

If your check comes back like this:

Selector1KeySize : 2048
Selector2KeySize : 2048

there is nothing left to upgrade. The twice-over routine only exists to move both selectors up a bit depth.

Rotate for freshness instead. Both selectors reading 2048 tells you the key size is current. It says nothing about how long those keys have been signing, which is what KeyCreationTime is for. If that date is more than six months old, rotate, and leave -KeySize off:

Rotate-DkimSigningConfig -Identity yourdomain.com

Same handover, same 96 hours, one run. Diarise the next one.

About those CNAME records

Be careful which format you copy. Microsoft changed it in May 2025. New custom domains get:

selector1._domainkey  CNAME  selector1-<domain-with-dashes>._domainkey.<initial-prefix>.<char>-v1.dkim.mail.microsoft

<char> is a partition character Microsoft assigns; you cannot choose it. Domains configured before the change keep the older form, pointing into <tenant>.onmicrosoft.com, and Microsoft says the two formats "can't coexist for the same selector"8. Both are still in use. Our own domain resolved the old way on 6 September 20269:

$ dig +short CNAME selector1._domainkey.osh.co.za
selector1-osh-co-za._domainkey.outsourcehouse.onmicrosoft.com.
$ dig +short CNAME selector2._domainkey.osh.co.za
selector2-osh-co-za._domainkey.outsourcehouse.onmicrosoft.com.

So treat the values here, or in any article, as illustrations. Take yours from Selector1CNAME and Selector2CNAME in the command above.

Verify from outside, not from PowerShell

After any rotation, confirm where you landed:

Get-DkimSigningConfig -Identity yourdomain.com | Format-List Selector1KeySize,Selector2KeySize,Status,
    RotateOnDate,SelectorBeforeRotateOnDate,SelectorAfterRotateOnDate,KeyCreationTime

Then check it the way a receiving server does. Run the domain through the DKIM checker and the Microsoft 365 checker, send a real message, and read the Authentication-Results header on what arrives. The s= value in the DKIM-Signature header names the selector that signed it.

PowerShell can report healthy while DNS says otherwise. DNS is the one that delivers your mail.

Our take

Microsoft 365 DKIM is the easy platform. The cmdlet does the work and the handover is seamless. The trap when moving from 1024 to 2048 is stopping after the first rotation and leaving a 1024-bit selector in place.

There are other ways to get DKIM wrong here, and Microsoft lists the usual ones. They are mostly DNS: the hostname entered with the domain appended, a missing selector2 record, a TXT record where a CNAME belongs, a trailing dot10. If DKIM is failing and the key size is fine, look there next.

Whether you are upgrading or keeping keys fresh, put the next rotation in the calendar. Six months, every time.

With DKIM clean, the next step is enforcement: taking DMARC from p=none to p=reject.

What to do

1. Connect-ExchangeOnline, then run the read-only Get-DkimSigningConfig above and read both KeySize values, KeyCreationTime, RotateOnDate and the two selector fields.
2. If either size is 1024: Rotate-DkimSigningConfig -KeySize 2048, diarise 96 hours, confirm RotateOnDate has passed and the s= on a fresh message names the other selector, then run it again.
3. If both are already 2048 and KeyCreationTime is over six months old: one plain Rotate-DkimSigningConfig, no -KeySize.
4. Confirm from outside with the DKIM and Microsoft 365 checkers, read s= on a real message, and diarise the next rotation.

What this article was checked against

Every claim above was verified against a primary source on 29 August 2026 and re-verified on 6 September 2026. Microsoft renames console pages and changes record formats without much warning, so re-run the commands rather than trusting the date on this page.

1. Only one selector is active and used; the other is inactive and is activated only after a key rotation, once the original is deactivated. — Set up DKIM to sign mail from a Microsoft 365 domain ↩
2. Signers MUST use RSA keys of at least 1024 bits and SHOULD use at least 2048 bits. — RFC 8301 §3.2 ↩
3. Keys should be rotated at least every six months; the same document calls 1024 bits "the current recommended length", which is why it is not a source for the 2048 recommendation. — M3AAWG DKIM Key Rotation Best Common Practices, March 2019 ↩
4. Key rotation requires the domain's DKIM toggle set to Enabled and a status of Valid or CnameMissing. — Set up DKIM to sign mail from a Microsoft 365 domain ↩
5. The verification command and its property names, including Selector1CNAME and Selector2CNAME. — Set up DKIM to sign mail from a Microsoft 365 domain ↩
6. The KeySize parameter's only valid values are 1024 and 2048, and the cmdlet creates new DKIM keys and uses the alternate selector. — Rotate-DkimSigningConfig (ExchangePowerShell) ↩
7. Quoted verbatim: upgrading to 2048 only upgrades the selector that is not currently active, and the command must be run again for the other one. — Rotate-DkimSigningConfig (ExchangePowerShell) ↩
8. The DKIM CNAME format introduced for new custom domains in May 2025, the dynamically assigned partition character, and that existing domains keep the old format. — Set up DKIM to sign mail from a Microsoft 365 domain ↩
9. Both CNAME formats are in service. Resolved 6 September 2026 against a domain configured before the change; the full commands and their output are printed above. — CNAME checker · dig +short CNAME selector1._domainkey.osh.co.za · dig +short CNAME selector2._domainkey.osh.co.za ↩
10. The documented common DKIM mistakes: wrong CNAME hostname format, missing selector2 record, TXT instead of CNAME, domain mismatch in the target, trailing dots. — Set up DKIM to sign mail from a Microsoft 365 domain ↩
11. Google Workspace generates the DKIM key in the Admin console and has the administrator add the public key as a TXT record at their own domain host. — Google Workspace Admin Help: set up DKIM ↩
12. The module is ExchangeOnlineManagement, and the documented interactive connection example is Connect-ExchangeOnline -UserPrincipalName <UPN>. — Connect to Exchange Online PowerShell ↩
13. "While the key rotation is in progress, you can't do another key rotation." — Set up DKIM to sign mail from a Microsoft 365 domain ↩
14. It takes four days (96 hours) for the new private key to start signing messages; until then the existing private key is used. The same page defines RotateOnDate, SelectorBeforeRotateOnDate, SelectorAfterRotateOnDate and KeyCreationTime. — Set up DKIM to sign mail from a Microsoft 365 domain ↩

Check what Microsoft 365 is publishing for your domain today.