Field troubleshooting note · published May 2026

Microsoft Outlook/Hotmail Policy Rejects — A 2026 Troubleshooting Guide

Microsoft consumer mail — Outlook.com, Hotmail.com, Live.com, MSN.com — remains the hardest of the major mailbox providers to diagnose when delivery breaks. Public reputation signals contradict private filtering decisions, SmartScreen applies opaque internal scores, and the May 2025 high-volume sender enforcement added a new family of rejection codes that older troubleshooting guides do not cover. This is the operational playbook we use when a managed-infrastructure client reports a Microsoft policy reject — the decoding tree, the right action for each code family, the SNDS workflow including the May 2026 portal migration, and the delisting paths that actually work versus the ones that look like they should.

01
Why Microsoft is the hardest case in 2026

Three structural facts about Microsoft consumer mail in 2026 explain why the same authentication setup that works at Gmail and Yahoo can still fail at Outlook.com.

1. Two filtering layers, one of which is invisible to you

Microsoft applies both connection-layer filtering (IP reputation, RBL checks, throttle decisions) and content-layer filtering via SmartScreen (the same engine that powers Microsoft Defender for Office 365). SNDS exposes the first layer. SmartScreen is opaque — even if your IPs look clean on SNDS, JMRP, and public RBLs, Outlook uses its own internal reputation system. A "green" SNDS dashboard does not mean your mail is reaching the inbox.

2. The May 2025 enforcement changed the rules for high-volume senders

On 5 May 2025 Microsoft began enforcing strict authentication for any domain sending 5,000 or more messages per day to its consumer services. Outlook began routing messages from high-volume non-compliant domains to the Junk folder, giving senders an opportunity to address any outstanding issues, and warned that future enforcement would reject those messages outright. Through 2026, that future has arrived: SPF + DKIM + DMARC alignment failures now return 550 5.7.515 Access denied directly at the connection.

3. SmartScreen, throttle and block decisions are made at IP, subnet, domain and tenant level simultaneously

You can be clean at the IP level and blocked at the subnet level. You can pass SPF and DKIM at the message level and still trigger SmartScreen content scoring. All of this is managed by a mixture of automated scoring systems and protections that can act at the IP, domain, tenant or envelope-from level. The result is a complex decision surface that can deliver contradictory signals: public tools like SNDS may show no obvious issue even as recipient-side frontends apply internal mitigations or listings.

02
The complete 5.7.x rejection catalogue

The full set of codes you may see when sending to Microsoft consumer addresses, what each one signals, and the right first action. Sections 3–7 expand the most common four into their own runbooks.

03
550 5.7.515 — the May 2025 enforcement code

This is the most-asked-about Microsoft code in 2026 because it was new in May 2025 and now affects every sender above 5,000 daily messages.

What the bounce looks like

550 5.7.515 Access denied, sending domain [yourdomain.com]
does not meet the required authentication level.

What it actually means

Error 550 5.7.515 for Outlook.com/Hotmail indicates that the domain in the 5322.From address does not meet the required authentication level for sending to Microsoft consumer email services, and the message is therefore rejected. The trigger is a hard threshold: 5,000+ messages per day from the same 5322.From domain to Microsoft consumer addresses. Once triggered, every message from that domain must pass:

• SPF — the sending IP must be in the SPF record of the 5321.MailFrom domain (envelope sender)
• DKIM — the message must carry a valid DKIM signature aligned to the 5322.From domain
• DMARC — the domain must publish a DMARC record (at least p=none), and either SPF or DKIM must align to the 5322.From domain

The most common failure mode is alignment, not authentication itself. A message can pass SPF and DKIM individually and still fail DMARC because neither aligns to the From address. This is especially common when sending through third-party platforms (ESPs, transactional providers, ticket systems) that sign messages with their own domain.

Decision tree for fixing it

04
550 5.7.1 S3140 / S3150 — IP block and throttle

These are the two oldest and most widely seen Microsoft block codes. S3140 means full block; S3150 means throttle. Both come from connection-layer filtering, both require submission of a delisting request, but the underlying causes differ.

What the bounces look like

# S3140 — full block
550 5.7.1 Unfortunately, messages from [1.2.3.4] 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 https://sender.office.com/

# S3150 — throttling
550 5.7.1 Unfortunately, messages from [1.2.3.4] weren't sent.
Please contact your Internet service provider since part of their
network is on our block list (S3150).

S3140 root causes (full block)

S3140 means that your IP address has been fully blocked by Microsoft, and no emails from that IP will be delivered to any of their platforms. This could be due to a violation of one or more of their policies, such as sending spam or malicious emails. In our incident history, the top three triggers are:

• Spam-trap hit — sending to a recycled or honeypot address Microsoft monitors. One trap hit can trigger S3140 on a new IP.
• Sudden volume spike — an IP that was sending 1,000/day jumping to 50,000/day without warming. Microsoft treats this as an account compromise pattern.
• Complaint cluster — multiple complaints within minutes from a single campaign. Microsoft’s SmartScreen flags the IP even if the rolling rate is below threshold.

S3150 root causes (throttled)

S3150 is recoverable without a delisting request if you change behaviour quickly. S3150 indicates that your IP address has been throttled, which means that emails from that IP are being delivered at a reduced rate. This could be due to factors such as low engagement rates or high spam complaints. Typical triggers:

• Low engagement — sending to a high proportion of inactive addresses. Microsoft assumes inactive = unwanted.
• Reverse DNS / PTR mismatch — common on freshly provisioned IPs where the PTR has not been set or does not match the HELO domain.
• Authentication soft-fail — SPF with ~all instead of -all, or DKIM signature on a domain not aligned to From.
• List quality drift — a previously clean list that has aged into inactive territory without re-engagement campaigns.

The runbook order

For both S3140 and S3150, the diagnostic order matters. Submitting a delisting request before you have fixed the underlying cause is the most common reason a delisting request gets refused.

05
550 5.7.511 — banned sender

5.7.511 sits one step above S3140 in severity. Where S3140 is the algorithmic block, 5.7.511 is the deliberate ban — an IP that Microsoft’s human or automated review has classified as a deliberate bad actor.

What the bounce looks like

550 5.7.511 Access denied, banned sender [1.2.3.4].
To request removal from this list, forward this message to
delist@messaging.microsoft.com. For more information, go to
https://go.microsoft.com/fwlink/?LinkId=526653.

What it actually means

The IP has accumulated reputation damage that pushed it beyond the automated mitigation threshold and into the banned-sender list. Common paths to 5.7.511 in our incident history:

• Compromised account — an account on the IP was hijacked and used to send phishing or bulk spam.
• Sustained spam-trap hits — multiple traps over a period of weeks, not a single incident.
• Repeated S3140 cycles — an IP that was S3140-listed, delisted, re-listed, delisted, re-listed. After roughly the third cycle it tends to graduate to 5.7.511.
• Network-level reputation issue — the IP’s /24 subnet has multiple banned IPs and Microsoft has applied subnet-level enforcement.

The 5.7.511 delisting path

Unlike S3140 where the form at sender.office.com usually suffices, 5.7.511 requires an email to delist@messaging.microsoft.com with substantial evidence of corrective action. The reply window is typically 3–10 business days; the success rate is materially lower than for S3140 because Microsoft’s position is that a banned-sender classification was deliberate.

The delisting request that gets results includes: a written description of what changed (the configuration audit, the list hygiene work, the engagement filtering), screenshots of SNDS showing the IP is now clean, evidence of authentication passing (test send headers), and the volume profile you intend to maintain after delisting. A short request with “please delist” almost always receives the templated “not qualified for mitigation” reply.

06
5.7.703 / 705 / 708 / 750 — organisation policy

This code family is recipient-side. The receiving organisation — usually a Microsoft 365 tenant administered by an IT team, not a consumer Outlook.com user — has configured a mail flow rule that rejects your message. The sender cannot fix these from the sending side.

What the sender can usefully do

Three steps that move the situation forward:

1. Confirm you are not on a public RBL — if you are, the tenant is correctly rejecting you; fix that first.
2. Contact the recipient through a different channel — phone or a message via another medium — and ask them to forward the rejection to their IT/messaging team.
3. Provide your sending IP, domain, and the full NDR text. Tenant admins running Exchange Online can use Get-MessageTrackingLog to see why the message was blocked and adjust their mail flow rule.

For TRANSPORT.RULES.RejectMessage errors specifically, the recipient can execute ‘Get-MessageTrackingLog’ in the Exchange Management Shell to check why the message was rejected. This is the diagnostic path that gets the fastest answer.

07
451 4.7.x — soft throttling, not a bounce

4.x.x codes are not bounces. They are deferrals — the receiving server is asking you to retry later. Treating a 4.x as a hard failure is one of the most common operational mistakes we see; it inflates apparent bounce rates, removes deliverable addresses from your list, and signals to your MTA that a perfectly recoverable situation is permanent.

Common 4.7.x variants from Microsoft

The retry pressure trap

Aggressive retry behaviour on 4.x codes can convert a temporary throttle into a permanent block. If your MTA retries every 60 seconds against a server that is asking you to slow down, the next response is often a hard 5xx. Set retry intervals to exponential backoff: 5min, 15min, 1h, 4h, then mark as failed after 24h. This is what we configure by default on PowerMTA installations we manage; see our note on retry pressure as the silent killer of SMTP reputation at scale for the full operational pattern.

08
SNDS and the May 2026 migration

Smart Network Data Services is Microsoft’s public sender dashboard for Outlook.com / Hotmail / Live / MSN. It shows complaint rate, trap hits, filter results and authentication status for every IP you control. Until 2026 it ran at sendersupport.olc.protection.outlook.com; a major service update in May 2026 changed both the URL and the data model.

What changed in May 2026

In May 2026, SNDS will move to a new URL as part of a service update. The current site at sendersupport.olc.protection.outlook.com will be deprecated. The migration introduces four operational changes that affect any tooling that integrates with SNDS:

• IP Status and IP Data are now REST APIs, not HTML pages or email links. Existing scrapers will break.
• Authentication is the same Microsoft login used for the SNDS portal — you do not need a separate API credential, but you do need to plumb that login into your tooling.
• Calculation methodology has been updated. Historical values are not directly comparable to the new ones; the published columns themselves have changed.
• Automated report links expire after 30 days instead of the previous indefinite retention. Long-lived dashboards must refresh the report URLs periodically.
• JMRP feeds not linked to an SNDS account will be removed post-migration. You must re-create them under the SNDS account after migration.

What to read in the SNDS dashboard

09
The delisting workflow that works

Microsoft maintains two delisting paths and most senders use the wrong one for their situation. Picking the right path gets you results in 24–48 hours; picking the wrong one wastes a week.

The delisting form that gets results

The sender.office.com form has a free-text field for “corrective actions taken”. Most senders write one line. The requests that get approved write several specific things:

• The exact root cause identified (compromised account, list import error, authentication misconfiguration)
• The specific action taken (account password reset, list removed, DNS records corrected)
• Authentication status now (SPF / DKIM / DMARC all passing — with the test send headers as evidence)
• Current SNDS state (Green, complaint rate below 0.1%, zero trap hits over last 14 days)
• Volume profile going forward (e.g. “sending 8,000/day to engaged 30-day actives, no list growth from purchased data”)

If you cannot make all five statements truthfully, do not submit the delisting request yet. Submitting prematurely and being refused puts your IP into a queue that takes longer to re-process the second time.

10
SmartScreen and the “green SNDS but blocked” puzzle

The most frustrating pattern in Microsoft troubleshooting is the “everything is clean but mail is in spam” case. SNDS is green, JMRP shows no complaints, authentication passes, no block code appears in NDRs — and Outlook.com users still report your mail going to junk.

What SmartScreen is doing

SmartScreen is the content-classification engine that scores every accepted message after the connection-layer filters pass. It uses sender reputation as one input but combines it with content signals (URL patterns, subject-line analysis, body structure, image:text ratio, encoded MIME parts), behavioural signals (cross-tenant engagement patterns), and user-feedback signals that are not exposed through JMRP.

Two consequences for troubleshooting:

1. You can pass every public check and still be filtered. SmartScreen has data you cannot see.
2. Content matters as much as reputation when the rest of your sending is clean. The same campaign body that worked for years can suddenly trip SmartScreen after a content classifier update.

The SmartScreen diagnostic checklist

When all eight checks pass and inbox placement is still degraded, the next step is segmentation: send the same content to two segments (engaged opens-in-30-days vs broader list) and compare placement. If the engaged segment lands inbox and the broader one does not, the issue is recipient-side reputation not content. If both go to junk, the issue is content or domain reputation.

11
What does not get you delisted

Four common requests that do not work, and what to do instead.

Myth 1: “Wait it out and the block will clear”

Microsoft blocks do not time out on their own at the IP level. S3140 will persist until you submit a delisting request and the underlying behaviour has changed. S3150 throttling sometimes lifts after sustained good behaviour but the recovery time is measured in weeks, not days.

Myth 2: “Sending more to recover reputation”

This is the most damaging response. After a block, the instinct is often to “prove” the IP by sending more legitimate mail. Microsoft reads volume increases after a block as evidence of evasion. Reduce volume to engaged-only after a block, not more.

Myth 3: “Submitting from multiple IPs to look diverse”

Rotating sends across multiple IPs to escape a block is interpreted as snowshoe spam pattern. The block extends to the other IPs in your pool. Concentrate on a single IP, fix it, then resume normal multi-IP operation.

Myth 4: “Pay for a higher-tier ESP”

This works only if the ESP gives you a dedicated IP and the dedicated IP is clean. Premium plans on shared-pool ESPs share the same pool as their other premium customers; one bad sender ruins the pool. Their shared IPs, used by countless users, are a liability. If one user sends to a spam trap or racks up complaints, the entire IP pool’s reputation tanks, triggering Microsoft’s blacklist. Dedicated infrastructure is the structural answer.

12
Defensive architecture — how to not arrive here

Most Microsoft blocks are preventable. Five architectural decisions, applied before the first send, dramatically reduce the likelihood of ever needing to use this troubleshooting guide.

1. Dedicated IPs with explicit warming

Shared IP pools are the single largest source of Microsoft delivery problems in our incident history. A dedicated IP, warmed deliberately over 6–8 weeks, isolates you from other senders’ reputation damage. See our IP warming service for the protocol we apply.

2. Separate IP pools per email stream

Transactional, marketing, and any cold-outreach streams must not share IPs. The complaint-rate profile of each stream is structurally different; sharing infrastructure means one stream’s problems become every stream’s problems. The transactional pool, in particular, must stay isolated — a marketing stumble cannot be allowed to block password resets and 2FA.

3. SPF, DKIM and DMARC at p=quarantine minimum from day one

The May 2025 enforcement codified what was already best practice. Publishing DMARC at p=quarantine (or p=reject) with proper alignment configured before scaling sends is cheaper than fixing it after a 5.7.515 block. The mechanics are in our DMARC managed service.

4. PTR records and HELO alignment

Reverse DNS that matches the HELO domain is a Microsoft prerequisite for clean reputation. On managed infrastructure we set this at IP provisioning; on self-hosted setups it is the most commonly missed configuration. Verify with dig -x <ip> and compare against your HELO.

5. Continuous SNDS monitoring with alerting

SNDS exists. JMRP is free. The combination tells you about a problem hours or days before it becomes a Microsoft block. The reason most senders only discover a problem when bounces start arriving is that nobody is reading SNDS daily. We poll SNDS via the new REST API for every managed client and alert on red status, complaint rate above 0.1%, or any trap hit.

Related operational notes

• Email Marketing Benchmarks 2026 — the deliverability thresholds that gate inbox placement across all major providers
• Postmaster Tools v2 — Six Months In — how Gmail’s sender dashboard changed and what to monitor
• DMARC at p=reject — One Year After the Mandate — the operational realities of moving to enforce-strict DMARC
• Retry Pressure — The Silent Killer of SMTP Reputation — why aggressive 4.x retries make 5.x blocks more likely
• Complaint Rate Spikes — Tracing the Source — segment-by-segment isolation when JMRP shows a spike
• Q1 2026 Permanent Rejections — Field Data — the cross-provider rejection-code distribution we logged in Q1