The single most common reason Microsoft 365 cold email lands in spam isn't the list, the copy, or the volume — it's that DKIM was never actually enabled, because setting up DKIM on Microsoft 365 has a step people don't realize exists. Adding the DNS records isn't enough; you have to flip a toggle in the Microsoft Defender portal. This is a step-by-step Microsoft 365 DKIM setup: the two CNAME records, the portal toggle everyone misses, and how to verify DKIM is actually signing before you send.
Microsoft 365 DKIM Has A Step You Don’t See Coming
Setting up DKIM on Microsoft 365 trips almost everyone up, because it has a step that isn’t obvious: after adding the DNS records, you have to enable DKIM signing in the Microsoft Defender portal. Miss that toggle, and DKIM silently fails.
On most platforms, DKIM is just DNS records — add them and DKIM works. On Microsoft 365, DKIM needs two CNAME records in your DNS plus a separate step: turning on DKIM signing in the Microsoft Defender portal. People add the CNAMEs, see them in DNS, and assume DKIM is working — not realizing the portal toggle is a distinct, required step. Without it, DKIM doesn’t sign, and mail lands in spam despite the records being present.
This hidden step is the single most common reason Microsoft 365 cold email fails authentication and lands in spam. It’s not the list, the copy, or the volume — it’s that DKIM was never actually enabled, because the portal toggle was missed. The DNS records being visible fools people into thinking DKIM is done.
So Microsoft 365 DKIM setup is two parts: the DNS records (obvious) and the portal toggle (hidden). This step-by-step covers both, with emphasis on the toggle people miss, so your DKIM actually signs and your Microsoft 365 cold email authenticates properly.
Microsoft 365 DKIM Setup, Step By Step
Here’s the full Microsoft 365 DKIM setup, step by step. The toggle at step 3 is the one people miss.
Add the two DKIM CNAME records. Microsoft 365 uses two CNAMEs — selector1._domainkey and selector2._domainkey — pointing to Microsoft’s DKIM endpoints for your domain. Add both to your DNS.
Wait for DNS propagation. Give the CNAMEs time to propagate (usually minutes to a few hours) before the next step.
Enable DKIM signing in the Defender portal. Go to the Microsoft Defender portal, find your domain under email authentication settings, and turn on DKIM signing. This is the hidden step — the CNAMEs do nothing until you flip this toggle.
Verify DKIM is signing. Send a test email and check the headers confirm DKIM: PASS, proving the toggle worked.
The four steps: add the two CNAMEs, let them propagate, enable signing in the Defender portal (the hidden step), and verify. The portal toggle at step 3 is what people miss — do it, and DKIM actually signs. Our authentication guide covers all three records.
The Portal Toggle: Where Everyone Gets Stuck
The portal toggle deserves its own focus, because it’s where Microsoft 365 DKIM setup goes wrong for almost everyone. The CNAMEs alone don’t enable DKIM — the toggle does.
Here’s exactly what to do: after the CNAMEs propagate, go to the Microsoft Defender portal (security.microsoft.com), navigate to email and collaboration settings, then policies, then email authentication settings, then DKIM. Find your domain, and turn on “Enable DKIM signing for this domain.” If it won’t let you enable it, the CNAMEs haven’t propagated yet — wait and retry. Once enabled, Microsoft 365 starts signing your outbound mail with DKIM.
🚩 The CNAMEs Do Nothing Without The Toggle
Adding the two DKIM CNAME records to your DNS does not enable DKIM on Microsoft 365. You must also turn on “Enable DKIM signing for this domain” in the Microsoft Defender portal. The CNAMEs being in your DNS fools people into thinking it’s done — but without the portal toggle, DKIM doesn’t sign, and mail lands in spam. The toggle is the step that actually enables DKIM.
So the portal toggle is the crux of Microsoft 365 DKIM setup. The CNAMEs are necessary but not sufficient — the toggle is what actually turns DKIM on. Miss it, and all your other authentication work is wasted because DKIM isn’t signing. Enable it, and DKIM works. This one toggle is the difference between Microsoft 365 DKIM that signs and DKIM that silently fails.
Verifying DKIM Is Actually Signing
After enabling the toggle, verify DKIM is actually signing before you send — because the whole point of this setup is DKIM working, and you should confirm it rather than assume.
To verify: send a test email from your Microsoft 365 inbox to a Gmail address you control. Open the email in Gmail, click the three dots, and choose “Show original.” Look for DKIM: PASS in the results. If it shows DKIM: PASS, DKIM is signing correctly — the toggle worked. If it shows DKIM: FAIL or no DKIM, the toggle isn’t enabled (or the CNAMEs are wrong) — go back and enable signing in the Defender portal. You can also use mxtoolbox.com to check DKIM for your domain.
This verification is essential because Microsoft 365 DKIM can silently fail — the records look present, but DKIM isn’t signing without the toggle. A quick test email header check confirms DKIM is actually working before you send real campaigns. Don’t assume the setup worked; verify DKIM: PASS. So the last step of Microsoft 365 DKIM setup is always verification — confirm DKIM signs, then send. This catches the silent failure that the hidden toggle causes, ensuring your Microsoft 365 cold email is actually DKIM-authenticated.
The Assume-The-CNAMEs-Worked Mistake
The mistake is assuming the DKIM CNAMEs mean DKIM works, skipping the portal toggle and verification — leaving DKIM silently failing while you send into spam.
🚩 Don’t Assume The CNAMEs Enabled DKIM
Adding the DKIM CNAMEs and assuming DKIM works — without the Defender portal toggle or verification — is the classic Microsoft 365 DKIM mistake. The visible CNAMEs fool you; DKIM silently fails; mail lands in spam. Always enable DKIM signing in the portal after adding the CNAMEs, then verify DKIM: PASS in a test email header before sending. The CNAMEs alone don’t enable DKIM.
The correction is to complete all the steps: add the CNAMEs, enable signing in the Defender portal (the hidden step), and verify DKIM: PASS before sending. Don’t assume the CNAMEs enabled DKIM — they don’t, without the toggle. Assuming the records mean DKIM works is why Microsoft 365 cold email silently fails authentication and lands in spam; completing the toggle and verifying is how you confirm DKIM actually signs. The setup isn’t done until DKIM verifies as PASS.
Flip The Toggle, Verify, Then Send
Microsoft 365 DKIM setup has a hidden step — enabling DKIM signing in the Microsoft Defender portal — that people miss because the DNS CNAMEs look like the whole job. Missing that toggle is the single most common reason Microsoft 365 cold email fails authentication and lands in spam.
The steps: add the two DKIM CNAME records (selector1 and selector2), let them propagate, enable “Enable DKIM signing for this domain” in the Defender portal (the hidden step), and verify DKIM: PASS in a test email header before sending. The portal toggle is the crux — the CNAMEs do nothing without it, so flipping it is what actually enables DKIM.
So flip the toggle, verify, then send. Don’t assume the CNAMEs enabled DKIM — complete the portal toggle and confirm DKIM: PASS. Better still, skip the manual setup: pre-warmed Microsoft 365 inboxes arrive with DKIM fully configured — CNAMEs added and the portal toggle already enabled — so DKIM signs correctly with no chance of missing the hidden step. Litemail pre-warmed Microsoft 365 inboxes come with SPF, DKIM (toggle included), and DMARC configured, from $4.99/inbox. Flip the toggle and verify if you’re setting up manually — or let pre-warmed inboxes handle the step everyone misses.
Related Resources
Skip the step everyone misses. Litemail pre-warmed Microsoft 365 inboxes arrive with DKIM fully configured — CNAMEs added, the Defender portal toggle already enabled — plus SPF and DMARC, on dedicated US and EU IPs — from $4.99/inbox, no minimum order — so DKIM signs correctly from day one. Get Pre-Warmed Inboxes → About Litemail — Litemail provides pre-warmed Google Workspace and Microsoft 365 inboxes for cold email outreach. From $4.99/inbox with automated DNS, dedicated US and EU IPs, and full admin access.
Related reading: Authentication Setup · SPF/DKIM/DMARC Setup · Microsoft 365 Troubleshooting · DMARC Fix Guide · Litemail Pre-Warmed Inboxes — Plans and Pricing
Frequently Asked Questions
How do I set up DKIM on Microsoft 365?
Add the two DKIM CNAME records (selector1._domainkey and selector2._domainkey) to your DNS, let them propagate, then enable DKIM signing in the Microsoft Defender portal (the hidden step), and verify DKIM: PASS in a test email header before sending. The portal toggle is required — the CNAMEs alone don't enable DKIM.
Why isn't my Microsoft 365 DKIM working after adding the records?
Almost certainly because you haven't enabled DKIM signing in the Microsoft Defender portal. On Microsoft 365, the CNAME records alone don't enable DKIM — you must also turn on 'Enable DKIM signing for this domain' in the portal. The CNAMEs being in your DNS fools people into thinking it's done, but without the toggle DKIM silently fails.
Where is the DKIM toggle in Microsoft 365?
In the Microsoft Defender portal (security.microsoft.com): go to email and collaboration settings, then policies, then email authentication settings, then DKIM. Find your domain and turn on 'Enable DKIM signing for this domain.' If it won't enable, the CNAMEs haven't propagated yet — wait and retry.
How do I verify Microsoft 365 DKIM is working?
Send a test email from your Microsoft 365 inbox to a Gmail address you control, open it, click the three dots, and choose 'Show original.' Look for DKIM: PASS. If it shows PASS, DKIM is signing correctly. If it shows FAIL or no DKIM, the portal toggle isn't enabled or the CNAMEs are wrong. You can also check with mxtoolbox.com.
Why does Microsoft 365 DKIM cause so many spam problems?
Because the portal toggle is a hidden step people miss. They add the CNAME records, see them in DNS, and assume DKIM works — but without enabling signing in the Defender portal, DKIM doesn't sign, and mail fails authentication and lands in spam. It's the single most common reason Microsoft 365 cold email hits spam.
How does Litemail handle Microsoft 365 DKIM?
Litemail pre-warmed Microsoft 365 inboxes arrive with DKIM fully configured — the CNAMEs added and the Defender portal toggle already enabled — plus SPF and DMARC, on dedicated US and EU IPs from $4.99/inbox. DKIM signs correctly from day one, with no chance of missing the hidden portal toggle that causes silent failures.
Buy Pre-Warmed Email Inboxes & Domains | Litemail
Buy pre-warmed email accounts, inboxes, and domains from $4.99/inbox. Google Workspace and Microsoft 365. Verified reputation, SPF/DKIM/DMARC pre-configured, US and EU IPs, full admin access, no minimum order.
View Plans & Pricing → Related reading: Authentication Setup · SPF/DKIM/DMARC Setup · DMARC Fix Guide · Litemail Pre-Warmed Inboxes — Plans and Pricing
