550 5.7.1 "Unfortunately, messages from [IP] weren't sent" — How to Fix It
The 550 5.7.1 rejection from Outlook.com almost always points at IP reputation. Here's how Microsoft decides to block, and the exact steps to get unblocked and stay that way.
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 — 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) — 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
The official delisting URL is sender.office.com → "Submit a delisting request". Microsoft's automated system reviews requests on a rolling basis. Expect a response within 24–48 hours.
In the form:
- Use a reply-to address on the sending domain — not a Gmail or freemail address.
- List all affected IPs in CIDR or single-IP format.
- Explain what you send, expected daily volume, and how recipients opted in.
- 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 — 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 34 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.