Emails Going to Spam Only at Outlook? A Diagnostic Guide

This is the pattern, and if you’re here you already recognize it:

Gmail open rate 34%. Yahoo fine. Apple fine. Outlook.com, hotmail.com, live.com and every Microsoft 365 corporate domain: 2% opens, zero bounces, zero error messages. Everything is being accepted and then filed in Junk.

The maddening part is the absence of evidence. No bounce to read, no rejection code to search, no blocklist entry to check. Microsoft accepted your mail — a 250 OK — then made a separate placement decision your logs will never see. Delivery looks perfect; engagement at one provider has collapsed.

This guide is about that divergence: why one provider junks you while another doesn’t, and how to work out which of two very different problems you have.

Why Gmail and Microsoft Disagree About Your Mail

Providers don’t run the same filter, and more importantly they don’t weight the same signals. That is the entire mechanism behind this symptom.

Gmail leans heavily on per-recipient engagement. Opens, replies, deletes-without-reading, and each recipient’s own history with your From address carry enormous weight. A sender with a mediocre IP but genuinely engaged subscribers can inbox at Gmail almost indefinitely. Engagement rescues you — though it won’t override Gmail’s own throttling signals during a volume spike.

Microsoft leans harder on IP and domain reputation and complaint history. Its filtering evaluates the connecting IP’s behavior across all Microsoft mail, the sending domain’s history, authentication posture, and the rate at which recipients hit “Junk.” Microsoft uses engagement signals too, but the sender-facing signals Microsoft actually exposes are not recipient-scoped: the SNDS complaint rate is reported per IP per day, and BCL is derived from complaint volume against the sender rather than from any individual recipient’s history. From that, and from consistent practitioner experience, the working conclusion is: at Microsoft, good engagement will not reliably dig you out of a reputation hole. At Gmail, it often will.

So a list with a stale, low-engagement tail and a rising complaint rate produces exactly the split you’re seeing. Gmail’s engaged majority keeps you inboxing. Microsoft’s aggregate view of the same traffic says “this IP generates complaints” and junks the lot — including mail to people who would have opened it.

There Are Two Microsofts, and They Have Separate Verdicts

Before diagnosing anything, understand that “Outlook” is two unrelated filtering systems sharing a brand:

• Outlook.com (consumer) — outlook.com, hotmail.com, live.com, msn.com, filtered by Microsoft’s consumer stack. This is what SNDS and JMRP report on.
• Microsoft 365 / Exchange Online Protection (corporate tenants) — company mailboxes hosted on Microsoft 365, filtered by EOP and then further shaped by that tenant’s own anti-spam policy, configured by their IT admin.

These render independent verdicts. You can inbox perfectly at outlook.com and be junked at half your corporate recipients, or the reverse. SNDS tells you nothing about tenant-side decisions, and the tenant admin sees nothing of your consumer reputation. Diagnosing them as one problem is the most common wasted week in this scenario.

The Diagnostic Sequence

Work these in order. Each step either rules something in or rules it out, and the later steps are meaningless without the earlier ones.

Step 1 — Confirm the pattern in your own data

Tool: your ESP’s reporting, segmented by recipient domain.
Check: delivery rate and unique open rate for the last 3–5 campaigns, broken out for outlook.com/hotmail.com/live.com/msn.com, for Microsoft-hosted corporate domains, and for gmail.com as a control.
Rules in/out: ~100% delivery with a fraction of Gmail’s opens confirms a placement problem. If delivery itself is down, you have blocking or throttling instead — look for S3140 or S3150 in your bounce text and treat it as a different problem.

Step 2 — Separate consumer from corporate

Tool: the same segmentation, plus an MX lookup on your top corporate domains.
Check: do Microsoft-hosted corporate domains (MX ending in mail.protection.outlook.com) behave like outlook.com? Is the corporate damage spread across many tenants or concentrated in one or two?
Rules in/out: broad damage across both systems means a sender-side reputation problem. Damage confined to specific companies means tenant policy.

Step 3 — Check the sending IP in SNDS

Tool: Smart Network Data Services, now at substrate.office.com/ip-domain-management-snds/SNDS (short link: aka.ms/snds). Microsoft cut over to that portal on 8 June 2026 and deprecated the older sendersupport.olc.protection.outlook.com/snds/ automated-access URLs on 22 June 2026; legacy browser URLs still 308-redirect.
Check: the Data Report’s Filter Result color per IP per day, plus the Complaint Rate column. Green means a spam verdict on a small share of that IP’s mail; yellow means substantial filtering; red means most or all of that day’s mail went to Junk.
Rules in/out: yellow or red confirms an Outlook.com reputation problem and gives you a date to correlate against a campaign. Solid green rules it out, leaving domain, content, or tenant causes. Microsoft is removing trap-hit counts from the Data Report starting 22 July 2026, so from that date onward, no trap data will no longer mean no traps.

Step 4 — Check authentication as Microsoft evaluates it

Tool: send to a mailbox you control at each system, then read the raw headers in Microsoft’s Message Header Analyzer.
Check: the Authentication-Results header. You want spf=pass, dkim=pass with header.d= matching your From domain, dmarc=pass, and compauth=pass. Composite authentication is the one people miss: compauth=fail with reason 001 means you published nothing enforceable — no DMARC, or SPF ending in ~all/?all. Note that p=none itself counts as a weak policy for compauth purposes — 001 persists until you move to quarantine or reject, so treat p=none as a staging post, not a destination.
Rules in/out: anything other than aligned passes is a fixable cause, and should be fixed before anything else. Clean passes rule authentication out.

Step 5 — Read your complaint rate in JMRP

Tool: the Junk Mail Reporting Program at substrate.office.com/ip-domain-management-snds/SNDS/Jmrp. Enrollment requires proving control of the IP range — via reverse DNS, WHOIS, or routing-table records — not a dedicated IP. If you send from your ESP’s shared pool, the pool operator holds that proof, so ask them for the complaint data. Microsoft says feedback can begin in as little as 72 hours after enrollment, so treat that as a floor rather than a typical wait.
Check: which campaigns, segments and From addresses generate complaints. Deliverability practitioners reported in mid-2026 that Microsoft narrowed these reports — message headers plus selected authentication headers, with the complainant’s recipient address redacted and the body no longer appended; Microsoft has not documented the change, so verify against what your own feed actually delivers. Either way, correlate by campaign identifiers in your own headers, since a blinded report strips the recipient address your suppression workflow needs.
Rules in/out: a complaint cluster tied to one segment or acquisition source names your culprit. If you send on your ESP’s shared pool, they hold the enrollment — ask them for the complaint data.

Step 6 — Check content and link reputation

Tool: your template, plus a DNSBL check on your link domains and their hosting IPs.
Check: URL shorteners, redirect chains, link domains shared with other senders, tracking domains that don’t match your brand domain, image-heavy templates with almost no text.
Rules in/out: if the IP is green and authentication is clean, this is where the remaining signal lives.

Step 7 — Determine tenant-level vs. provider-level

Tool: the table below, plus one cooperative recipient at an affected company.
Check: whether the junking is confined to a single organization’s users.
Rules in/out: this determines whether any sender-side work can help you at all.

Tenant-Level vs. Provider-Level: How to Tell

BCL: The Number That Decides Corporate Junk Placement

Microsoft 365 stamps inbound bulk messages with a Bulk Complaint Level (BCL) in the X-Microsoft-Antispam header. Per Microsoft’s documentation: 0 is not a bulk sender, 1–3 a bulk sender generating few complaints, 4–7 a mixed number, 8–9 a high number.

Each tenant’s anti-spam policy sets a threshold. Microsoft’s defaults: 7 in the default and newly created policies, 6 in the Standard preset security policy, 5 in the Strict preset. Messages that meet or exceed the threshold go to Junk under the default and Standard configurations, and are quarantined outright under Strict.

This is why the same message inboxes at one company and is junked at another. A BCL of 6 clears a threshold of 7 and fails a threshold of 6. Nothing about your sending changed — their slider sits in a different position. Microsoft’s sender rules document the BCL thresholds and tenant controls in full.

How to ask a recipient admin to check. Send this to your contact and ask them to forward it to IT:

Could you run a message trace in the Microsoft Defender portal for a recent message from [your sending domain], open the headers, and tell me: (1) the BCL value in X-Microsoft-Antispam, (2) the SCL and SFV values in X-Forefront-Antispam-Report, and (3) whether CAT shows BULK. Also, what BCL threshold is set in the anti-spam policy applied to our users, and are you on the Standard or Strict preset? If our mail is being caught as bulk rather than spam, adding our sending domain to the allowed senders list would resolve it.

If the answer is CAT:BULK with a BCL under 8, you are not a spammer in Microsoft’s eyes — you are gray mail meeting a strict local threshold. No amount of list cleaning changes that verdict. The fix is an allow-list entry or a policy change, and only their admin can make it.

The Most Common Causes, Ranked

1. A stale, non-engaging tail weighted toward Microsoft. Old hotmail.com and live.com addresses are often abandoned but still accepting mail — no engagement, some complaints, no rescue.
2. A complaint spike you never saw, because you weren’t enrolled in JMRP.
3. A sudden volume change to Microsoft, which reads as compromised-account behavior however legitimate the addresses are.
4. SPF passes, but alignment fails. DKIM d= pointing at your ESP’s domain with no DMARC record is tolerated at Gmail and scored as unauthenticated by Microsoft’s compauth.

How to Fix It: In This Order

Step 1: Fix authentication first

SPF passing on the envelope domain, DKIM signing with d= on your own domain, and a published DMARC record — start at p=none if you must, but publish one. It’s fast, fully under your control, and every later step is evaluated more favorably once it’s in place.

Step 2: Cut the Microsoft-domain tail, aggressively

Build a suppression segment specific to Microsoft domains: any outlook.com, hotmail.com, live.com, msn.com or Microsoft-hosted corporate address with no open or click in 90 days comes out of your sends. Apply a stricter sunset window here than you use for Gmail. The asymmetry is deliberate — the rescue mechanism that exists at Gmail doesn’t exist at Microsoft.

Step 3: Enroll in SNDS and JMRP before you resume

Now, not after. You need the instrumentation running before your next send so you can see whether the fix worked. Both are free.

Step 4: Ramp volume back to Microsoft separately

Treat Microsoft domains as their own warm-up target. Start with 30-day openers only, at a fraction of your normal Microsoft volume, and increase gradually over two to three weeks while watching SNDS color daily. Rushing this is how a Junk-folder problem becomes an S3150 throttle.

Step 5: Use the support path only when it applies

For Outlook.com consumer issues, the sender support form is at olcsupport.office.com. Microsoft 365 recipients showing 5.7.606-649 access-denied rejections have a separate delist portal at sender.office.com. And if you hit 5.7.511, that portal won’t work — forward the full NDR to [email protected]. Neither fixes Junk-folder placement — they address blocking. Submitting a delisting request while your complaint rate is still elevated wastes the request and your credibility for the next one. Fix behavior first, escalate second.

Why Microsoft Recovers Slower Than Gmail

Gmail’s engagement-weighted model means a corrected send to an engaged segment shows improvement within days — you re-prove yourself recipient by recipient. Microsoft’s model is aggregate and historical: it evaluates the IP and domain over a trailing window, so a few good days barely move an average built from weeks of bad ones. Practitioners typically estimate two to six weeks of consistent, ramped sending before recovery is visible — Microsoft publishes no recovery timeline, so treat that range as field experience rather than a guarantee. Expect it to appear as a gradual lift rather than a switch flipping.

Microsoft also tells you almost nothing along the way — no placement dashboard, no per-domain reputation score, no notification when your status changes. SNDS color and your own segmented open rates are the entire feedback loop.

Shared IP vs. Dedicated IP: Who Fixes What

On a shared IP pool, Outlook.com reputation is your ESP’s to manage, and because enrollment turns on proving control of the IP range, it is the pool operator — not you — who can enroll it in JMRP. Your leverage is list quality — and a neighbor’s bad list can junk you through no fault of your own. Ask your ESP for the SNDS status of the pool you send from; a competent provider will tell you.

On a dedicated IP, all of the above is yours. Enroll in both programs, and note that Microsoft’s volume sensitivity cuts both ways: an IP sending inconsistent volumes to Microsoft never builds a stable reputation in the first place.

How Mailercloud Handles Microsoft Deliverability

At Mailercloud we deliver over a billion emails a month, so Microsoft placement is a daily operational concern rather than an occasional incident. Our deliverability team monitors SNDS status across our sending pools, processes Microsoft complaint feedback, enforces engagement-based suppression on Microsoft domains specifically, and manages volume ramping to Microsoft infrastructure as a distinct workflow from other providers.

If your Outlook and Microsoft 365 open rates have collapsed while Gmail looks fine, talk to our deliverability team — or start free with Mailercloud.

FAQ: Emails Going to Spam at Outlook Only

Why do my emails inbox at Gmail but go to Junk at Outlook?

The two providers weight different signals. Gmail leans on per-recipient engagement, which lets an engaged audience carry a mediocre sender. Microsoft leans harder on IP and domain reputation and complaint history — its own sender-facing metrics are IP-scoped (the SNDS complaint rate) and sender-scoped (BCL), not recipient-scoped. Practitioners consistently find that engagement does not override those signals the way it does at Gmail. The same list produces opposite outcomes.

Is there an Outlook equivalent of Google Postmaster Tools?

Partially. SNDS shows filter status and complaint rate per IP, for Outlook.com consumer mail only, and requires proof that you control the IP range. No Microsoft tool reports your placement inside corporate Microsoft 365 tenants — that visibility exists only for the tenant’s own admin.

What does BCL mean and can I lower mine?

Bulk Complaint Level, 0–9, assigned by Microsoft 365 to inbound bulk mail based on complaint behavior. You lower it the way you lower complaints: cleaner acquisition, tighter sunsetting, honest subject lines, easy unsubscribes. Whether a given BCL lands in Junk depends on the recipient tenant’s threshold — default 7, Standard preset 6, Strict preset 5.

Only one client’s employees see my emails in Junk. What do I do?

That’s tenant-level, and no sender-side work will fix it. Ask your contact to have IT check the BCL and SFV values in the headers and add your sending domain to the allowed senders list in their anti-spam policy.

How long does Outlook inbox placement take to recover?

Practitioners generally estimate two to six weeks of consistent, engagement-filtered, gradually ramped sending; Microsoft publishes no figure. It is slower than Gmail because Microsoft’s observable sender signals — the SNDS complaint rate, which is scoped to the IP, and BCL, which is derived from complaint volume against the sender — are aggregate and trailing rather than per-recipient.

Why are my emails going to spam?

Usually one of four things: weak authentication (SPF, DKIM, or DMARC not passing and aligned), poor list quality driving complaints, low recipient engagement, or IP/domain reputation damage. The tricky part is that the same list can inbox at one provider and spam at another, because Gmail weights engagement while Microsoft weights IP and domain reputation — so “going to spam” rarely has a single universal cause. Diagnose per-provider, not globally.

How do I stop my emails from going to spam?

Fix the signal the provider actually weights. Get SPF, DKIM, and DMARC passing and aligned; suppress unengaged and complaint-prone recipients; keep your complaint rate under 0.1%; and warm volume gradually rather than spiking. At Microsoft specifically, watch SNDS and BCL rather than engagement, because engagement won’t rescue you there the way it does at Gmail.