On May 5, 2025, Microsoft began enforcing bulk sender requirements for all email sent to Outlook, Hotmail, and Live.com mailboxes. Non-compliant bulk mail now returns a permanent 550 5.7.515 rejection — the email is refused, not deferred. It never reaches the recipient.
This was the third major enforcement action from a top-tier mailbox provider in 18 months:
- February 2024: Gmail and Yahoo began enforcement
- May 2025: Microsoft Outlook began enforcement
- September 2025: La Poste began enforcement
Together, these four providers cover the majority of consumer email inboxes globally. If your authentication or sending practices were non-compliant, you’ve almost certainly been experiencing delivery failures since May 2025 — whether or not your ESP surfaced them clearly.
Microsoft Outlook Enforcement — Key Facts
What Microsoft Requires
Microsoft’s bulk sender requirements closely mirror Gmail’s and Yahoo’s, with some differences in how they weight certain signals.
Authentication (Required)
SPF (Sender Policy Framework) Your domain must have a valid SPF record that includes your sending IP addresses or authorized sending services. SPF failures significantly increase the risk of rejection.
DKIM (DomainKeys Identified Mail) All bulk mail must be signed with a valid DKIM signature. Your email service provider typically handles DKIM signing — verify that it’s configured correctly for your sending domain.
DMARC
A DMARC record must be published at your sending domain. The minimum policy is p=none (monitoring mode). Microsoft does not require p=quarantine or p=reject, but having a DMARC record is mandatory for bulk senders.
One-Click Unsubscribe (Required)
Bulk mail must include RFC 8058 compliant List-Unsubscribe and List-Unsubscribe-Post headers enabling one-click unsubscribe. Recipients must be removed within 48 hours of opting out.
This is the same requirement Gmail and Yahoo enforce. Most major ESPs (Klaviyo, Mailchimp, HubSpot, BayEngage, and others) add these headers automatically for campaign emails. Verify your ESP is doing so by checking the raw headers of a sent email.
Valid Forward and Reverse DNS
Your sending IP must have:
- Forward DNS: The IP resolves to a hostname
- Reverse DNS (PTR record): The hostname resolves back to the sending IP
PTR records are set by whoever controls your sending IP — usually your ESP. If you’re on shared IPs, your ESP manages this. If you’re on dedicated IPs through a provider that gives you infrastructure control, verify PTR records are set correctly.
Low Spam Complaint Rate
Microsoft monitors complaint rates through its built-in feedback mechanisms and applies similar thresholds to Gmail:
- Below 0.10%: Acceptable
- 0.10%–0.30%: Warning zone — expect increasing filtering
- Above 0.30%: High risk of rejection
How Microsoft’s Filter Differs from Gmail’s
Understanding the differences helps you diagnose provider-specific placement issues.
IP reputation is weighted more heavily by Microsoft. SmartScreen — Microsoft’s email filtering system — places significant weight on the historical reputation of your sending IP address. Gmail weighs domain reputation and engagement more heavily. This means:
- If you’re on a shared IP that another sender abused, you may see Outlook placement issues even if your own practices are clean
- Dedicated IP senders have more direct control over Outlook deliverability
- A reputation problem at Outlook that doesn’t appear at Gmail is more likely to be IP-level than domain-level
Engagement signals matter less to Microsoft. Gmail famously uses whether recipients open, reply to, or move your email out of spam as a positive reputation signal. Microsoft’s SmartScreen is more content and IP-focused. This means that sending very frequently to disengaged Outlook subscribers hurts you primarily through complaint rate accumulation, not through Gmail’s engagement-signal mechanism.
Microsoft uses its own blocklists. Microsoft Defender’s blocklist and SmartScreen reputation database are separate from Spamhaus, Barracuda, and other common blocklists. Being clear on common blocklists doesn’t guarantee Outlook delivery if Microsoft’s own systems have flagged your IP or domain.
Checking for 550 5.7.515 Errors in Your ESP
If Microsoft enforcement has affected your sending, you’ll see 550 5.7.515 errors in your ESP’s bounce logs or delivery failure reports. Here’s how to check in common ESPs:
- Klaviyo: Account → Deliverability Hub → Bounces; filter by error code
- Mailchimp: Campaign → View Report → Bounces; check bounce reason text
- BayEngage (TargetBay): Deliverability dashboard → Delivery Errors; look for 550 5.x.x errors
- Generic ESPs: Look in your bounce/delivery failure log for SMTP error codes starting with
550 5.7
If you’re seeing these errors on Outlook/Hotmail/Live.com addresses, your sending is non-compliant with Microsoft’s requirements.
What to Fix First
If you’re experiencing 550 5.7.515 rejections, work through authentication in this order:
1. Verify SPF
Check your SPF record at yourdomain.com using any SPF lookup tool. Verify:
- The record exists
- It includes your ESP’s sending IPs or include mechanism
- The total lookup count is under 10
- The record ends with
~allor-all
Use the free SPF Builder to rebuild your record if it’s incorrect.
2. Verify DKIM
Confirm DKIM is enabled and correctly configured in your ESP. For Klaviyo users, check Settings → Email → Sending Domains and verify all DNS records show green. For other ESPs, check their domain authentication settings.
3. Publish DMARC
If you don’t have a DMARC record, add one immediately. The minimum:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
Use the free DMARC Record Generator to build your record.
4. Add One-Click Unsubscribe Headers
Verify your ESP is adding List-Unsubscribe and List-Unsubscribe-Post headers to campaign emails. Check the raw headers of a sent campaign email — most email clients have a “view source” or “show original” option that displays raw headers.
5. Check Your IP’s PTR Record
If you’re on dedicated IPs, verify PTR records are correctly set. If you’re on shared IPs, contact your ESP to confirm PTR records are in place.
Monitoring Outlook Deliverability
Microsoft offers SNDS (Smart Network Data Services) for monitoring your sending IP’s reputation with Microsoft’s systems. SNDS shows:
- Trap hit rate (spam trap activity from your IP)
- Complaint rate
- Filter status (OK, Caution, Red)
SNDS requires registration with a Microsoft account and domain verification. Access it at https://sendersupport.olc.protection.outlook.com/snds/.
For unified monitoring across Gmail, Outlook, Yahoo, and other providers — including seed list testing that shows inbox placement at Outlook specifically — InboxEagle monitors all major ISPs simultaneously. The Email Deliverability Checker gives you a quick authentication and placement check, and seed list testing shows your actual folder placement at Outlook mailboxes in under 5 minutes.
The Bigger Picture: Four Providers Enforcing
With Microsoft’s May 2025 enforcement, all four major bulk email enforcement providers are now active:
| Provider | Enforcement Began | Error for Non-Compliance |
|---|---|---|
| Gmail | February 2024 → SMTP rejection November 2025 | Permanent 5xx rejection |
| Yahoo Mail | February 2024 | Rejected or filtered |
| Microsoft Outlook | May 5, 2025 | 550 5.7.515 |
| La Poste | September 2025 | Rejected |
There is no longer a meaningful market segment of “major email providers that don’t enforce authentication.” Getting compliant isn’t optional — it’s table stakes for reaching any significant inbox.
The Bottom Line
Microsoft’s May 2025 enforcement closed the last major gap in the authentication enforcement landscape. If you’ve been treating authentication as optional because a specific provider hadn’t enforced yet, that option no longer exists.
- 550 5.7.515 means permanent rejection — these emails are gone; they don’t retry or defer
- SPF, DKIM, and DMARC must all be configured — not just present; they must pass and align with your From domain
- One-click unsubscribe headers are required — not just an unsubscribe link in the footer; the RFC 8058 header must be present
- Shared IP senders inherit pool risk — a non-compliant sender on your shared IP can affect Outlook delivery for others on that pool
- Check SNDS for IP-level signals — Microsoft’s Smart Network Data Services shows trap hit rate and filter status; useful for diagnosing Outlook-specific issues
Related reading: