Your campaign goes out, and Outlook and Hotmail addresses start bouncing with something like this:
550 5.7.1 Unfortunately, messages from [12.34.56.78] weren’t sent. Please contact your Internet service provider since part of their network is on our block list (S3150). You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors.
Microsoft is two very different systems wearing one name. Outlook.com and Hotmail are consumer mailboxes filtered by Microsoft’s own reputation engine. Microsoft 365 is tens of thousands of corporate tenants, each with an admin who can block you independently of anything Microsoft decides.
The bounce code tells you which one you’re fighting. Get that wrong and you’ll spend a week filing delisting requests to a system that was never blocking you. This guide decodes every variant, then walks the fix in the order that works.
Table of Contents
What Microsoft Is Actually Doing When It Blocks You
Microsoft filters inbound mail on two tracks that share code but not policy.
Consumer (Outlook.com, Hotmail, Live, MSN). Filtering is centralized. Microsoft evaluates your sending IP against its own reputation data — complaint rates from users hitting “Junk,” spam trap hits, volume patterns, authentication results. Blocks here are IP-level and Microsoft-controlled. The mail servers are *.olc.protection.outlook.com.
Microsoft 365 / Exchange Online (corporate tenants). Mail passes Exchange Online Protection first, then lands inside a tenant that has its own anti-spam policies, connectors, blocked-sender lists, and Defender for Office 365 rules. The mail servers are *.mail.protection.outlook.com. A rejection here may come from Microsoft’s shared blocklist — or from one company’s admin who added your domain to a block list. Microsoft cannot delist you from the latter. Only that tenant’s admin can.
This split is why senders get stuck. They file a mitigation request at Microsoft’s delist portal for a block that lives inside a single customer’s tenant policy, wait 48 hours, and get nothing — because there was nothing at Microsoft’s end to remove.
Decoding the Error: Microsoft Block Codes Reference
Find your exact string here before you do anything else.
Microsoft has never published a legend for its S-codes. The distinctions below are the deliverability community’s working consensus from observed behavior, not documented Microsoft policy — treat them as a triage heuristic, not a specification.
Two codes deserve emphasis. 451 4.7.500-699 is not a block — it’s Microsoft’s probation period for senders whose volume pattern changed, and hammering retries is how it becomes one. And 5.7.511 is the code Microsoft explicitly excludes from the self-service portal; senders waste days resubmitting there instead of emailing [email protected]. For how these sit alongside every other enhanced status code, see 5.7.511, 5.7.515 and the 5.7.606–649 range in the wider reference.
How to Confirm This Is Your Problem
Grep your bounce logs for:
- The literal strings S3150, S3140, 5.7.606, 5.7.511, 5.7.515
- Rejecting hosts ending in olc.protection.outlook.com (consumer) versus mail.protection.outlook.com (Microsoft 365) — this single distinction routes your entire fix
- 451 4.7.500 deferrals, which are the early warning that precedes an S3140/S3150 listing
Then check the IP itself in SNDS. If your Outlook.com delivery is collapsing but the block codes are absent, you’re not blocked — you’re being filtered to Junk, which is a reputation problem, not a delisting problem. If the bounce names OU-001 instead, Microsoft is enforcing a third-party listing — OU-001 means delist at Spamhaus, not at Microsoft.
The 5 Most Common Reasons Microsoft Blocks Senders
1. Complaint rate above Microsoft’s tolerance
Microsoft is unusually complaint-sensitive because it has unusually good complaint data — every “Junk” click from an Outlook.com user feeds the reputation engine directly. This is the dominant cause of S3140 listings.
2. Volume ramp on a new or cold IP
An IP with no sending history at Microsoft that suddenly pushes tens of thousands of messages looks like a compromised host. You get 451 throttling first, then S3150 if you push through it.
3. Missing or misaligned authentication at bulk volume
Since May 5, 2025, domains sending more than 5,000 messages a day to Outlook.com, Hotmail and Live must pass SPF, pass DKIM, and publish a DMARC record at minimum p=none with alignment to SPF or DKIM. Non-compliant mail went to Junk first, then to outright rejection with 5.7.515.
4. Spam traps and stale addresses
Hotmail and Live addresses abandoned years ago get recycled into traps. Any list that has sat unmailed for a year is carrying them.
5. Shared IP contamination, or one tenant’s own policy
On a shared pool, another sender’s complaints can list the IP you send from — Microsoft blocks the IP, not the tenant. Separately, a single company’s admin can block you inside their own Microsoft 365 tenant; that looks identical in your logs until you notice the failures are confined to one recipient domain.
How to Fix It: Step by Step
The order matters more here than with almost any other provider. Microsoft’s mitigation team looks at your current SNDS status when it processes your request. If SNDS is red when your request lands, expect the request to be denied, and denied requests make subsequent ones harder. Microsoft doesn’t document how that decision is made or how quickly — practitioners generally report denials arriving fast enough to suggest little or no human review.
Correct order: identify → check SNDS → fix → request mitigation → re-warm.
Step 1: Identify the variant
Use the table above. Consumer or commercial? Microsoft’s block or a tenant’s? Block or throttle? Every subsequent step depends on this answer, and it takes two minutes.
Step 2: Enroll in SNDS and read your IP status
Smart Network Data Services is free and it is the only window you get into how Microsoft sees your IP. Register at aka.ms/snds, sign in with a Microsoft account, and request access for the IPs you’re responsible for. Microsoft verifies control via the IP’s WHOIS or rDNS contact. For the full Microsoft sender ruleset, SNDS and JMRP reference, see our maintained reference page.
SNDS gives you a per-IP daily report with exact recipient and RCPT command counts, a complaint rate, and a color-coded filter result. Microsoft’s SNDS FAQ defines these as spam-verdict rates, not block states: green is under 10% of that IP’s mail filtered as spam, yellow is 10 to 90%, red is over 90%. Red means nearly everything was junked, which is a reputation emergency but not by itself proof of a block. Microsoft reworked SNDS through 2026: the portal moved, report links now expire after 30 days, and network access approvals need renewing roughly every 10 months. Use the aka.ms/snds shortlink rather than bookmarking a deep URL. Note also that Microsoft is removing trap-hit counts from the SNDS Data Report starting 22 July 2026, so from that date onward an absence of trap data will no longer mean an absence of traps.
Step 3: Enroll in JMRP
The Junk Mail Reporting Program is Microsoft’s complaint feedback loop, and it matters more than most senders realize — Microsoft is one of very few large providers that operates one at all. Sign up at the JMRP portal using the same account, register your IPs, and supply an address to receive complaint reports.
Every JMRP report is a recipient who clicked Junk. Auto-suppress them immediately, permanently, across every list. A sender who ignores JMRP data is manufacturing the next S3140 listing.
Step 4: Fix the underlying behaviour
- Suppress everyone in the JMRP feed and everyone with no engagement in 90 days at Microsoft domains
- Verify the list and remove invalid addresses
- Confirm SPF passes, DKIM signs and verifies, and DMARC is published with alignment — this is mandatory above 5,000/day to hotmail.com, live.com and outlook.com, and helps everywhere else
- Ensure a working, visible unsubscribe and a valid, monitored From and Reply-To address
- Pause sending to Microsoft domains from the affected IP while you do this
Step 5: Request mitigation — with the right form for your code
Now, and only now:
- 5.7.606-649: the Office 365 Anti-Spam IP Delist Portal at sender.office.com. One email address and one IP per submission; use the address that received the NDR. You’ll get a confirmation email, then click through to select Delist IP. Allow up to 24 hours.
- 5.7.511: forward the complete NDR, including the code and IP, to
[email protected]. Microsoft responds within about 48 hours. - S3140 / S3150 (consumer): these are not handled by sender.office.com. Use the Outlook.com Delivery Support form at olcsupport.office.com, which covers @outlook.com, @hotmail.com, @live.com and @msn.com only.
- 5.7.515: there is nothing to request. Fix authentication and the rejections stop.
Practitioners consistently report that mitigation requests filed by individual senders on shared IPs are usually denied, though Microsoft publishes no policy to that effect. Microsoft holds the IP operator responsible, so escalate through your ESP rather than filing alone. Tone matters too: a specific, factual request naming what changed gets a human’s attention. A demand, or a resubmission of an identical request that was already denied, does not.
Step 6: Re-warm deliberately
Once delisted, restart at 10–25% of normal Microsoft volume, to your most engaged recipients only, and roughly double every couple of days while SNDS stays green. Returning to full volume immediately is the single most common way senders get relisted within a week.
Paste-Ready Microsoft Mitigation Request
Adapt the bracketed fields. Keep it this short.
Subject: Delisting request — [IP address] — [your sending domain]
Hello,
We are requesting mitigation for IP [IP address], which is returning [exact error code and full bounce string] when sending to Microsoft recipients.
This IP is a [dedicated / shared] IP operated by [company], used for [transactional / opt-in marketing] mail for [sending domain]. Typical daily volume to Microsoft domains is [N].
Root cause: [e.g. an imported list from a 2023 event contained stale Hotmail addresses, which raised our complaint rate].
Remediation completed on [date]:
- Suppressed [N] addresses with no engagement in 90 days
- Enrolled this IP in SNDS and JMRP; all JMRP complaints now auto-suppress
- Verified the affected list and removed [N] invalid addresses
- Confirmed SPF pass, DKIM signing on [domain], and DMARC published at [policy]
- Paused all sending to Microsoft domains since [date]
SNDS currently shows this IP as [green / yellow] with a complaint rate of [X%].
On restoration we will resume at approximately 20% of prior volume to engaged recipients only and ramp gradually.
Contact: [name, role, email, phone]
How to Prevent Microsoft Blocks
- Watch SNDS weekly, not after a bounce. The complaint rate climbs before the block lands. Yellow is your window to fix things without a mitigation request.
- Treat JMRP as an automated suppression feed. Pipe it into your suppression list programmatically — manual handling means complaints keep accruing while someone reads their inbox.
- Authenticate above the threshold and below it. SPF, DKIM and DMARC are mandatory over 5,000/day to hotmail.com, live.com and outlook.com, and strongly weighted below that. No reason to sit at
p=noneforever once your alignment reports are clean. - Respect 451 deferrals. Reduce concurrency and delivery rate rather than retrying harder. Deferral is a negotiation; ignoring it converts it to a block.
- Segment Microsoft domains in your reporting. Track delivery, complaint and deferral rates for outlook.com, hotmail.com and live.com separately. Aggregate numbers hide a Microsoft problem until it’s a listing.
Shared IP vs Dedicated IP: Who Fixes What
On a shared pool, the IP reputation belongs to your provider, and Microsoft will generally decline a mitigation request from an individual sender on that pool. Your job is list quality and complaint rate; your provider’s job is pool hygiene, SNDS and JMRP enrollment for every pool IP, and the mitigation relationship with Microsoft. If your provider isn’t enrolled in SNDS for the IPs you send from, ask why.
On a dedicated IP, all of it is yours: enroll in SNDS and JMRP yourself, monitor it, and file your own mitigation requests. You also get the upside — your reputation is uncontaminated by anyone else’s list.
How Mailercloud Handles Microsoft Deliverability
We deliver over a billion emails a month, so Microsoft blocks are a daily operational reality rather than an emergency. Every sending IP in our pools is enrolled in SNDS and JMRP, complaint feeds auto-suppress at the platform level, we throttle to Microsoft in response to 451 deferrals instead of retrying through them, and our deliverability team owns the mitigation and re-warm process when a listing happens.
If you’re looking at an S3150 bounce right now, or your Outlook delivery has quietly collapsed, talk to our deliverability team — or start free with Mailercloud.
FAQ: Microsoft 550 5.7.1 Blocks
How long does a Microsoft block last?
Anecdotally, senders report that consumer S3140/S3150 listings often clear on their own within a few days once the triggering traffic stops — Microsoft documents no expiry for these codes, so treat that as a practitioner observation rather than a published behavior. Delist requests at sender.office.com can take up to 24 hours or longer to propagate; 5.7.511 requests handled via [email protected] typically get a response within 48 hours.
What’s the difference between S3150 and S3140?
S3150 is generally limit-driven — you exceeded what Microsoft expects from that IP. S3140 is reputation-driven — complaints, traps, or poor list quality. The remediation overlaps heavily, but S3140 means your list is the problem, and mitigation without cleaning it will be denied.
Why did my delisting request get denied?
Three common reasons: SNDS still showed red when the request was processed; the IP is shared and Microsoft expects the operator to file; or the request was a resubmission with nothing changed. Fix the underlying signal, wait for SNDS to move, then file once.
My mail is accepted but goes to the Outlook spam folder. Is that a block?
No, and it needs a different fix. There’s nothing to delist. Work the reputation signals — SNDS complaint rate, JMRP suppressions, DMARC alignment, engagement segmentation — because Junk placement is Microsoft telling you your reputation is marginal rather than bad. We cover that case in depth in our guide to mail going to spam only at Outlook.
Does Microsoft really offer a feedback loop?
Yes — and it’s more useful than most. Roughly thirty providers run ARF feedback loops, mostly brokered through Validity’s Universal FBL; Microsoft and Yahoo are the two that matter at Western B2C scale. Google’s Feedback Loop gives per-campaign complaint data via an injected Feedback-ID header but never per-recipient ARF, and gateways like Proofpoint give senders nothing. If you send meaningful volume to Outlook.com, JMRP is your best diagnostic signal.
What is Outlook error S3150 (or S3140)?
They’re Microsoft’s internal block codes for consumer Outlook.com, Hotmail, and Live.com, returned inside a 550 5.7.1 rejection. S3150 is limit-driven — a volume spike or a cold IP sending too hard — while S3140 is reputation-driven, from complaints or poor list quality. Note that early 2026 saw a wave of S3150 false positives hitting clean, low-volume senders, so check SNDS first: if it’s green and you’re still blocked, you have a strong case to escalate rather than a problem to fix.
I submitted the Outlook delisting form and nothing happened. What now?
That’s common — the form often auto-replies “Nothing was detected to prevent your mail…” even while rejections continue. The workaround senders report success with: reply to that automated email with your specifics (sending domain, IPs, sample NDR, SNDS screenshot), which escalates the ticket to a human reviewer. Keep the sending paused or throttled while you wait, because new bounces during review weaken your case.
Amar CP is the Co-Founder and Sales Director at Mailercloud, where he leads partnerships, alliances, and customer growth. With over a decade of experience in application development, database architecture, and scaling web systems, Amar brings a rare blend of engineering depth and go-to-market expertise to email marketing. He writes about email deliverability, marketing automation, and helping small businesses grow smarter with data-driven campaigns.
