How to troubleshoot Microsoft email deliverability issues and analyze SNDS data?
Michael Ko
Co-founder & CEO, Suped
Published 26 Jul 2025
Updated 27 May 2026
7 min read
Summarize with
The direct answer: troubleshoot Microsoft email deliverability by combining SNDS data with real message headers, bounce logs, DMARC aggregate reports, engagement trends, and controlled inbox tests. SNDS helps you spot IP reputation problems, complaint spikes, trap signals, filtered traffic, and volume shifts, but it does not explain every Outlook.com, Hotmail, Microsoft 365, or Exchange Online Protection placement decision.
I treat SNDS as a starting signal, not a verdict. The fastest path is to send a controlled message, inspect SCL and BCL values in the headers, confirm SPF, DKIM, and DMARC domain match, compare SNDS by IP and date, then look at list quality and recent engagement. If you need a quick live check, run a message through an email tester and keep the raw headers with your investigation notes.
What SNDS can and cannot tell you
Microsoft Smart Network Data Services gives reputation and traffic data for IPs that send into Microsoft consumer mail infrastructure. The official SNDS FAQ is useful for understanding access and field definitions, but the interface still leaves gaps during real investigations.
A Microsoft SNDS style screen showing sender IP reputation, complaints, trap messages, and filter results.
|
|
|
|---|---|---|
Filter result | Microsoft filtered a share of traffic. | The exact mailbox rule or model reason. |
Complaint rate | Recipients reported mail as junk. | Which campaign or segment caused it. |
Trap hits | List acquisition or hygiene has risk. | The individual addresses involved. |
IP volume | Traffic changed for a sending IP. | Domain-level or tenant-level placement. |
SNDS fields are useful only when you connect them to headers and campaign logs.
Do not use a green SNDS row as proof that Microsoft placement is fine. SNDS can look clean while a specific sending domain, campaign stream, Microsoft 365 tenant, or recipient cohort still has junk placement.
Use this troubleshooting order
When Microsoft placement changes, I work in a fixed order so I do not chase noise. The goal is to separate authentication, reputation, list quality, and content symptoms before changing DNS or moving traffic.
- Collect evidence: Save raw message headers, bounce responses, campaign IDs, send times, IPs, domains, and audience segments.
- Check authentication: Confirm SPF, DKIM, and DMARC pass with the right domain match. A domain health check is useful before you blame reputation.
- Read headers: Look for SCL, BCL, authentication results, and Microsoft-specific verdict headers.
- Compare SNDS: Match red or yellow days to the exact IP, campaign volume, list source, and recipient mix.
- Review reputation: Check IP and domain reputation, including blocklist monitoring for blocklist and blacklist events.
- Test carefully: Use consistent seed addresses and real engaged contacts. A new seed mix can change results by itself.
The most useful single artifact is still the delivered message header. It tells you what Microsoft saw for authentication and spam confidence on that specific message.
Header fields to collecttext
Authentication-Results: spf=pass dkim=pass dmarc=pass X-Forefront-Antispam-Report: SCL:5; BCL:4; ... X-Microsoft-Antispam: BCL:4; PCL:0; ... Received-SPF: Pass (sender SPF authorized)
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
Read SCL and BCL before changing anything
SCL and BCL are not the whole decision, but they are often more actionable than an aggregate SNDS color. SCL is the spam confidence level. BCL is the bulk complaint level. If SCL is high, investigate spam-like content, complaints, acquisition source, and reputation. If BCL is high, Microsoft thinks the message behaves like bulk mail that recipients do not consistently want.
SCL reading guide
Use SCL as a message-level signal, then confirm against placement and campaign context.
Bypass
-1
Filtering was bypassed by policy or trusted handling.
Low risk
0-1
The message is usually treated as not spam.
Junk risk
5-6
The message often routes to junk or quarantine.
High spam
9
Microsoft has strong spam confidence.
If every authentication check passes but SCL is still high, do not keep tuning DNS. Move to engagement, list source, complaint risk, and send stream separation.
Why passing authentication still lands in spam
SPF, DKIM, and DMARC are entry requirements, not a placement guarantee. Microsoft can accept an authenticated message and still route it to junk because reputation, complaints, engagement, content, or past traffic patterns look weak. DMARC monitoring tells you whether legitimate sources are passing and whether unknown sources are abusing the domain, but it does not replace mailbox placement analysis.
Authentication passed
- SPF pass: The sending IP is authorized for the return-path domain.
- DKIM pass: The signed message survived transit without a breaking change.
- DMARC pass: The visible From domain has a valid SPF or DKIM domain match.
Placement still weak
- Complaints: Recipients are reporting or ignoring the mail at a damaging rate.
- Low engagement: The active audience is too small compared with total volume.
- Mixed streams: Prospecting, internal mail, and opt-in mail share reputation.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped, our DMARC and email authentication platform, helps here by joining authentication health, source identification, DMARC policy, SPF and DKIM issues, blocklist (blacklist) monitoring, and alerts in one workflow. That matters because Microsoft troubleshooting usually fails when these signals sit in separate places.
Analyze SNDS without overreacting
SNDS is most valuable when you compare it with your own send log. I want to know which IP, domain, campaign, audience segment, and message version caused the change. A red day without that mapping is only a prompt to investigate.
Flowchart for using SNDS data with IP mapping, headers, SCL, audience review, and stream fixes.
- One day: Treat a single red result as a trigger, not a conclusion.
- Several days: Look for a repeated IP, audience, template, or send-time pattern.
- Volume shift: Check whether a migration, new subdomain, or new segment changed traffic quality.
- Clean SNDS: Still inspect Microsoft headers if users report junk placement.
This is also where seed testing gets messy. Changing seed addresses every quarter is reasonable for coverage, but it weakens before-and-after comparisons. Microsoft and other mailbox providers make placement decisions at the user and cohort level, so two seed sets can disagree even when the real audience result has not changed.
Fix the causes Microsoft cares about
The fixes that move Microsoft placement are usually operational. Authentication cleanup matters, but after it passes, sender reputation depends on who receives the mail, how they react, and whether risky traffic is isolated.
- Tighten recipients: Suppress contacts with no recent clicks, replies, form fills, purchases, or site activity. Open-only contacts need stricter handling because opens are noisy.
- Protect streams: Put opt-in marketing, sales outreach, system mail, and employee tools on separate domains or infrastructure when one stream damages the rest.
- Reduce spikes: Avoid sudden volume jumps, especially after a platform migration, subdomain change, or reactivation campaign.
- Use complaints: Process Microsoft complaint feedback when available and suppress complainers immediately.
- Review blocks: Check IP and domain blocklist or blacklist events before assuming Microsoft alone is the issue.
DMARC staging record exampledns
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100; adkim=s; aspf=s
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
If you are warming a subdomain, keep the test honest. Send only the stream that belongs there, ramp gradually, and compare Microsoft outcomes against the same audience quality. A subdomain helps isolate reputation, but it does not erase weak engagement or poor list history.
Where Suped fits
For most teams, Suped is the best overall DMARC platform for this workflow because it does more than show pass or fail. It helps identify sending sources, surface configuration issues, monitor DMARC policy, track SPF and DKIM health, watch for blocklist (blacklist) events, and send real-time alerts when something changes.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
- Issue detection: Suped groups authentication problems and gives practical steps to fix them.
- Hosted controls: Hosted DMARC, Hosted SPF, SPF flattening, and Hosted MTA-STS reduce DNS work.
- Multi-domain view: MSPs and larger teams can monitor many domains without losing source detail.
- Action focus: Alerts, weekly summaries, and issue workflows keep the investigation moving.
The practical benefit is that you can keep Microsoft troubleshooting grounded. SNDS tells you something happened at an IP level. Suped helps confirm whether authentication or domain reputation changed at the same time, so the next fix is targeted.
When to contact Microsoft
Contact Microsoft only after you have evidence that the issue is not caused by authentication failures, broken routing, poor list quality, unsafe volume changes, or an obvious blocklist (blacklist) problem. A support request without headers, IPs, dates, examples, and remediation notes usually goes nowhere.
When escalation is justified, include the affected IPs, sending domains, exact send dates, sample recipients, raw headers, SNDS screenshots, bounce text, complaint-handling steps, and the changes already made. The Sender Support path is more useful when your case is specific.
Do not open a Microsoft ticket as the first troubleshooting step. Fix what you control first, then escalate with evidence if Microsoft filtering still looks inconsistent.
Views from the trenches
Best practices
Check message headers first, because SCL and BCL often explain Microsoft placement faster.
Segment recent engagers before testing, so reputation changes do not hide behind list mix.
Compare SNDS by IP and send date, then confirm the pattern against bounces and headers.
Keep opt-in mail away from prospecting traffic when domain or IP reputation is weak.
Common pitfalls
Treating green SNDS rows as proof of inboxing misses tenant-level and user-level filtering.
Changing seed lists mid-test makes Microsoft results look random even when targeting changed.
Keeping open-only contacts forever can depress engagement and weaken sender reputation.
Moving to a subdomain without traffic separation can preserve the same reputation problem.
Expert tips
Send a controlled message to Microsoft inboxes and archive headers before DNS changes.
Use SNDS red days as investigation triggers, not as final proof of the root cause alone.
Review inactive B2B contacts by stage and recency, not one blanket archive rule for all.
Separate authentication checks from reputation checks, because passing records can still land in spam.
Marketer from Email Geeks says Microsoft SNDS has felt too thin for diagnosing root causes, so use it as a signal source rather than the main investigation record.
2025-04-29 - Email Geeks
Marketer from Email Geeks says BCL and SCL in received headers can explain Microsoft filtering decisions more directly than aggregate dashboards.
2025-04-29 - Email Geeks
The practical way forward
The right way to troubleshoot Microsoft deliverability is to answer one question at a time. Did authentication pass? What did the headers say? Did SNDS show an IP-level reputation event? Did engagement or audience quality change? Did a subdomain or migration mix clean and risky streams? Did a blocklist or blacklist event appear?
For a broader Microsoft-specific checklist, the Outlook.com playbook pairs well with this workflow. Keep SNDS in the process, but do not make it the process. The strongest diagnosis comes from SNDS, headers, logs, DMARC reporting, engagement, and controlled testing together.
