Is the Microsoft outage resurfacing again?
Published 5 Mar 2026
Updated 21 Oct 2026
14 min read
Summarize with
Updated on 21 Oct 2026: We clarified Microsoft S3150 troubleshooting and support routes, including the separate 550 5.7.515 authentication error.
If the symptom is 550 5.7.1 with an S3150 reference, do not classify it as a Microsoft outage by itself. Investigate a sending-IP block affecting Outlook.com consumer recipients, including Hotmail, Live, and MSN. The error text says part of the sending network is on Microsoft's block list. It does not establish a general Microsoft 365 outage or explain why the IP was blocked.
That distinction matters because the responses are different. A Microsoft 365 outage calls for incident monitoring and standards-based retries for temporary 4xx responses. A Microsoft blocklist (blacklist) recurrence requires evidence collection, containment, remediation, and the correct delisting route. Compare official status signals against bounce logs, outbound IPs, recipient domains, authentication results, complaint timing, and delivery rates.
Microsoft's January 22-23, 2026 incident, MO1221364, was resolved after capacity and load-balancing work. Reports included intermittent mail flow and temporary 451 4.3.2 responses. A new 550 5.7.1 S3150 response has a different failure pattern and does not show that incident has resumed.
Short answer
- Answer: S3150 bounces point to Microsoft rejecting a sending IP or network, not to a general Microsoft 365 outage.
- Check: Confirm whether Microsoft has an active incident before changing sending infrastructure.
- Contain: Stop automatic retries of the permanent 5xx failure and slow new Microsoft-bound traffic on affected IPs.
- Escalate: Follow the NDR instructions and submit exact bounces, IPs, time windows, and authentication evidence.
Common Microsoft S3150 rejection
550 5.7.1 Unfortunately, messages from [IP] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150).
How to tell an outage from an S3150 block
Start with Microsoft's status evidence, then compare it with the affected mail stream. For business recipients, check Health > Service health in the tenant's Microsoft 365 admin center. Also check public service health, and public status posts. Public status posts cover selected incidents and do not replace the tenant's service health details. A clear public status page does not rule out a new or localized incident. If mail flow fails broadly, report it through the admin center and preserve logs while Microsoft investigates. Repeated S3150 bounces still require an IP-block investigation. Temporary 4xx responses also occur during reputation-based rate limiting, so a 4xx code alone does not establish an outage.
Illustrative Microsoft 365 service health screen for checking Exchange Online incidents.
Broad Microsoft incident
- Scope: Many tenants, regions, or Microsoft services show matching access or mail-flow issues.
- Evidence: Microsoft status channels show a matching incident or advisory; temporary SMTP errors support the investigation but do not prove an outage.
- Action: Preserve logs, honor 4xx retry intervals, and follow Microsoft recovery updates.
- Risk: Changing DNS or IP routing during a true outage can create a second problem.
S3150 blocklist recurrence
- Scope: Specific outbound IPs or pools fail while other Microsoft-bound traffic still lands.
- Evidence: Bounces repeat the Microsoft block list wording and the 550 5.7.1 S3150 reference.
- Action: Segment by IP, stop retrying rejected messages, remediate the cause, and request delisting.
- Risk: Automatic retries after a permanent rejection waste queue capacity and keep sending into the same block.
|
|
|
|---|---|---|
Status | Matching incident | No matching incident required |
SMTP code | Often 4xx, such as 451 4.3.2 | 550 5.7.1 S3150 |
IP scope | Many paths | Specific IP or range |
Response | Follow incident updates | Remediate and delist |
Fast classification signals
What Microsoft S3150 means
The 550 5.7.1 status alone is broad. Permissions, connector settings, authentication failures, and recipient security policies can produce other 5.7.1 non-delivery reports (NDRs). The S3150 marker and the sentence saying part of the network is on Microsoft's block list identify this case as a permanent SMTP rejection tied to the source IP or network. This is a hard bounce for that delivery attempt, even if a sending platform labels it a soft bounce. It does not mean the recipient address is invalid, so record the policy block separately from invalid-address suppressions.
Treat this as a blocklist (blacklist) case first. Check whether the affected IP appears in your blocklist monitoring, then compare Microsoft bounces against other mailbox providers. A clean result on public lists does not clear Microsoft's internal reputation decision. If only Microsoft domains fail, the sending identity still needs review, but the escalation target is clearer.
How to classify Microsoft SMTP responses
Classify the SMTP response and compare affected routes; these categories are not published Microsoft thresholds.
Temporary failure
4xx only
Queue and retry according to the SMTP response; investigate persistent deferrals.
Deferral wave
Mixed 4xx
Temporary rate limiting can reflect sender reputation; it is not proof of an outage.
IP block
S3150
A specific outbound IP repeats the block list wording.
Possible range issue
Network
Several affected IPs suggest a wider scope; the bounce alone does not identify a blocked subnet.
Confirm the pattern
One S3150 bounce confirms that delivery attempt was rejected. Compare samples across timestamps, IPs, and recipient domains to establish the scope, but do not delay escalation while waiting for more failures. If rejection happens before message content is accepted, Microsoft's DKIM and DMARC results are unavailable. Label authentication evidence from a separate delivered test as such.
Illustrative delivery evidence log
timestamp_utc,recipient_domain,outbound_ip,smtp_result,queue_id,receiver_authentication 2026-02-15T03:10:00Z,outlook.com,203.0.113.10,550 5.7.1 S3150,a1b2c3,unavailable 2026-02-15T03:12:00Z,hotmail.com,203.0.113.10,550 5.7.1 S3150,d4e5f6,unavailable 2026-02-15T03:14:00Z,live.com,203.0.113.11,250 accepted,g7h8i9,check_delivered_headers
Triage steps for Microsoft S3150 errors
The first hour matters. Avoid broad DNS edits, template rewrites, and emergency IP swaps until the failure pattern is clear. Fast triage should prove whether the issue is Microsoft-wide, IP-specific, recipient-domain-specific, or tied to a recent traffic change. Because S3150 is a permanent 5xx response, remove the rejected messages from automatic retries rather than treating them like temporary 4xx deferrals.
Microsoft S3150 troubleshooting flowchart: check status, match bounces, segment IPs, protect traffic, and escalate.
- Status: Check Microsoft status channels first, then record the exact time and incident identifier if one exists.
- Bounces: Group failures by recipient domain, outbound IP, complete SMTP response, campaign, and message stream.
- Authentication: Run a domain health check and verify SPF, DKIM, DMARC, reverse DNS (rDNS/PTR), and HELO/EHLO. Confirm that the sending IP has a valid PTR hostname and that hostname resolves back to the IP.
- Message test: Send a representative sample through an email tester to catch header, content, and authentication errors.
- Traffic: Check whether transactional mail and marketing mail share the affected reputation pool. Plan separate streams instead of moving urgent traffic to an untested IP during the incident.
- Volume: Slow new Microsoft-bound traffic on affected IPs and watch whether blocks clear, worsen, or move to nearby IPs.
- Case: Follow the NDR's route and include the full SMTP transcript, affected IP, sending domain, UTC timestamps, and authentication results.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A clean test does not prove Microsoft will accept the next message or remove the IP. It helps identify configuration gaps before escalation. Record the actual outbound IP, since shared hosting or network address translation can make it different from the server's local IP. If a provider owns the shared IP, ask it to investigate other traffic in that pool.
How to submit the correct delisting request
Microsoft uses different support routes for consumer Outlook.com destinations and Microsoft 365 business recipients. The complete NDR is the routing instruction. Do not assume that a form which accepts an IP covers every S3150 rejection, and do not submit an IP you do not control.
|
|
|
|---|---|---|
Outlook.com consumer mailboxes | 550 5.7.1 S3150 | Use Outlook.com sender support. The Microsoft 365 IP delist process does not establish this IP's consumer-service status. |
Microsoft 365 business mailboxes | 550 5.7.606 through 5.7.649 | Follow the IP delist instructions in the NDR, including email verification and the final Delist IP action. |
Microsoft 365 business mailboxes | 550 5.7.511 | Follow the NDR instruction to contact delist@microsoft.com; the self-service IP delist process does not handle this code. |
One Microsoft 365 organization | Recipient tenant policy block | Ask the recipient administrator to investigate the tenant policy; a global delist does not remove a tenant-specific block. |
Match the recipient service and complete NDR to the support route.
- Preserve the NDR: Save the complete rejection, source IP, recipient domain, sending domain, queue ID, and UTC timestamp.
- Stop permanent retries: Do not retransmit a message to the same recipient after the 550 response. Investigate before sending new mail.
- Follow the named route: Use the Microsoft delist or sender-support route stated in the NDR for the affected recipient service.
- Confirm IP ownership: If a hosting provider or email service controls the shared IP, send the evidence to that provider so it can investigate and file the request.
- Complete verification: When Microsoft sends a confirmation message, open its link and complete the delist action. A form submission alone is not always the final step.
- Use email only when directed: If the NDR explicitly says to forward it to delist@microsoft.com, include the full NDR and blocked IP.
- Resume carefully: After Microsoft confirms mitigation, send a small controlled test and check SMTP acceptance before increasing volume. Track S3150 by IP and recipient domain, and confirm inbox or junk placement separately.
A 'not blocked' response from the wrong Microsoft service does not clear an S3150 case. If current rejections continue after a support response, reply to the existing case with a fresh full NDR and UTC timestamp. Recheck the actual outbound IP and request further review; do not keep submitting the same evidence to unrelated support routes.
Delisting does not repair reputation
A successful delist removes the current block. Before restoring normal volume, find the condition that caused it. Review consent records, recent complaints, invalid recipients, traffic spikes, rDNS and HELO, plus SPF, DKIM, and DMARC. The same IP can be blocked again if the underlying sending pattern continues. A false positive or another sender on a shared IP also warrants investigation; the rejection alone does not prove your domain caused the block.
Distinguish S3150 from 550 5.7.515 authentication errors
Microsoft's support guidance identifies 550 5.7.515 as an authentication rejection for high-volume senders to Outlook.com consumer mailboxes. It is a different diagnosis from an S3150 IP block. Enforcement began on May 5, 2025, so treat these requirements as active.
- For domains sending 5,000 or more messages per day to Microsoft consumer services, both SPF and DKIM must pass.
- Publish a valid DMARC record with p=none or a stricter policy. DMARC must pass through SPF or DKIM with the required domain alignment to the visible From address.
Inspect message authentication results for each sending service. A DMARC pass through SPF does not excuse a DKIM failure under these requirements. Fix the failed authentication for 5.7.515; continue the IP-block investigation for S3150. Keep an existing quarantine or reject policy when it is correctly configured.
Why authenticated senders can still be blocked
Passing SPF, DKIM, and DMARC proves authorization and alignment. It does not guarantee acceptance. Microsoft's published guidance says filtering also considers sending IP reputation, domain reputation, list accuracy, complaint rates, and content. A new IP has little reputation and often needs a controlled warm-up before delivery stabilizes.
One blocked IP inside a load-balanced pool can make the issue look random. Each IP can have a different complaint profile, recipient mix, retry history, neighboring-network reputation, or volume pattern. Segmenting bounce and complaint data by outbound IP is more useful than relying on a pool-wide average.
Illustrative complaint timing
03:00 100 messages sent from 203.0.113.10 03:05 3 older messages marked as junk by Microsoft users 03:10 New mail from 203.0.113.10 starts receiving S3150 The complaints concern older sends, not necessarily the 100 new messages. Do not calculate a complaint rate from these unmatched counts.
This sequence does not establish causation or reveal Microsoft's internal threshold. Complaints can arrive long after delivery, so dividing complaints about older mail by new sends does not produce a valid complaint rate. Match complaints to the relevant messages and reporting definition, then compare timing by outbound IP.
Common mistake
Do not rely on global averages as proof that every route is healthy. Inspect the blocked IP and message stream separately, using consistent complaint-rate definitions. A low overall complaint rate does not rule out a Microsoft blocklist decision.
How Suped supports an S3150 investigation
Suped is our DMARC and email authentication platform. For an S3150 investigation, it brings DMARC monitoring, SPF and DKIM checks, blocklist monitoring, alerts, and multi-domain review into one workflow. That helps separate an authentication fault or broader blacklist event from a Microsoft-only IP rejection.
Blocklist monitoring page showing domain and IP checks across blocklists with importance and status
Use Suped's authentication and blocklist evidence alongside bounce logs and complaint data when preparing Microsoft's delisting case. DMARC aggregate reports cover reporting receivers and are not a complete SMTP delivery log; they do not prove that every rejected message reached authentication checks. Compare the affected IPs with passing authentication evidence and public blacklist results.
- DMARC visibility: Compare sending sources and authentication alignment by domain before escalation.
- Blocklist evidence: Check whether the affected IP appears on a public blocklist.
- Alerts: Detect authentication or blocklist changes without waiting for a scheduled review.
- DNS checks: Validate SPF and DKIM configuration while keeping it separate from Microsoft's IP decision.
- Multi-domain review: Compare customer or business domains without merging their evidence into one average.
What to do when only Microsoft recipients are affected
When other mailbox providers accept normally but Outlook.com, Hotmail, Live, or MSN rejects with S3150, focus on Microsoft's consumer service. For Microsoft 365 business recipients, use the complete NDR to identify the rejection and support route. If only one business domain fails, involve its recipient administrator. The related playbooks for Microsoft domain blocks and a Microsoft bounce message are useful once the issue has narrowed to Microsoft recipients.
- Slow down: Reduce new Microsoft-bound volume on affected IPs and stop retrying permanent S3150 failures.
- Protect mail: Keep critical transactional mail separate from bulk streams that are generating complaints.
- Compare IPs: Check whether sibling IPs in the same pool are accepted, deferred, or blocked.
- Review lists: Suppress recent complainers, invalid addresses, unengaged recipients, and contacts without clear consent.
- Escalate cleanly: Use the route in the NDR and submit a concise case with timestamps, IPs, and full samples.
- Avoid churn: Do not rotate IPs blindly, change From domains, or weaken authentication under pressure.
Do not make the evidence worse
Blind IP rotation often turns one Microsoft block into several. If a new IP sends to the same recipients with the same complaint sources and volume pattern, the underlying problem moves with the traffic while the new IP has less reputation.
Views from the trenches
The dated community observations below describe individual sending experiences, not a verified current outage or a published Microsoft filtering policy. Treat a 550 S3150 response as permanent at the SMTP level even when a provider's report calls it a soft bounce.
Best practices
Record exact S3150 samples with IP, domain, timestamp, stream, and authentication result.
Separate transactional traffic from marketing traffic before testing new Microsoft routes.
Compare sibling IPs in the same pool before assuming the issue is content or DNS only.
Keep complaint timing data close to bounce logs so short-window spikes are visible.
Common pitfalls
Treating S3150 as proof of a broad outage delays sender-side evidence work early.
Using daily complaint averages alone can hide IP-specific failures in Microsoft delivery logs.
Rotating IPs without changing recipient risk can spread the Microsoft rejection pattern.
Ignoring partial delivery hides cases where one IP is blocked while other IPs still deliver.
Expert tips
Build the escalation around recurrence timing, affected IPs, and clean authentication proof.
Hold risky Microsoft segments while you validate whether the block follows an IP or pool.
Track temporary 4xx deferrals separately from permanent 550 S3150 blocks in delivery reports.
Watch data feed gaps carefully because zeroes can mean reporting pause, not zero impact.
Marketer view
Marketer from Email Geeks says S3150 started appearing as soft bounces and IP blocks for senders that had no earlier Microsoft delivery issues.
2026-02-13 - Email Geeks
Marketer view
Marketer from Email Geeks says Microsoft filtering appears less tolerant, so formerly acceptable sending patterns now need tighter control.
2026-02-14 - Email Geeks
