Outlook 550 5.7.1 S3150 block-list rejection

What S3150 proves

A reply containing 550 5.7.1, wording that the sender's network is on a block list, and marker S3150 is a permanent rejection for that SMTP attempt. Microsoft's published support guidance describes it as a block on the public outbound sending IP used by the mail service.

Proved

The IP that connected to the Microsoft consumer-mail edge was rejected for this attempt.

Not proved

S3150 alone does not show that SPF, DKIM, DMARC, message content, or the recipient address caused the rejection.

Queue stance

A 550 reply is permanent for the attempt. Repeating the same route unchanged is not a repair.

Ownership boundary

A shared relay provider controls its outbound pool; a dedicated-IP sender controls its own reputation and delisting work.

Preserve the minimum evidence packet

1. Keep the complete SMTP diagnostic, remote Microsoft MX hostname, UTC time, three-digit and enhanced codes, S3150 marker, and the bracketed outbound IP.
2. Record the sending provider, route, provider message ID, visible From domain, envelope domain, and whether the IP is dedicated or shared.
3. Retain the NDR from the return mailbox or provider event stream. Redact the recipient and message content before sharing it publicly.
4. Compare one controlled Microsoft attempt with one accepted recipient domain without changing multiple variables at once.

Why API success or provider 250 can still end in S3150

An application can return HTTP 200, a queue can complete, and an upstream SMTP provider can accept a submission with 250 before that provider attempts final delivery. Microsoft may then reject the provider's outbound connection with 550 5.7.1 S3150. The later NDR is authoritative for the final attempt.

A failover that watches only the synchronous submission response cannot see this sequence. Treat asynchronous bounce ingestion as a separate delivery boundary: correlate NDRs to the original message, mark the attempt permanently failed, and route any controlled recovery through an explicitly approved path rather than silently resending.

Choose the response by IP ownership

Shared provider IP

Open a provider case with the complete NDR, both timestamps, and all affected outbound IPs. The provider owns pool hygiene, compromise response, reputation, and any Microsoft delisting request. Checking public DNS can reveal adjacent configuration problems, but changing your From-domain DNS cannot directly remove a provider-owned IP from Microsoft's private block list.

Dedicated or self-hosted IP

Stop bulk retries, check for account compromise and unexpected volume, review complaints and bounce patterns, verify PTR and forward DNS, then use Microsoft's sender reputation and delisting channels. A successful form submission is not proof of restored delivery; verify with one new controlled message after the route is ready.

Verify authentication without mislabeling the cause

SPF, DKIM, DMARC alignment, PTR, consent, volume, and complaint controls still matter for reliable delivery. Audit them against the actual production route, but keep the findings separate: S3150 names an IP block, while an authentication failure requires its own receiver or message evidence.

• Use the exact outbound IP from the NDR for PTR and forward-confirmation checks.
• Use the real envelope domain for SPF and the real d=/s= values for DKIM.
• Compare the visible From domain with a passing SPF or DKIM identity before claiming DMARC alignment.
• Do not assume a clean public block-list lookup contradicts Microsoft's private S3150 verdict.

Controlled recovery

1. Resolve the provider or IP-ownership action first.
2. Invalidate superseded verification codes according to the product's security model.
3. Send one fresh test through the intended production route to a controlled Outlook or Hotmail mailbox.
4. Require receiver acceptance and inbox evidence before restoring normal volume.
5. Keep bounce-aware monitoring active so a later asynchronous NDR cannot remain a false success.