Incident
Microsoft 365 Email Authentication: What's Changed and What to Check
Microsoft has progressively tightened email authentication requirements for Microsoft 365. DKIM is now effectively required for custom domains — and SPF alone is no longer sufficient for reliable inbox delivery.
Microsoft 365 has been tightening how it treats custom-domain senders: SPF alone no longer reliably lands in the inbox — you need DKIM keys published and signing enabled, or DMARC alignment breaks and mail junked or rejected.
What changed
Microsoft 365 now strongly enforces DKIM alignment for custom domains. Emails without DKIM configured are increasingly landing in Junk or being rejected.
The key change many missed: adding include:spf.protection.outlook.com to your SPF record is not enough. You also need:
- selector1 and selector2 CNAME records published in your DNS
- DKIM signing enabled in Microsoft 365 Defender
Without these, M365 signs email with Microsoft's domain — not yours. DMARC alignment fails.
The error in bounce logs
What to do
Check alignment
Open DNS Preflight →FAQ
Is SPF alone enough for Microsoft 365?
No longer. Microsoft now expects DKIM configured for custom domains. SPF + DKIM + DMARC is the required setup.
What are the selector1 and selector2 CNAMEs?
Two CNAME records that let Microsoft sign email with your domain's DKIM key instead of Microsoft's. Required for DMARC alignment. Get exact values from Defender → DKIM settings.
My M365 email was working fine without DKIM — why is it failing now?
Microsoft has been tightening enforcement progressively. What worked a year ago may now trigger spam filtering or rejection.
Does this affect all M365 customers?
All customers with custom domains should configure DKIM. @outlook.com/@hotmail.com addresses are handled automatically.
How do I verify M365 DKIM is working?
Run DNS Preflight — the alignment engine checks selector1 and selector2 CNAMEs and shows pass/fail.