S3150: part of their network is on our block list

Outlook.com refused mail from your sending IP. The block applies to the IP, and changing your domain's DNS records does not lift it. Find out who controls that IP, clean up what earned the block, and file with the Outlook.com form. The Microsoft 365 delist portal does not cover Outlook.com.

Quick answers

What does S3150 mean in an Outlook.com bounce?
The bounce text says it: messages from the IP in brackets were not accepted because that IP, or part of the network it belongs to, is on the Outlook.com block list. It is a reputation block on the sending IP. Microsoft does not define S3150 on the Outlook.com postmaster site; its SMTP error table lists SC, DY and 5.7.515 codes but no S-codes.
Can I use sender.office.com to remove an S3150 block?
No. The Office 365 Anti-Spam IP Delist Portal at sender.office.com handles the Microsoft 365 blocked senders list, which produces 550 5.7.606-649 banned sending IP bounces. Microsoft's delist documentation points senders blocked by Outlook.com, the consumer service, to a separate delisting form at olcsupport.office.com.
Is S3150 caused by SPF, DKIM or DMARC?
Not directly. The block names an IP address, and publishing or fixing DNS records does not remove it. Authentication still matters: Outlook.com requires SPF, DKIM and DMARC from domains that send more than 5,000 messages a day to its users, and a request for mitigation is weaker if your mail does not pass.
The bounce says to contact my Internet service provider. Do I have to?
Only if you do not control the IP. If the bracketed IP belongs to your ESP, your hosting company or a shared relay, the owner of that IP has to fix the cause and request mitigation. If the IP is your own mail server, you file the request yourself.
Should I keep retrying mail that bounced with S3150?
No. The Outlook.com postmaster policies say a sender that receives a 5xx response must not retransmit that message to that recipient, and must stop sending to a recipient after multiple non-delivery responses.

The exact bounce string

Mail to an Outlook.com, Hotmail, Live or MSN address comes back with a non-delivery report that reads: 

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

The IP in brackets is the server that connected to Outlook.com and tried to hand the message over. Senders quote this string in Microsoft Q&A threads such as network is on our block list (S3150) and blocked by Outlook.com, Block List S3150. A sibling code, S3140, carries the same sentence.

The mail.live.com/mail/troubleshooting link now lands on the Outlook.com postmaster site. Its SMTP error table (Postmaster troubleshooting, checked 26 September 2026) lists SC-002, SC-004, DY-001, DY-002 and 550 5.7.515. It does not define S3150 or S3140. What you have to work with is the text of the bounce: a block against the sending IP or its network.

Which Microsoft service rejected the mail

Microsoft runs two receiving systems with separate block lists and separate delisting paths. The path depends on which one rejected the mail. In one of the Q&A threads above, the sender checked the blocked IP at sender.office.com and was told it was not blocked, while Outlook.com kept bouncing the mail with S3150.

  • (S3150) or (S3140): Outlook.com, the consumer service. Delist through the Outlook.com form at olcsupport.office.com.
  • 550 5.7.606-649 Access denied, banned sending IP: a Microsoft 365 recipient. Delist yourself at sender.office.com.
  • 550 5.7.511 Access denied, banned sender: a Microsoft 365 recipient, after further investigation. The portal cannot help; forward the NDR to [email protected].
  • 550 5.7.515: Outlook.com rejected mail from a domain that sends more than 5,000 messages a day without the required SPF, DKIM and DMARC. The fix is SPF, DKIM and DMARC; there is nothing to delist.

The portal, the 5.7.511 route and the pointer to the Outlook.com form all come from Microsoft's Remove yourself from the blocked senders list (updated June 2026). Its closing section links the delisting form for "Outlook.com, the consumer service" and asks senders to read the postmaster FAQ first.

To confirm which side a recipient domain is on, look up its MX records with the MX lookup or dig: 

$ dig +short MX hotmail.com
2 hotmail-com.olc.protection.outlook.com.

$ dig +short MX microsoft.com
10 microsoft-com.mail.protection.outlook.com.

Outlook.com consumer domains (outlook.com, hotmail.com, live.com, msn.com) resolve to hosts under olc.protection.outlook.com. Microsoft 365 organisations publish MX hosts ending in mail.protection.outlook.com or mx.microsoft, as described in Microsoft's SMTP DANE documentation.

Step 1: find out who controls the IP

Take the IP from the brackets and look up its reverse DNS name: 

$ dig +short -x 203.0.113.10
mail.example.net.
  • It is your own mail server. You fix the cause and you file the request.
  • It belongs to your ESP, hosting company or a shared relay. Open a ticket with that provider and include the full bounce. The provider controls the IP and what else is sent from it, so the cleanup and the mitigation request are theirs to make.
  • You do not recognise it. The message left through a hop nobody documented, such as a smarthost, a relay set up by another team, or an application server. Send a copy of the same message to a mailbox you control and follow the Received headers to find it.

The bounce says "part of their network": the wording allows for a block on the whole range as well as on your own address. If other senders share the IP or its range, their traffic counts against it too.

Step 2: remove what earned the block

Fix the cause before you ask for mitigation. Check the IP against the requirements on the Outlook.com postmaster policies page:

  1. Valid reverse DNS. "Email servers must have valid reverse DNS records." The dig -x lookup above must return a hostname.
  2. No dynamic IP space. Connections from dynamic IP space may not be accepted. A server on a residential or dynamic range needs to relay through a static, properly named host.
  3. No retries after 5xx. After a 500-599 response the sender must not retransmit that message to that recipient, and after multiple non-delivery responses it must stop sending to that recipient. Clear your queue of retries to Outlook.com addresses.
  4. Authentication for high-volume domains. Domains that send more than 5,000 messages a day to Outlook.com must pass SPF and DKIM and publish DMARC at p=none or stronger, aligned with SPF or DKIM. Check a sample message with the email header analyzer.
  5. No compromise. The postmaster troubleshooting page tells senders blocked for namespace mining to check that their machines and sending accounts are not compromised. Look for unknown mailboxes, new app passwords, forwarding rules, and web forms that accept arbitrary recipients.
  6. List hygiene. The unsubscribe mechanism must be clearly documented and easy to find. Remove addresses that bounce or complain.

Step 3: enrol the IP in SNDS and JMRP

Outlook.com offers two free programs, open to senders and ISPs, listed on the postmaster Services page:

  • SNDS (Smart Network Data Services, aka.ms/snds) shows how Outlook.com rates the mail from your IP space and how many users complained about it.
  • JMRP (Junk Email Reporting Program) returns the full message, with headers, of mail that Outlook.com users mark as junk or phishing. Microsoft says feedback can start in as little as 72 hours after enrolment.

SNDS gives you the data to judge whether your cleanup worked. JMRP gives you the complaining addresses to suppress. Enrol the IPs you operate. For a shared ESP IP, ask the provider what SNDS shows for it.

Step 4: file the Outlook.com delisting request

Read the postmaster FAQ first, as Microsoft's delist documentation asks. Then open the Outlook.com form at olcsupport.office.com; it asks you to sign in with a Microsoft account. Provide:

  • The IP address or addresses from the bounce.
  • The full bounce text, with the (S3150) code.
  • What caused the problem, if you found it, and what you changed.
  • That the IP has valid reverse DNS and that your domain passes SPF, DKIM and DMARC.

The postmaster FAQ states that submitting this information does not guarantee delivery of any message to Outlook.com users. In the Q&A thread about a company domain blocked with S3150, the request came back "Not qualified for mitigation" even after the sender had closed an account compromise. A Microsoft Q&A moderator (Microsoft external staff) replied that reputation-based blocks are not always removed immediately and that the automated review can require further monitoring before mitigation is granted. Keep sending only clean mail from the IP and keep watching SNDS.

What DMARC reports can and cannot tell you here

DMARC aggregate reports do not record IP block-list rejections, so an S3150 bounce will not appear in them. They list, per reporting receiver, every source IP that sent mail using your domain in the From header, with the SPF and DKIM result for each. That is the inventory Step 1 needs: an IP you do not recognise, sending as your domain, is where abused forms and compromised relays show up. The DMARCTrust DMARC reports view turns the daily XML into a per-source breakdown.

Was this page helpful? Send us feedback

Last updated: October 2026

← All guides Start now

Need expert help with email deliverability?

Hire an email deliverability consultant who has shipped billions of emails. Free assessment, hands-on engagement, written quote before any work starts.

Talk to a consultant