How to Fix Microsoft 365 Cold Email Deliverability After Domain Setup
You set up M365, configured DNS, started sending — and emails are going to Junk. Here's where the setup went wrong and how to fix it.
You set up Microsoft 365 for cold email outreach. DNS records are configured. You start sending and emails are going to Junk on Outlook and sometimes spam on other providers. The setup should be working but something is wrong.
Why This Happens
Microsoft 365 setup for cold email has several common pitfalls that differ from Google Workspace setup:
DKIM setup in M365 is not straightforward. Microsoft requires you to publish two CNAME records for DKIM (selector1 and selector2) and then enable DKIM signing in the Microsoft 365 admin center. If you only published the DNS records but didn't enable signing, your emails are not DKIM-signed.
SPF for Microsoft 365 requires including spf.protection.outlook.com in your SPF record. If this is missing or you have the wrong include value, SPF fails.
DMARC alignment can fail if the envelope sender domain doesn't match the header From domain. This is common when using shared tenants or certain routing configurations.
Microsoft 365's default sending limits are relatively low. New tenants are particularly restricted. If you exceed these limits, Microsoft may throttle or block your sending.
Step-by-Step Diagnosis
Verify SPF by checking your DNS TXT record includes include:spf.protection.outlook.com and that you have no more than one SPF record. Use the SPF checker.
Verify DKIM by checking that both selector1 and selector2 CNAME records exist in DNS and that DKIM signing is enabled in the Microsoft 365 admin center under Exchange, then DKIM. Use the DKIM checker to confirm both selectors are published and valid.
Verify DMARC by confirming you have a DMARC TXT record and checking alignment in test email headers. Use the DMARC lookup.
Send test emails to accounts across Gmail, Outlook, and Yahoo. Check placement on each provider. Run a full placement test to get the complete picture including authentication results.
If you're also using a third-party outreach tool alongside Microsoft 365, determine which infrastructure is actually sending your cold emails. The outreach tool may bypass Microsoft's SMTP entirely — meaning your Microsoft DNS setup is not being used for those sends.
The Fix Path
Complete DKIM setup if it's only partially done. Both CNAME records must exist in DNS and signing must be enabled in the admin center.
Fix SPF to include Microsoft's servers. Remove old includes if you migrated from another provider.
Set up DMARC with at least p=none and monitoring enabled: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
Stay within M365 sending limits. Warm up the inbox by sending low-volume emails that generate engagement before launching cold campaigns. The same 2–4 week warmup principle applies to M365 as it does to Google Workspace. Use the sending limit planner with M365 selected to configure your ramp.
Use the launch checklist to verify all setup elements before your first send.
When to Replace Instead of Repair
If the issues are configuration mistakes, they're straightforward to fix. Correct your DNS, enable DKIM signing, and start warmup. Deliverability should improve within a few days to a week.
If you've been sending cold email from a misconfigured M365 setup for weeks and have accumulated reputation damage, recovery takes longer. Reduce volume, fix configuration, and allow 2–4 weeks of low-volume warmup to rebuild. If you need M365 inboxes performing immediately for B2B campaigns, WarmInboxes can provide properly configured and prewarmed Microsoft 365 accounts ready for production.
Mistakes That Make This Worse
- Publishing DKIM DNS records without enabling signing in the admin center
- Exceeding tenant sending limits on a new M365 setup
- Having multiple SPF records
- Not warming up M365 inboxes because "they're a paid email service"
- Assuming your outreach tool is using M365's infrastructure when it might be sending through its own servers
Run the checks first
Before replacing anything, run a free inbox placement test. You might find the issue is DNS, not the domain — and save yourself a week of unnecessary work.