Your legitimate mail server just got this back from Outlook:
550 5.7.1 Unfortunately, messages from [203.0.113.10] 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.Or worse, no error at all — a clean 250 2.0.0 OK, and every message lands silently in the Junk folder where nobody looks. Outlook.com, Hotmail, Live, MSN and consumer Office 365 all run on one shared filtering stack, and that stack keeps a running opinion of your sending IP. The part almost nobody acts on: Microsoft publishes that opinion for free. Two feeds — SNDS (Smart Network Data Services) and JMRP (Junk Mail Reporting Program) — turn a black-box block into a data problem. Enroll, read the numbers, fix the signal, then delist. In that order. Do it backwards and Microsoft's automated mitigation re-blocks you within days.
What Microsoft measures, and where the two feeds fit
Keep the two programs straight, because people conflate them constantly.
- SNDS is aggregate telemetry: a per-IP, per-day dashboard of what Microsoft *sees* about your traffic — how many recipients you hit, your complaint band, and whether you tripped a spam trap. It is what the machine thinks.
- JMRP is a per-complaint feedback loop: every time an Outlook.com user hits Junk on your mail, Microsoft mails you an ARF report. It is what the humans say.
Both are keyed to the sending IP address, not your domain. That is the single most important fact here. Getting SPF, DKIM and DMARC perfect is necessary, but it does not by itself move an IP off the block list — this is an IP-reputation game first and an authentication game second. Authentication is how you *stop poisoning* the IP; reputation is the thing that actually gets scored.
Getting into SNDS (the enrollment friction is the point)
Register at `https://sendersupport.olc.protection.outlook.com/snds/` (the old postmaster.live.com/snds/ alias still redirects). Sign in with any Microsoft account, then request access for a single IP or a CIDR range.
The friction is deliberate: Microsoft verifies that you actually control the netblock. It sends an authorization link to the contact addresses registered for that IP range — the WHOIS / RIR abuse and admin contacts, or the technical contact on the ARIN/RIPE object. You do not get to pick the destination address. If you rent your IP from a hosting provider, you almost certainly don't control that WHOIS record, so the authorization mail lands with them. Open a ticket asking your provider to forward the SNDS authorization link, or to add your address as an abuse-c contact. This is where most people give up. Don't.
Once authorized, grab an Automated Data Access (ADA) key from the SNDS settings. It lets you pull CSV without logging into the web UI — exactly what you want for cron jobs and alerting. Expect data to appear roughly 24–48 hours after your first traffic to Microsoft, as one row per IP per UTC day.
Reading the SNDS data view like a dashboard
This is the diagnostic heart. The data view gives you these columns per IP per day:
- Activity period — the UTC day the row covers.
- RCPT commands — how many recipients you *attempted*.
- DATA commands — how many messages you actually transmitted.
- Message recipients — recipients that reached the filtering stage.
- Filter result — GREEN / YELLOW / RED. This is the headline.
- Complaint rate — a bucketed band (<0.1%, 0.1–1%, and up).
- Trap message period and Trap hits — spam-trap collisions.
Read it the way an SRE reads a latency graph:
- GREEN, 0 trap hits, complaints < 0.1% — healthy. Keep doing exactly this.
- YELLOW — borderline. Complaints creeping into 0.1–1%, or volume spiking off your baseline. Treat it as an incident, not a shrug.
- RED — you are actively filtered. Something turned it red, and there are only two independent killers: complaint rate and trap hits.
Sustained complaints above roughly 0.3% put you on thin ice; a nonzero trap-hit column is a five-alarm fire. Traps mean you are mailing purchased or stale lists, or hitting recycled addresses that Microsoft converted into pristine traps after a run of hard bounces. You cannot argue with a trap hit — you can only find and kill the list segment that produced it.
Pull the CSV with your ADA key:
# Per-day activity data (the columns above)
curl -s "https://postmaster.live.com/snds/data.aspx?key=YOUR_ADA_KEY" -o snds.csv
# Current per-IP status / color, machine-readable
curl -s "https://postmaster.live.com/snds/ipStatus.aspx?key=YOUR_ADA_KEY"Wire that into a nightly job and alert on any row where the filter result is not GREEN. You want to hear about YELLOW from your own monitoring, not from a customer asking why their password reset never arrived.
Wiring up JMRP so complaints come to you
Enroll for JMRP at the same sender support portal. It requires an existing SNDS relationship for the IP range, so do SNDS first. You nominate one recipient address per IP or range; from then on, every time an Outlook.com user marks your mail as Junk, that address receives an ARF message (Abuse Reporting Format, RFC 5965).
The catch that makes or breaks JMRP: the reports are redacted. The complaining recipient's address is stripped, so you cannot simply read off "unsubscribe this person." You correlate by the original message headers that ARF embeds back to you — which means you have to instrument your outbound mail *now*, before the complaints arrive, so the reports are actionable later. At minimum, put a stable per-send or per-subscriber identifier in a custom header and set the unsubscribe headers:
List-Id: EvilMail alerts <alerts.evilmail.pro>
List-Unsubscribe: <https://evilmail.pro/u/9f3a...>, <mailto:[email protected]?subject=9f3a>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
X-EM-Campaign: 2026-07-alertsWhen the ARF report comes back with those headers intact, you can map the redacted complaint to a subscriber and suppress them. Pipe the JMRP mailbox straight into your suppression list — one complaint, one instant unsubscribe, no human in the loop. Ignoring JMRP is worse than not having it: Microsoft knows the loop exists, and continuing to mail people who complained is precisely the behavior that keeps your row RED.
From RED to GREEN: the fix loop
Here is the opinionated part, and the reason most delisting requests fail. Order of operations is not optional.
- 1.Fix the envelope. PTR must exist and forward-confirm (FCrDNS). SPF must pass. DKIM must sign. DMARC must be published and aligned. Your HELO/EHLO name must match the PTR and resolve to an A record. This is table stakes; Microsoft treats a spoofable or unauthenticated envelope as a reason to distrust everything else.
- 2.Fix the list. Suppress every address that ever produced a JMRP complaint. Find and delete the segment that generated trap hits — usually that means dropping any list you didn't collect yourself with confirmed opt-in.
- 3.Then, and only then, request mitigation at `https://sender.office.com/` (the Microsoft Sender Information and Support form).
What the form grants is conditional mitigation: a temporary lift while Microsoft re-watches your complaint and trap signals over the next few days. If those signals are still bad — because you delisted without fixing them — the automated system slams the door again, and repeat offenders earn longer cool-downs.
Decode the codes so you know which door you're at:
- S3150 — blocked but mitigation-eligible via the form.
- S3140 / S3115 — policy/reputation blocks in the same family.
- 550 5.7.606–649 — the "access denied, banned sending IP" class. These require the mitigation form; there is no self-clearing.
DNS and auth records to have in place
Verify every layer from the command line before you file anything. Using evilmail.pro's own mailflow as the worked example:
# 1. Reverse DNS must forward-confirm (FCrDNS)
dig -x 203.0.113.10 +short # -> mail.evilmail.pro.
dig +short mail.evilmail.pro # -> 203.0.113.10 (must match)
# 2. SPF authorizes the sending IP, hard-fails the rest
dig +short TXT evilmail.pro
# "v=spf1 ip4:203.0.113.10 -all"
# 3. DKIM public key on the selector you sign with
dig +short TXT default._domainkey.evilmail.pro
# "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ..."
# 4. DMARC published and strictly aligned
dig +short TXT _dmarc.evilmail.pro
# "v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=s; aspf=s"If dig -x returns nothing, or the forward lookup doesn't come back to the same IP, Microsoft never gets past gate 1 — fix rDNS with your host before anything else.
Diagnostic checklist
Run this when Outlook delivery drops:
- Pull SNDS status for the IP: GREEN, YELLOW, or RED? Note trap hits and complaint band.
- Read the SMTP rejection verbatim — capture the S-code (S3150, 5.7.606, etc.); it tells you whether the form even applies.
- Confirm FCrDNS:
dig -xand the forward lookup match, HELO name resolves. - Confirm SPF pass, DKIM sign, DMARC alignment with the
digchecks above. - Check the JMRP mailbox — is it enrolled, and are complaints being auto-suppressed?
- Find the trap source if trap hits > 0: which list segment or import produced them? Delete it.
- Suppress all recent complainers before touching the delist form.
- File sender.office.com mitigation only after the above are done.
- Re-check SNDS 24–48h later
Operating cadence
Check SNDS weekly at minimum, daily via the ADA CSV if you send serious volume. Treat any YELLOW as an incident with an owner, not a note-to-self. Keep the JMRP suppression loop fully automatic — a complaint should unsubscribe someone before you've finished reading the report. And respect the physics: Microsoft's reputation memory runs in weeks, not hours. One heroic list scrub won't undo a month of 0.4% complaints, and one bad send won't sink a consistently clean IP. Consistency beats heroics. That discipline — clean lists, aligned auth, an instrumented feedback loop, and never delisting before you've fixed the signal — is the same mailflow hygiene that keeps evilmail.pro's own infrastructure in the inbox.