Microsoft 365 Deliverability Fixes for Cold Email Agencies
Microsoft 365 has stricter spam filtering and lower sending limits than Google Workspace. Here's what causes deliverability failures and how to fix them.
Microsoft 365 accounts are increasingly popular for cold email — partly because GWS inboxes are harder to get and partly because M365 domains can look more corporate. But M365 has its own set of deliverability challenges, and Outlook's spam filters are notably more aggressive than Gmail's in certain areas.
Why M365 is different from GWS for cold email
Microsoft's filtering infrastructure (Exchange Online Protection, or EOP) uses different signals than Gmail. It's particularly aggressive about filtering based on sending IP reputation and authentication alignment. It also has lower sending limits — 10 sends per inbox per day is the safe ceiling for cold email, compared to 15 for GWS.
Common causes of M365 spam placement
1. Missing or wrong SPF record
M365 requires a specific SPF record: v=spf1 include:spf.protection.outlook.com -all. Using ~all (softfail) instead of -all (hardfail) is technically permissible but can weaken your position with some filters. More commonly, operators forget to update SPF when adding M365 to an existing domain. Check yours at /tools/spf.
2. DKIM not enabled
DKIM signing is not enabled by default in M365. You must activate it in the Microsoft 365 Defender portal. The selectors are selector1 and selector2. Use the DKIM checker to confirm they're published and valid.
3. Sending above safe limits
M365's safe sending limit for cold email is 10 per inbox per day. Exceeding this risks account flagging. With M365, the per-account limits are enforced more strictly than with GWS. Use the sending limit planner to build your ramp correctly.
4. New domain with no history
Microsoft weighs domain age heavily. New domains sending cold email immediately are at significant risk of EOP filtering. The minimum recommended age is 30 days, with 60–90 days being safer for M365 specifically.
5. Outlook-to-Outlook filtering
When your recipient also uses Outlook/M365, Microsoft's filtering applies at both ends. This creates double-filtering that makes deliverability harder. For campaigns targeting corporate Outlook users, GWS inboxes often perform better than M365-to-M365.
6. Poor sending IP reputation
M365 shared IPs can have variable reputation. If Microsoft's shared sending infrastructure has recent abuse from other tenants, your email can be caught. This is more of an issue with lower-tier M365 plans that use shared IP pools.
The M365 setup checklist
- SPF:
v=spf1 include:spf.protection.outlook.com -all - DKIM: enabled in M365 Defender, both selectors published in DNS
- DMARC:
v=DMARC1; p=none; rua=mailto:your@email.comminimum - Domain age: 30+ days minimum, 60+ preferred
- Sending limits: max 10/inbox/day, ramp over 3+ weeks
- Max 3 inboxes per domain
Diagnosing M365 placement failures
Run a placement test and check the authentication results in the headers. If DKIM shows as a failure, that's your primary fix. If auth is clean but placement is still spam, it's a reputation issue requiring a slower recovery approach.
When to stop trying to save an M365 setup
M365 accounts that have been sending aggressively and are flagged by Microsoft are extremely difficult to recover. Microsoft's filtering is less transparent than Google's, and the delisting process for M365-flagged domains is slower. If a client campaign is active and the M365 setup is damaged, replacement is often the faster path.
If you need replacement sending infrastructure while an M365 setup recovers, the key is having pre-warmed inboxes ready to deploy without a warmup period. WarmInboxes is one source for this. Run the diagnostics above first to confirm you're dealing with reputation damage and not a fixable auth issue.
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.