550 5.7.1 “Unfortunately, messages from [IP] weren’t sent” — How to Fix It

If Microsoft is bouncing your email with this line in the SMTP response, you're in the right place:

550 5.7.1 Unfortunately, messages from [203.0.113.42] weren't sent.
Please contact your Internet service provider since part of their network
is on our block list (S3140). You can also refer your provider to
http://mail.live.com/mail/troubleshooting.aspx#errors.

This is an IP-level rejection from Outlook.com / Hotmail / Live (the consumer side of Microsoft mail). It is not a content rejection, an authentication rejection, or a per-recipient block. The sending IP itself is on Microsoft's internal block list and every message from it is being refused at the SMTP boundary.

What 550 5.7.1 Actually Means

Microsoft has its own internal IP reputation system that sits in front of Exchange Online Protection (EOP) and Outlook.com's filters. When that system decides a sending IP is sending too much spam, has a poor SNDS color, or matches one of their internal abuse signals, it stops accepting connections from that IP entirely.

The S-codes give you the reason:

Code	Meaning
S3140	IP listed for poor reputation / spam complaints
S3150	IP listed, plus authentication or content signals failing
S3115	Listed on a third-party blocklist Microsoft consumes

In every case the remediation path is the same.

Step 1: Confirm the Block Is Really IP-Based

Before you fill in a delisting form, make sure the issue isn't actually a recipient block (550 5.7.606) or a tenant block (550 5.7.708). The IP in square brackets in the bounce tells you which IP Microsoft is unhappy with, and that's the one you delist.

Run that IP through our blacklist checker to confirm whether any third-party DNSBL is also listing it. Microsoft uses Spamhaus signals as one input, so a Spamhaus PBL/XBL listing makes a Microsoft block far more likely.

Step 2: Register for SNDS and JMRP — Today

You cannot meaningfully fix Microsoft deliverability without:

• SNDS (Smart Network Data Services) shows the reputation Microsoft assigns to your IPs.
• JMRP (Junk Mail Reporting Program) is the feedback loop that tells you when Outlook.com users hit "report junk".

Both are free. SNDS will show you a colored status for each IP:

• Green: healthy, low complaint rate.
• Yellow: elevated complaints or spam-trap hits, watch list.
• Red: bad enough that delivery is throttled or blocked.

If your IP is red in SNDS, the delisting form below will likely fail until you fix the underlying complaint or trap problem.

Step 3: Submit the Sender Information Form

For Outlook.com, Hotmail and Live, the delisting route is Microsoft's Outlook.com sender support form, which Microsoft links from its delist documentation. Do not use sender.office.com for an S3140: that portal removes IPs blocked by Microsoft 365 (550 5.7.606-649). Expect a response within 24–48 hours.

In the form:

1. Use a reply-to address on the sending domain, not a Gmail or freemail address.
2. List all affected IPs in CIDR or single-IP format.
3. Explain what you send, expected daily volume, and how recipients opted in.
4. Confirm you've enrolled in SNDS and JMRP and have valid SPF + DKIM + DMARC.

If you've never delisted before, the request is usually approved. A second or third delisting on the same IP within 90 days is rarely approved, because Microsoft assumes the underlying problem isn't fixed.

Step 4: Fix the Underlying Reason

Delisting without fixing root cause means you'll be back within days. Run through:

• Authentication: verify SPF, DKIM, and DMARC alignment with our Domain Health tool. Microsoft increasingly treats SPF/DKIM failure as a near-instant relisting signal.
• List hygiene: purge bounces, unengaged contacts older than 90 days, and any purchased data.
• Volume ramp: if you just spiked from 5k/day to 50k/day, throttle back and warm up over 2–4 weeks.
• Complaint rate: Microsoft considers anything above 0.3% complaint rate as a hard problem. JMRP reports tell you the exact addresses to remove.

Step 5: Add IP Reputation Monitoring

Once you've been delisted, set up monitoring so you catch the next listing in hours, not after a customer escalation.

MailVitals' IP Monitoring tracks your sending IPs against 25 DNSBLs and pulls Microsoft SNDS color signals so you get a Slack/email alert the moment something turns yellow.

FAQ

How long does Microsoft delisting take? Most first-time delisting requests are processed within 24–48 hours. Repeated requests on the same IP take longer and are more likely to be rejected without a clear remediation explanation.

Why was my second delisting request denied? Microsoft's automated system flags repeat offenders. If you delist, then trigger the same complaint or trap pattern, the second request is reviewed by a human who is looking for evidence you've actually changed sending practices.

Can I send through a different IP while delisting? Yes. If your ESP has spare IPs or a backup pool, switching is the fastest way to restore delivery while the form is reviewed. Just don't bring a brand-new IP into production cold; warm it.

Related

• S3140 / S3150 Microsoft SMTP Errors Explained
• SNDS & JMRP Setup Guide

Sources

• Outlook.com Postmaster: Troubleshooting, Outlook.com's own list of 550 block codes (SC-001 to SC-004, DY-001, OU-001) and its point that junk complaints are a principal driver of reputation.
• Use the delist portal to remove yourself from the blocked senders list (Microsoft Learn), sender.office.com covers Microsoft 365 blocks (5.7.606-649); Outlook.com has a separate delisting form.
• Outlook.com Postmaster: Services for Senders and ISPs, SNDS and JMRP as the free Outlook.com reputation and complaint feeds, with JMRP feedback from about 72 hours after enrolling.
• Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders (Microsoft Tech Community), the SPF, DKIM and DMARC rules Outlook.com applies to domains sending over 5,000 messages a day.