Why Does Microsoft Trash My Emails? A Marketing Cloud Guide to Fixing Outlook/Hotmail Blocks (and Understanding SNDS & JMRP)

Last Updated on August 4, 2026

Part of my ongoing series on Email Deliverability. If you’re new here, start with ensuring email deliverability and IP warming in Marketing Cloud, then come back for the Microsoft deep-dive.

Marketing Cloud Outlook deliverability has a habit of going wrong suddenly and without warning. If you landed here because Outlook, Hotmail, MSN, or Live addresses are suddenly bouncing back blocked, skip straight to Blocked right now? Start here. If you want to actually understand Marketing Cloud Outlook deliverability — how Microsoft decides whether to accept your mail, and how to set yourself up so this stops being a fire drill — read on from the top.

Ask any Marketing Cloud practitioner where their deliverability headaches come from, and Microsoft will be near the top of the list. Gmail is stricter on paper, but Gmail is also predictable. Microsoft — the consumer side, Outlook.com and Hotmail, what the deliverability world calls Microsoft OLC — has always had the quickest blocking trigger finger of the major consumer mailbox providers. Al Iverson at Spam Resource, who has been writing about this for over two decades and is about as close to a source of truth as this field has, puts it plainly: he’s not convinced Microsoft actually hates anyone, but it’s clear a lot of senders feel that way.

And through 2026, more of them feel that way than usual. There’s been a well-documented wave of Microsoft OLC blocking: sudden S3150 block-list bounces and 451 4.7.x rate-limiting hitting senders with otherwise clean reputations, often with no change on the sending side. So if you’re seeing a spike in Microsoft block bounces and your ESP is waving vaguely at “reputation or spam filtering,” the first thing to know is: you’re not imagining it, and you’re not alone.

The second thing to know is that “reputation” is often the wrong diagnosis. Let’s fix the immediate problem first, then build the understanding that keeps it fixed.

Blocked right now? Start here

Work these in order. The whole point of the ordering is cheapest-to-check first. Don’t start a reputation investigation before you’ve ruled out the two-minute causes. Most Marketing Cloud Outlook deliverability incidents resolve at Step 1 or Step 2.

Step 1: Read the actual bounce string. Don’t trust the ESP summary.

Your ESP’s “reputation / spam filtering” label is a catch-all bucket. The real diagnosis is in the SMTP response Microsoft returned. Pull a genuine bounce and look at the code:

550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level → This is an authentication problem, not reputation. Go to Step 2.
550 5.7.1 ... (S3150) or similar block-list language → This is a reputation / block-list issue. Go to Step 3.
451 4.7.x deferrals that never clear → Rate-limiting tied to IP reputation or a volume spike. Go to Step 3, then Step 5.
Anything referencing Spamhaus → Deal with Spamhaus first. Nothing on the Microsoft side moves until that listing is cleared. Check at check.spamhaus.org.

This one step redirects most people. A sudden mass block that “came from nowhere” is far more often the authentication rule below than a reputation collapse — reputation degrades gradually, the auth rule blocks overnight.

Step 2: Rule out the high-volume authentication mandate (the most likely cause of a sudden block)

Since 5 May 2025, Microsoft rejects mail outright from any domain sending 5,000+ messages a day to Outlook.com consumer addresses (outlook.com, hotmail.com, live.com, msn.com) unless it passes all three: SPF, DKIM, and DMARC — with alignment, and at least a published p=none policy. The rejection is the 550 5.7.515 above.

The reason this hits people as a surprise mass block: it triggers on the From-domain’s volume, and enforcement flipped from junk-foldering to hard rejection. You can cross the threshold from a single high-volume From domain, or a new send pattern, and get blocked with no reputation change at all. Check, in order:

DMARC exists and passes. The 5322.From domain has a valid DMARC record (p=none is enough to satisfy the rule) and DMARC actually passes.
Alignment. DMARC needs SPF or DKIM to align with the visible From domain. The classic SFMC-adjacent failure is the return-path (5321.MailFrom) not aligning with the From (5322.From) domain. If you’re on a Private Domain / SAP setup, this is where to look.
DKIM is signing with the right domain. The signing domain must align with the From domain.

Use a tool like LearnDMARC or a header inspection on a test send to Outlook to see SPF/DKIM/DMARC results in one view. If you’re seeing 5.7.515, this is your fix — and it’s fully in your control.

(Scope note so you don’t chase the wrong thing: the May 2025 rule governs Outlook.com consumer inbound only. Microsoft 365 tenant-to-tenant mail is a separate regime — a p=reject sender to an M365 tenant gets 550 5.7.509, governed by that tenant’s anti-phishing policy, not this mandate.)

Step 3: Get eyes on Microsoft’s view of your IPs (SNDS)

If it’s a reputation/block-list bounce rather than 5.7.515, you need to see what Microsoft sees. That’s SNDS — per-IP filter status (green/yellow/red), complaint rate, and spam trap hits. Two things to look at immediately:

Filter status and complaint rate for the affected IP(s). Yellow or Red tells you this is reputation, and roughly how deep.
The RCPT vs DATA gap. If Microsoft is rejecting before the DATA command, that points at PTR/reverse-DNS or authentication, not content — and it’s invisible in your normal SFMC delivery metrics.

SNDS access in Marketing Cloud has a specific route (the abuse@salesforce.com flow), covered in full in The Marketing Cloud specifics below. If you don’t have SNDS set up yet, request it today — it’s the single most useful thing you can do for Microsoft visibility, and you’ll want it for the next incident even if this one resolves first.

Step 4: Request unblocking the right way

Once you understand the cause, submit a delisting/mitigation request via Microsoft Sender Support (sender.office.com / the Outlook Sender Support form). The cardinal rule: fix the underlying issue before you ask. Microsoft tracks senders who repeatedly request mitigation without changing anything, and eventually they stop granting it — you’ll get “these IPs have previously received mitigations… and have failed to maintain patterns within our guidelines.” If you’re mid-warmup, say so and ask for “pre-emptive accommodation” with your projected daily volumes; they’ll usually raise your inbound limits to let the warmup proceed. You will most probably need to escalate this request multiple times, while Microsoft claims there are no issues on their end.

Step 5: If auth is clean and SNDS is green and it still blocks

It happens. Then it’s almost always one of: a volume spike (spread large sends across days, hold a steady average), namespace-mining suspicion from too many invalid-address attempts (suppress user-unknowns, audit data sources), or the SRD panel — Microsoft literally samples recipients to vote on whether your mail is spam, and no technical fix overrides “people don’t want this.” At that point it’s list quality and content, full stop. The rest of this article explains each of these and how to stay ahead of them.

That’s the fire drill. The rest is the understanding that makes the fire drill rare.

Two acronyms, two jobs

Keep these straight, because people constantly conflate them:

SNDS (Smart Network Data Services) is Microsoft’s reputation data portal. It tells you how your sending IPs are performing against Outlook.com/Hotmail recipients: volume, filter status, complaint rate, and — the part almost nobody uses — spam trap hits. It’s read-only insight.
JMRP (Junk Mail Reporting Program) is Microsoft’s feedback loop (FBL). When an Outlook user hits “Report Junk,” JMRP forwards you a copy of that complaint so you can suppress the complainer.

SNDS shows you the aggregate picture. JMRP feeds you the individual complaints. You want both — but in Marketing Cloud, only one of them is yours to configure. More on that below.

The 2026 authentication baseline and why more mail is bouncing

Before the tools, the rule that reframed Marketing Cloud Outlook deliverability for everyone. The high-volume mandate from Step 2 isn’t a temporary blip — it’s the new floor, and it’s worth understanding beyond the emergency-fix version.

Microsoft aligned itself with the Google/Yahoo bulk-sender requirements that landed in 2024, then went further by turning failures into hard rejections rather than junk-foldering. For any From domain over 5,000/day to Outlook consumer mailboxes, SPF + DKIM + DMARC with alignment is table stakes. Below that threshold the same signals still drive filtering — so treat it as the baseline at any volume, not a line you only worry about once you cross it.

Practical implications for SFMC senders:

Alignment is the trap, not authentication itself. Plenty of setups pass SPF and DKIM but fail alignment for DMARC purposes because the return-path domain doesn’t match the From domain. On a properly configured Private Domain with a SAP subdomain this is handled, but mixed or legacy sending configurations are where 5.7.515 shows up.
p=none satisfies the rule — you don’t need p=reject to clear Microsoft’s bar. (You may want to move toward enforcement for brand-protection reasons, but that’s a separate decision.)
One weak From domain can block a stream. Because the threshold is per From domain, a single high-volume sending domain with a broken record can start bouncing while everything else looks fine.

If your Microsoft bounces are 5.7.515, this section is the root cause. If they’re not, read on — reputation is the other half of the story.

SNDS is IP-level, and that changes everything

The single most important thing to understand about Marketing Cloud Outlook deliverability monitoring is that SNDS reports on IP addresses, not domains. This is the opposite of Google Postmaster Tools, which reports on domain reputation.

Why it matters: the same campaign can show a healthy domain reputation in Google Postmaster Tools and a Yellow IP in SNDS at the same time — and both are correct. Gmail users and Outlook users are different populations with different spam-reporting habits. Don’t assume that because Gmail looks fine, Microsoft does too. Check both.

Because SNDS is IP-based, you register every sending IP individually, and access is only granted for dedicated IPs. If you’re on a shared IP pool, Microsoft won’t give you SNDS access — the data would expose other senders sharing that space. (Shared-IP contamination is also a real cause of blocks you didn’t earn: if someone else on the pool misbehaves, you inherit the reputation hit. It’s one more argument for a dedicated IP if your volume justifies it.)

What SNDS actually shows you

Once you’re in, each registered IP gets a daily row of data. The fields worth watching:

RCPT and DATA — the count of recipients your IP tried to send to (RCPT TO commands) versus the messages Microsoft actually accepted after the DATA command. A meaningful gap between the two means Microsoft is rejecting mail before it’s accepted — often a PTR/reverse-DNS or authentication problem. This rejection is invisible in your SFMC delivery metrics, which record the send as “accepted,” so SNDS is sometimes the only place you’ll see it.
Complaint rate — spam complaints divided by messages delivered. Keep it under 0.3%. Above that and you’re drifting toward trouble; sustained rates above ~0.5% push you toward Red. Note the timing quirk: SNDS shows complaints on the day they were reported, not the day the email was sent.
Trap hits — whether your IP sent to one of Microsoft’s spam trap addresses. This is the field to obsess over, and I’ll come back to why.
Filter status — the color code: Green, Yellow, Red.

One volume caveat: an IP has to send at least 100 messages in a day before SNDS will show data for that day, and history goes back roughly 90 days. Gaps in the data on low-volume days are normal.

The color code, and the mistake everyone makes

Green means Microsoft generally trusts your mail. Red means the filters have essentially given up on you — the overwhelming majority of your mail is being treated as spam. Yellow is the interesting one, because it’s where people make the wrong call.

Yellow is not “fine, but keep an eye on it.” Yellow means Microsoft is actively increasing filtering on that IP right now. More of your mail is going to Junk, and if the trend holds, Yellow becomes Red. Treat Yellow as an urgent signal, not a comfortable middle ground.

A few practical patterns worth internalizing:

Green to Yellow usually follows a sustained stretch — a week or so — of complaint rates in the 0.3–0.5% band. A single bad day rarely flips it; a bad week does.
Yellow to Red comes from sustained complaints above 0.5%, or any trap hits at all. Even a tiny number of trap hits can drag you from Yellow to Red, which is exactly why trap data deserves more attention than it gets.
Red back to Yellow is slow and unforgiving. Expect roughly 30 days of genuinely clean sending — low complaints, zero traps — before Microsoft’s system starts to relent, and the recovery isn’t linear. You may sit in Red for three weeks of disciplined sending before anything moves. Patience is the only strategy that works here.

Because SNDS is per-IP, you can also have a Red promotional IP and a Green transactional IP on the same infrastructure at the same time. That’s reputation isolation working as intended — and a good argument for separating streams.

The trap-hit field is the one nobody uses

Here’s the piece I want you to take away even if you skim everything else.

Spam traps are addresses that exist only to catch senders with poor list hygiene. They accept mail, so they never bounce. That means you cannot detect them from your bounce reports — not in SFMC, not anywhere in your normal tooling. Google Postmaster Tools doesn’t show trap data either. SNDS does. It is, functionally, the only early-warning system for trap hits available in standard sender tooling.

So when SNDS shows a trap hit, the diagnostic move is direct: look at which campaigns ran that day and which segments they used. The overlap between “days with trap hits” and “specific sends” points straight at the list segment or acquisition source that carried the trap address. That’s actionable in a way that a vague “complaints are up” reading never is. Catch it the day after, pause the offending segment, investigate the source — and you very likely avoid the Yellow-to-Red slide and the 30-day recovery that comes with it.

What changed in 2026

Beyond the authentication mandate, Microsoft has been reworking both monitoring tools, so if your knowledge of SNDS is a couple of years old, update it.

SNDS relaunched in June 2026. The portal moved and came back with updated access controls and some changes to what data is shared and how. As Al Iverson noted at the time, the rollout was bumpy — people reported trouble getting access to IP ranges because confirmation emails weren’t arriving, and registration dates and feedback-loop feeds were buggy for some. His advice, which I’d echo: if you hit a wall, you’re not alone, and it’s often worth waiting a few days and trying again while Microsoft works through the issues. (The earlier January 2026 round of changes, also documented on Spam Resource, was mostly interface and presentation — evolutionary, not a rebuild of what SNDS measures.)

JMRP moved platforms. The feedback loop was rebuilt on new infrastructure, and the old enrollment didn’t automatically carry over. For self-managed senders this matters enormously: if you were enrolled before the migration and never re-enrolled, you may have been silently missing complaint data for months — accumulating invisible reputation damage that showed up in your SNDS color but without the per-message detail that tells you which segments were the problem. (Marketing Cloud senders are in a different boat here — see the next section.)

One migration gotcha for the technically inclined: if you were parsing the return-path address in JMRP complaint reports to identify the campaign and recipient, that approach broke in the transition. The commonly suggested alternative is to encode that information in the Message-ID header instead — and, as Al rightly warns, don’t make it human-readable, or someday someone will do something clever and unwelcome with it.

The Marketing Cloud specifics: read this part twice!

Everything above is general Microsoft deliverability. Here’s where Marketing Cloud Outlook deliverability diverges from a self-hosted MTA, and where I see people burn time.

Do not configure JMRP yourself. This is the big one. Per Salesforce’s own documentation, all SFMC sending addresses are already enrolled in JMRP, and Microsoft complaints are ingested directly into the platform and handled for you. Trying to set up your own JMRP feed on top of that is redundant at best. Your job on the complaint side is to make sure your unsubscribe and suppression logic is sound — Salesforce is already catching the Microsoft feedback loop.

SNDS, on the other hand, you request yourself — and there’s a specific process. In Marketing Cloud you don’t just point SNDS at an inbox you control. You:

Go to the Outlook.com SNDS site and request access for your dedicated IP (or range).
When it asks which authorization address to send the request to, you must choose abuse@salesforce.com. Any other address gets the request rejected, because Salesforce owns the IPs and has to approve.
Then open a support case in Salesforce Help with the subject “Microsoft SNDS access,” the description covering your Microsoft account email, the address you sent the request to (abuse@salesforce.com), and the IP range(s) requested. Confirm the case is routed under Marketing – Engagement – Email Deliverability.

The support case is effectively the liaison: Microsoft sends the verification to Salesforce’s admin address, and the deliverability operations team reviews and approves it. SNDS is granted for dedicated IPs only, and if you have multiple IPs that aren’t in one continuous range, submit separate requests.

The EMEA/RIPE trap. This one’s relevant to a lot of us in the Nordics and the rest of Europe. If you’re on the EMEA stacks (50/51), your IPs are managed under the RIPE registry rather than ARIN. SNDS confirms IP ownership via a WHOIS lookup, and Microsoft’s lookups against RIPE get rate-limited regularly. You’ll see something like “Sorry, whois.ripe.net will not let us do any more lookups today. Please come back and try again tomorrow” — which stops SNDS from resolving Salesforce’s admin contact and quietly derails the whole abuse@salesforce.com flow. The documented workaround: have the access request sent to one of the other addresses SNDS displays, and approve it yourself, if you’re able to receive mail at that inbox. Not elegant, but it’s the escape hatch when the registry API won’t cooperate.

The full list of reasons Microsoft blocks you

Step 5 of the triage named the usual suspects; here they are in full, drawn from Al Iverson’s long experience with OLC. When your Marketing Cloud Outlook deliverability problem is past the auth mandate and into genuine reputation territory, it’s one or more of these:

Too many spam complaints. The root cause is almost always list quality — third-party, purchased, or co-reg data generates complaints because recipients never asked for the mail. Fix the acquisition, not the symptom.
A poor “Sender Reputation Data” (SRD) score. Microsoft samples recipients and effectively lets them vote on whether your mail is spam. Too many votes and you’re off the island. It doesn’t map cleanly to raw complaint counts, which makes root cause harder to pin down — and no technical fix overrides it. This is a “send mail people actually want” problem.
A volume spike. If you normally send 3,000 a day from an IP and suddenly push 1.6 million, that alone can trip a block. Spread large sends across days and keep an observable, steady daily average — the same discipline that governs IP warming.
Suspected namespace mining. If Microsoft sees you hitting too many invalid addresses, it assumes you’re guessing at addresses. Suppress your user-unknowns and cut bad data sources. (A subtle contributor: sending to a list in strict alphabetical order can look like mining. So can a compromised sending account — worth ruling out.)
SmartScreen. Microsoft’s proprietary content filter. Support won’t tell you specifically what tripped it — they’ll point vaguely at content and recipient interaction — so the fix is the boring fundamentals: wanted mail, engaged recipients, clean content.
Reverse DNS / PTR mismatch. Your sending IP’s reverse DNS should match your HELO/EHLO hostname. If it fails, Outlook may refuse the connection outright — and this shows up as that RCPT/DATA gap in SNDS.

When you request unblocking, the cardinal rule bears repeating: don’t play games. Fix the issue first, submit once, and if you’re warming, ask for pre-emptive accommodation. Going back weekly to re-request without changing anything is how you earn a permanent no.

Where SNDS fits in your Marketing Cloud Outlook deliverability monitoring

To close the loop with the rest of this series: SNDS isn’t a standalone answer, it’s one instrument in the panel. Solid Marketing Cloud Outlook deliverability comes from catching divergence early enough that you never end up in the fire-drill at the top of this article. During warmup and in steady state, I’d watch:

Open rates by ISP domain in SFMC’s Email Performance for All Domains report — your fastest signal that one mailbox provider is diverging from the others.
SNDS for the Microsoft-specific view: IP status, complaint rate, and above all trap hits.
Google Postmaster Tools for the Gmail domain-reputation view.
Your DMARC aggregate reports, so an alignment problem surfaces there before it surfaces as a wall of 5.7.515 bounces.

The catch with all of these is that they’re pull, not push — they only help if you actually log in and look, and by the time a Microsoft problem is bad enough to notice in your headline stats, a single domain has usually been quietly rotting for a week. That’s exactly the gap I built the Deliverability Early Warning System (DEWS) to close. It’s a packaged SFMC automation that builds a daily domain-level performance picture, normalises mailbox providers so outlook.com, hotmail.com, live.com, and msn.com roll up into one “Microsoft” view, and emails you — proactively — when a specific ISP’s bounce or open rate diverges from your campaign average. No dashboard to remember, no query to run by hand: you only hear from it when there’s actual bad news, and the alert tells you which mailbox provider is unhappy with which campaign. It even leans on Al Iverson’s MAGY domains list for the provider mapping, so the grouping matches the same source of truth this whole article rests on. If you take one structural lesson from a Microsoft blocking incident, let it be this: catch the drift at the domain level while it’s still a yellow flag, not after Microsoft has already slammed the gate.

SNDS is unglamorous. The interface is dated, the registration is fiddly, and in SFMC there’s an approval dance on top. But the trap-hit data genuinely isn’t available anywhere else, and for anyone sending serious volume to Outlook.com and Hotmail — which is most of us — that alone earns it a permanent place in the routine.

Microsoft doesn’t hate you. It’s just quicker to lose patience than the others. Strong Marketing Cloud Outlook deliverability comes down to giving it aligned authentication, clean lists, steady volume, and wanted mail — and watching the right signals. Do that, and you’ll stay on the green side of the line.

Warm up your IP — don’t burn it. And keep an eye on Microsoft while you do.