S3140 and S3150 Microsoft SMTP Errors Explained

When Outlook.com bounces a message with 550 5.7.1, the parenthetical at the end of the response is the actual diagnosis. The two codes you'll see most often are S3140 and S3150. They look similar but tell you different things — and the fix is not the same.

S3140 — Pure Reputation Block

550 5.7.1 ... part of their network is on our block list (S3140).

S3140 means the IP itself has crossed Microsoft's internal reputation threshold. The triggers are almost always:

• High complaint rate (Outlook.com users clicking "report junk").
• Spam-trap hits — old, recycled, or pristine traps in Microsoft's seed network.
• Sudden volume spike that doesn't match historical behaviour.
• Listing on Spamhaus PBL/XBL or another DNSBL Microsoft consumes.

What S3140 does not necessarily mean: your authentication is broken. SPF/DKIM/DMARC can be perfect and you can still earn an S3140 if your engaged-user metrics are bad enough.

Fix path: SNDS enrollment → JMRP enrollment → submit sender.office.com delisting form → fix the underlying complaint or trap issue. Full walkthrough in 550 5.7.1 Microsoft Error Fix.

S3150 — Reputation + Authentication/Content

550 5.7.1 ... (S3150).

S3150 is "S3140 with extra problems." Microsoft saw reputation issues and one or more of:

• SPF hardfail or softfail with DMARC alignment failure.
• DKIM signature broken, missing, or domain mismatch.
• DMARC policy of p=none on a domain Microsoft expects to be enforced (especially after the 2024 bulk-sender rules).
• Content signals — heavy URL shorteners, image-only HTML, suspicious link patterns.

S3150 is harder to clear because Microsoft will often refuse to delist until they re-validate that the next batch of mail passes authentication cleanly.

Fix path:

1. Run the sending domain through Domain Health and confirm SPF, DKIM, DMARC are green and aligned.
2. Generate a clean DMARC record with the DMARC Generator — at minimum p=quarantine.
3. Review one of your sent messages in the Email Headers Analyzer — every Authentication-Results line should pass.
4. Only then submit the delisting form. Mention in the notes that authentication has been fixed and link to the public domain so Microsoft can verify.

S3115 — Third-Party Blocklist Reflected

You'll occasionally see S3115. This means Microsoft's filter is mirroring a third-party DNSBL listing (most commonly Spamhaus). Microsoft will not delist S3115 — you must delist from the upstream blocklist first, and S3115 falls off automatically within hours.

Check upstream listings with Blacklist Checker.

Side-by-Side Summary

Code	Root cause	First action	Delisting URL
S3140	IP reputation, complaints, traps	Enroll in SNDS/JMRP, then delist	sender.office.com
S3150	Reputation + auth/content failing	Fix SPF/DKIM/DMARC, then delist	sender.office.com
S3115	Upstream DNSBL listing	Delist from Spamhaus / DNSBL	Upstream blocklist

What Not to Do

• Don't submit a delisting form before fixing root cause. Microsoft tracks resubmissions and the second request gets a human reviewer who looks for evidence of change.
• Don't rotate to a fresh IP without warming it. A clean IP sending production volume cold triggers a faster S3140 than the one you just delisted.
• Don't ignore SNDS. If your IP is yellow or red there, the delisting form will almost certainly be denied.

FAQ

Is S3140 permanent? No. Microsoft's reputation engine forgets quickly when sending behaviour improves. Most IPs that get delisted and then send clean for 7–14 days stay green.

Can I see S3140/S3150 before I get blocked? Yes — SNDS shows IPs trending yellow before they go red. That's why enrolling on day one matters.

Why do I see different codes from different Microsoft endpoints? Outlook.com / Hotmail use one filter stack; Microsoft 365 (Exchange Online) uses EOP with different codes like 5.7.708. They're related but graded independently.

Related

• 550 5.7.1 Microsoft Error — Full Fix Guide
• Microsoft Outlook Delisting Walkthrough