Why Your Emails Go to Junk in Outlook and Hotmail (It's Not the Same as
Emails going to junk in Outlook even after Gmail is fixed? Here's why Microsoft filters differently — and the exact SNDS, JMRP, and 5.7.515 fixes.
If your emails are going to junk in Outlook and Hotmail while Gmail delivers them fine, you're not imagining it — Microsoft's filtering stack is a genuinely different system with different reputation data, different error codes, and different escalation paths. Fixing Gmail deliverability does not automatically fix Outlook. This guide covers what's actually different and the exact steps that move mail from Junk to Inbox on Microsoft's side.
You cleaned up your SPF, DKIM, and DMARC. Your Gmail placement recovered. Then a customer writes in: "Your invoice landed in my Junk folder." Their address ends in @hotmail.com. Welcome to the other half of the consumer mailbox market — the half that runs on SmartScreen, SNDS, and complaint feedback loops that behave nothing like Google's.
Why is Outlook filtering different from Gmail?
Gmail's spam filtering is heavily engagement-driven: opens, replies, "not spam" clicks, and inbox placement history on Google's own user base train its model. Microsoft runs a layered system instead:
- Connection and IP-level filtering — before content is even scanned, Microsoft's edge blocks or throttles based on IP reputation, much of it visible to you in the Smart Network Data Services (SNDS) portal.
- SmartScreen content filtering — a machine-learning content classifier that assigns every message a Spam Confidence Level (SCL). SmartScreen was originally trained on Hotmail-era data and still leans harder on content heuristics and URL reputation than Gmail does.
- Panel and feedback data — Microsoft supplements complaints with its own "sender reputation panel" (invited users who vote on mail) plus JMRP complaint reports. Gmail has no direct equivalent.
The practical consequence: you can have pristine engagement at Gmail and a red IP verdict at Microsoft at the same time. Different data, different verdict.
Try it: Run your sending domain through the free sender-compliance checker — it flags the authentication gaps Microsoft's May 2025 enforcement specifically rejects on.
What changed in May 2025: Microsoft's bulk sender enforcement
Since May 5, 2025, Microsoft requires SPF, DKIM, and DMARC (at minimum p=none) for anyone sending more than 5,000 messages per day to Outlook.com, Hotmail, and Live addresses. Non-compliant mail is rejected outright — not junked, rejected — with this error:
550 5.7.515 Access denied, sending domain example.com does not meet
the required authentication level.If you've seen 5.7.515 in a bounce, that's not a reputation problem at all. It's a hard authentication failure. The fix order:
- SPF — one TXT record, includes your actual sending services, ends in
-allor~all. Verify with the SPF checker. - DKIM — a valid signature from a domain that aligns with your From domain (relaxed alignment is fine). Check with the DKIM checker.
- DMARC —
v=DMARC1; p=none; rua=mailto:[email protected]at minimum. Note:p=nonepasses enforcement, but it does nothing for spoofing protection. The DMARC rollout from none to reject is worth doing once monitoring is stable.
Two Outlook-specific gotchas we see constantly:
- SPF passes but alignment fails. Your ESP signs DKIM with its own domain and SPF-authenticates via its own bounce domain. Gmail is sometimes forgiving here if one of them aligns; Microsoft's enforcement requires at least one aligned identifier, same as the RFC — but if your DNS is misconfigured so neither aligns, Gmail may still inbox you on engagement strength while Microsoft 5xx-rejects you.
- DKIM key too short. Some older setups still run 512-bit keys. Microsoft treats weak keys as failed signatures in practice. Move to 2048-bit.
If you're not sure which of your mail streams fails alignment, send a real campaign email through the deliverability tester — it runs 35 authentication checks including alignment for both SPF and DKIM and shows you exactly what Microsoft's edge sees.
SNDS: the reputation report Gmail doesn't give you
Google Postmaster Tools shows domain and IP reputation as vague buckets (High/Medium/Low/Bad). Microsoft's SNDS gives you something more granular and more honest: per-IP, per-day verdicts colored green, yellow, or red, plus complaint rates, trap hits, and message counts — straight from the Hotmail/Outlook.com edge servers.
How to read SNDS data
Enroll at sendersupport.olc.protection.outlook.com/snds and verify ownership of your sending IPs. A typical daily row looks like:
| Date | IP | Messages | Complaints | Complaint rate | Trap hits | Verdict |
|---|---|---|---|---|---|---|
| 2026-01-14 | 203.0.113.10 | 48,220 | 61 | 0.13% | 3 | YELLOW |
| 2026-01-14 | 203.0.113.11 | 51,904 | 12 | 0.02% | 0 | GREEN |
What to watch:
- Complaint rate above ~0.1% turns an IP yellow; sustained high rates turn it red. This maps directly to junking for that IP's mail. (For context, the Gmail and Yahoo bulk sender rules draw the ceiling at 0.3% — but Microsoft starts hurting you well before that.)
- Trap hits above zero mean your list contains spam traps — almost always a sign of purchased lists, old unengaged segments, or missing double opt-in. Zero is the only acceptable number.
- Red verdict with low complaints usually means traps or content fingerprints, not complaints. Don't assume "nobody complained so we're fine."
If you manage multiple IPs, checking SNDS manually every day gets old fast. WillItInbox's monitoring pulls SNDS data automatically alongside Google Postmaster and Yahoo Sender Hub, so drift shows up in one dashboard instead of three portals — and you get alerted when an IP flips yellow before it flips red. See the full SNDS guide for enrollment edge cases (shared IPs, ranges you don't fully control, and the SNDS API).
JMRP: complaints you can actually see
Gmail never tells you which users hit "Report spam." Microsoft's Junk Mail Reporting Program (JMRP) does — it forwards you a copy of every complaint from enrolled Outlook.com/Hotmail recipients.
Enroll at the same sender support portal, point it at an abuse@ or postmaster@ address you actually read, and then:
- Suppress every complainer immediately and permanently. Not after the next campaign. Immediately.
- Tag the source. JMRP complaints include headers — match them to the campaign and signup source. If one acquisition channel generates 5x the complaints of others, that's a list-quality problem you can fix at the root.
- Watch for complaint spikes within 24h of a send. That's SmartScreen-relevant feedback: complaint bursts train the filter against your content fingerprint, not just your IP.
A complaint rate under 0.1% is the working target. If you can't get there, no amount of mitigation requests will save you — which brings us to the part most blogs get wrong.
The mitigation request form: legit tool vs. bandaid
When an IP is red in SNDS and your mail is being junked or blocked (550 5.7.1 style rejections), Microsoft's sender support form (linked from the SNDS portal) lets you request a review. A human (or at least a different automated tier) looks at your case.
A mitigation request is legitimate when:
- You inherited an IP with a poisoned history (new ESP allocation, reused cloud IPs).
- You fixed the underlying problem — auth, list hygiene, a runaway complaint source — and need the verdict reset to reflect current behavior.
- You're being rate-limited during a legitimate IP warming schedule and need temporary throttle relief.
It's a bandaid when:
- Your complaint rate is still above 0.1% and you're just asking for forgiveness.
- You haven't enrolled in SNDS/JMRP and can't describe your own traffic in the form. Support will ask for sending volumes, list sources, and opt-in flows. "We send newsletters" is not an answer.
- The same IP got mitigated 60 days ago and is red again. Microsoft notices repeat offenders, and each subsequent request is less effective.
Write the request like an incident report: what broke, what you changed (specifically — "removed 14-month unengaged segment, 38k addresses"), what your SNDS data shows now. Vague requests get vague denials.
Hotmail legacy quirks, SCL/PCL headers, and SafeSenders
A few Outlook-specific behaviors that trip up senders who only know Gmail:
SCL and PCL. Every inbound message gets stamped with a Spam Confidence Level (SCL, 0–9) and often a Phishing Confidence Level (PCL). You can see them in the X-Microsoft-Antispam header of a received message. SCL 0–1 is inbox territory; 5–6 typically junks; 8–9 is quarantine/block. If your mail consistently lands at SCL 5, SmartScreen's content model dislikes something — URL reputation, image-heavy layout, or a content fingerprint matching previously complained-about mail. Paste a received message into the free header analyzer to see the SCL/PCL stamps and every authentication result in one view.
Hotmail-era infrastructure. Old @hotmail.com mailboxes still behave slightly differently at the edges — older Safe Sender lists, long-abandoned accounts converted to traps, and stricter treatment of "graymail" (bulk mail the user once opted into but never opens). Microsoft is more aggressive than Gmail about junking graymail by default. Low engagement hurts you at Microsoft even when it isn't generating complaints.
Safe Senders cuts both ways. If recipients add you to Safe Senders (or you land there via their contacts), you bypass SmartScreen content filtering for that mailbox. That's why "add us to your contacts" is still a legitimate post-purchase nudge for Outlook-heavy audiences — it's one of the few places a user-level whitelist genuinely overrides the filter. Don't build your strategy on it, but don't skip it either.
Consumer vs. enterprise filtering. Office 365 / Microsoft 365 business tenants run Exchange Online Protection with admin-configurable anti-spam policies. A B2B recipient's junking may be their tenant's policy (aggressive SCL thresholds, transport rules), not Microsoft's verdict on you. If only one company's domain junks you, suspect their admin settings, not your reputation.
The overlap fixes that help everywhere
Microsoft-specific tooling aside, the fundamentals that keep you out of junk at Outlook are the same ones that keep you out of spam everywhere else:
- Full authentication with alignment — SPF + DKIM + DMARC, verified per sending stream. This is now a hard reject criterion, not a reputation hint.
- Complaint rate under 0.1% — measured via JMRP at Microsoft and Postmaster at Google. One number, two instruments.
- List hygiene — spam traps in SNDS and hard bounces above ~2% are the fastest ways to go red. Validate lists before big sends; the email validator catches dead mailboxes, disposables, and known traps across 12 checks.
- Blocklist hygiene — Microsoft consults its own internal lists plus external signals. A listing on a major DNSBL will drag down otherwise-healthy IPs; run the blacklist check across 20+ DNSBLs and follow a proper delisting process if anything shows up.
- Consistent volume — sudden 10x spikes look like compromise to both SmartScreen and Gmail. Warm new IPs gradually.
And before any big campaign to an Outlook-heavy list: send a real email through the deliverability tester. You get 70+ checks — auth, DNS, headers, content, links — in about 15 seconds, with the failures ranked by impact. It won't promise inbox placement (nobody honestly can), but it will tell you whether Microsoft's edge has a technical reason to junk you before your list finds out the hard way.
Frequently asked questions
Sources reviewed
- Email sender guidelines(official)
- Sender requirements and recommendations(official)
Factual review: June 13, 2026 by WillItInbox Editorial.
Keep reading