Sharing this in case it helps other NS8 admins. I hit this wall recently. Mail to some Microsoft-hosted recipients just stopped arriving. Here’s what happened, and how I fixed it.
The symptoms
Mail from one of my domains stopped reaching Microsoft mailboxes. Outlook.com, Hotmail, and some Microsoft 365 tenants. Two behaviours showed up:
- Hard bounce (NDR). Error code
5.7.606-649. Message said “banned sending IP”. It pointed to a delisting portal. - Silent drop. No NDR at all for some tenants. Mail just disappeared. Nothing useful in the logs on their side.
First clue: Postfix logs on my NS8 mail module. SMTP responses mentioned Microsoft’s S3140 block code. This code means the IP is on a range with bad reputation. In my case, the whole subnet was flagged. Not just my IP.
Here’s an anonymized real bounce I got:
<recipient@example-outlook-domain.tld>: host
outlook-com.olc.protection.outlook.com[XX.XX.XX.XX] said: 550 5.7.1
Unfortunately, messages from [YOUR.SENDING.IP.HERE] 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. [Name=Protocol
Filter Agent][AGT=PFA][MxId=xxxxxxxxxxxxxxxx]
[TYxPEPFxxxxxxxx.xxxprdxx.prod.outlook.com 2026-xx-xxTxx:xx:xx.xxxZ
xxxxxxxxxxxxxxxx] (in reply to MAIL FROM command)
The key line is part of their network is on our block list (S3140). That’s the tell. It’s not about your domain or your mail content. It’s about the IP range itself.
That’s an important point. You can do everything right. You can still get blocked. If your neighbours on the same /24 send spam, you pay for it too.
Step 1 — Check the basics first
Before blaming Microsoft, I checked my own setup. Microsoft won’t even look at a delisting request if these aren’t clean:
- SPF. One TXT record. All authorized sending IPs. End with
-all. - DKIM. Signing active (rspamd/opendkim on the mail module). Public key published. Verify with
dig TXT selector._domainkey.yourdomain.tld. - DMARC. A
_dmarc.yourdomain.tldTXT record. Start withp=noneif unsure. Pointrua=to an address you actually read. I pulled the DMARC aggregate reports to confirm alignment was passing. No point asking for delisting if your own reports show failures.
All three were already correct. Anonymized, here’s roughly what a clean setup looks like:
SPF: v=spf1 ip4:xx.xx.xx.xx ip4:xx.xx.xx.xx mx ~all
DMARC: v=DMARC1; p=reject; pct=100; adkim=s; aspf=s; rua=mailto:dmarc@yourdomain.tld; ruf=mailto:dmarc@yourdomain.tld
DKIM: default._domainkey.yourdomain.tld → valid RSA key published
Note the DMARC policy: p=reject, strict alignment on both SPF and DKIM (adkim=s; aspf=s), reports going somewhere I actually read. That’s stricter than what most domains run. Worth aiming for, not just p=none.
So the problem was pure reputation. Not a config bug on my side.
Step 2 — Make sure abuse@ is real
Microsoft often replies to the abuse@ address on file. Either the domain’s or the IP’s WHOIS entry (RIPE, for European IPs). If that mailbox bounces, your request goes nowhere. I checked:
abuse@domain.tldexists. It’s not a black hole.- It matches what RIPE has for the IP range.
- Someone reads it. Me, in this case.
Sounds obvious. It’s the detail people skip.
Step 3 — Enroll in JMRP and SNDS
Two separate free programs, both on the same Microsoft sender support portal:
- JMRP (Junk Mail Reporting Program) — Smart Network Data Services. When a recipient marks your mail as junk, you get a forwarded copy. No volume threshold — even at ten messages a day, a single complaint reaches you.
- SNDS (Smart Network Data Services) — Smart Network Data Services. Gives you visibility on volume, complaint rate, spam trap hits for your IP.
Heads up on SNDS: it has a display floor. Microsoft won’t show data for an IP sending under roughly 100 messages a day. If you’re a small transactional sender, don’t be surprised if the dashboard just says “No data for specified IPs” every single day. That’s normal, not a sign you did something wrong. It also only covers the consumer Outlook.com/Hotmail/Live space, nothing on the Microsoft 365 side.
JMRP has no such floor, so it becomes your real source of evidence, even for a low-volume sender.
Step 4 — Find the right portal
This part cost me time. Microsoft has different portals depending on who’s rejecting you:
- Outlook.com / Hotmail / Live (consumer) → Smart Network Data Services for SNDS/JMRP enrollment and consumer-side delisting/mitigation requests.
- Microsoft 365 / Exchange Online (tenant mailboxes) → https://sender.office.com/. This is the dedicated IP delist portal for the
550 5.7.606-649 banned sending IPcase. Anyone can use it. Even non-M365 customers.
My case involved a shared hosting subnet, not just my IP. So I also opened a ticket with the hosting provider’s abuse team. In parallel with the Microsoft request. Don’t wait for the provider to notice on their own. They usually escalate only after several customers on the same range complain.
Step 5 — Ask properly, with evidence
Microsoft’s delisting form wants specifics. Not a generic complaint. What worked for me:
- The exact NDR code and timestamp of a rejected message.
- Proof that SPF/DKIM/DMARC pass and align. A dig output or screenshot helps.
- A short note on volume and purpose. This domain isn’t a bulk mailer. Low-volume business mail.
- Confirmation that abuse@ is monitored.
Vague requests get ignored or bounced back. Specific ones get processed.
One more thing worth knowing: my first attempt was auto-rejected. The self-service delisting form ran through some automated check and said no, no human involved. So I had to escalate. I opened a support ticket instead, with an actual person on the other end. In that ticket I had to prove two things clearly:
- I’m not sending spam. Low volume, real business mail, no bulk sending.
- I actively monitor what goes through my SMTP server. Logs, alerts, the works. Not just a fire-and-forget setup.
That’s what got it moving. If the automated form says no, don’t give up there. Ask for a human.
Step 6 — Wait, and monitor
Delisting takes time. It’s not instant. SNDS, once enrolled, shows if your IP is still flagged. It also shows your complaint rate. Useful to confirm things are actually improving.
Outcome
The delisting request went through. The hosting provider fixed the wider subnet issue. Mail started flowing again. Both to Outlook.com and Microsoft 365 recipients. No more NDRs.
No changes were needed on the NS8/Postfix side. SPF/DKIM/DMARC and the abuse mailbox were already correct. That’s exactly what made the delisting request easy to argue.
TL;DR
- Check the exact NDR code. It tells you which blocklist, and which portal to use.
- Confirm SPF/DKIM/DMARC first. Before asking for delisting.
- Make sure abuse@ exists. And that someone reads it.
- Use sender.office.com for M365/Exchange Online blocks. Use the sender support portal for consumer Outlook.com/Hotmail issues.
- On shared hosting? Push your provider’s abuse team too. You might be collateral damage from a neighbour’s IP.
- Give Microsoft specifics. Not just a plea.
- If the automated form rejects you, escalate to a human. Prove you’re not spamming and that you monitor your SMTP.
Happy to answer questions if anyone’s dealing with the same thing on their NS8 install.
From my experience the automated way will fail, then you report it and they do the necessary MS voodoo tricks and you’re good to go. It might be worth asking them why you have to do that every now and then; it wasn’t necessary in my case.