Microsoft SNDS monitor guide for Outlook sender reputation

Microsoft's Smart Network Data Services (SNDS) is the only window most senders ever get into Outlook.com filtering. It is free, frequently updated, and almost always misread — usually because the column names are terse and the documentation is spread across three different help portals. Pair it with domain monitoring, deliverability testing, and the API docs if you need repeatable checks around Outlook reputation.

What each SNDS column means

The three SNDS warning signs

1. Filter result flips to YELLOW. You have ~72 hours before delivery degrades. Pause campaign volume and identify the offending segment.
2. Trap hits appear for the first time. A trap is an address that should never receive mail — hitting one means your acquisition or hygiene process is broken.
3. HELO/MAIL FROM mismatch with rDNS. Microsoft penalizes infrastructure that does not reverse-resolve cleanly to its sending identity.

What to do when SNDS turns yellow

Use SNDS as a trigger, not as the whole diagnosis. A YELLOW day should send the team to the bulk sender checklist, a fresh deliverability test, and list validation before the next Outlook-heavy campaign.

Pairing SNDS with JMRP

SNDS gives you the rate; JMRP (the Junk Mail Reporting Program) gives you the addresses. Sign up at the same portal, register a complaint-handling mailbox, and Microsoft will forward every 'Junk' click. Suppress those addresses immediately — continuing to mail them after a complaint is the fastest way to a permanent block.

Additional guidance: Microsoft SNDS: Setup Guide and How to Read Your Data

Microsoft SNDS (Smart Network Data Services) is Microsoft's free dashboard showing how Outlook.com, Hotmail, and Live treat your sending IPs: mail volume, complaint rates, spam trap hits, and a green/yellow/red reputation status per IP. You register, prove ownership of your IP space, and get daily data within about 24 hours. It is the only first-party window into Microsoft's consumer spam filtering, and most senders never set it up.

If you send any meaningful volume to @outlook.com, @hotmail.com, or @live.com addresses, SNDS is not optional reading. It's the difference between guessing why Outlook junked your campaign and knowing.

What is Microsoft SNDS, exactly?

SNDS is Microsoft's counterpart to Google Postmaster Tools, with one structural difference you need to internalize upfront: SNDS is IP-based, not domain-based. Every data point it shows you is tied to a specific sending IP address, because Microsoft's consumer filtering still weighs IP reputation heavily.

For each IP you own, SNDS reports roughly daily aggregates:

That last row is the one everyone fixates on, and we'll come back to it. The two columns most senders underuse are complaint rate and spam trap hits — they tell you why the color moved.

SNDS vs. Google Postmaster Tools

Google's system reports domain reputation and compliance; Microsoft's reports per-IP traffic and user complaints. If you're already fluent in one, don't assume the other works the same way. Our Google Postmaster Tools v2 guide covers the Gmail side; the mental models don't transfer cleanly, which is also why the domain reputation vs. IP reputation split matters: Gmail leads with domain, Outlook consumer still leads with IP.

Why SNDS still matters in 2026

Microsoft enforced authentication requirements for bulk senders (over 5,000 messages/day to consumer domains) starting May 2025, rejecting non-compliant mail outright with:

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

That enforcement gets the headlines. But authentication is the entry ticket, not the ranking. Once your SPF, DKIM, and DMARC pass, Microsoft's filter still decides inbox vs. junk largely on reputation signals — and SNDS is where those signals surface.

A realistic scenario we see constantly: a sender's Gmail placement is fine, authentication is clean, but 30% of their Outlook-bound mail lands in junk. Without SNDS, they're flying blind. With SNDS, they can see that complaint rate spiked to 0.6% on Tuesday and trap hits appeared the same day — pointing at a bad list segment, not a technical failure.

If Outlook is where your mail is dying, pair this guide with our walkthrough on fixing emails landing in junk at Outlook and Hotmail. SNDS tells you the what; that post covers the how.

How to register and verify your IPs

The Microsoft SNDS setup flow is straightforward but has one step that trips people up: proving you own the IP space.

Step 1: Create the account

Go to sendersupport.olc.protection.outlook.com/snds and sign in with a Microsoft account. Use a shared team alias, not a personal account — SNDS access dies with the employee who registered it.

Step 2: Request access to your IP range

Under "Request Access," enter your sending IPs or CIDR range. SNDS then verifies ownership through one of these routes:

• rDNS match — the IP's reverse DNS (PTR record) resolves to a domain you can receive mail at (e.g., postmaster@, abuse@, hostmaster@).
• Whois match — the IPs are registered to your organization in the RIR whois record, and the contact email there receives the confirmation link.
• Network owner authorization — if the IPs belong to your ESP or hosting provider, they have to authorize your view access.

Step 3: The ESP problem

If you send through a shared ESP (Mailchimp, SendGrid, Braze — anyone on shared IP pools), you generally cannot get SNDS access to those IPs. The pool belongs to the ESP. This is the single most common "SNDS setup failed" story, and the answer is: you don't need SNDS for shared IPs, because you can't act on the data anyway. SNDS becomes essential the moment you move to a dedicated IP.

If you're on a dedicated IP at an ESP, ask their deliverability team to grant SNDS view access — most support it as a routine request.

Step 4: Wait for data

SNDS populates with roughly a 24-hour lag. There are also minimum volume thresholds: if your IP sends very little mail to Microsoft consumer domains on a given day, some panels show nothing. Quiet IPs are data-poor IPs.

How to read the SNDS data panels

A typical daily row, annotated:

IP: 203.0.113.17
Date: 2026-08-11
RCPT commands:     48,210
DATA commands:     47,908
Message recipients: 46,540
Filter result:     Yellow
Complaint rate:    0.4%
Trap hits:         3

Reading it like a practitioner:

• RCPT vs. DATA delta. In the example, ~300 RCPTs never became DATA. Some of that is normal (duplicate suppression, timeouts). A large gap means Microsoft rejected recipients at RCPT time — often a sign the recipient list contains dead or malformed addresses.
• Complaint rate. This is real users clicking "Report junk." Microsoft doesn't publish a hard threshold, but treat anything sustained above ~0.1% as a problem and anything near 0.3%+ as an emergency, consistent with where the industry thresholds landed after Gmail and Yahoo set theirs in 2024–2025.
• Trap hits. Microsoft's spam traps (addresses that never signed up for anything) received mail from your IP. Any nonzero number means your acquisition or hygiene process is leaking. Three hits in a day from a clean sender is a red flag, not noise.
• Filter result. Green/yellow/red is Microsoft's aggregate judgment of the day's mail from that IP. Microsoft has never published the exact formula; treat it as a directional signal, not a grade.

Green, yellow, red: what the status colors actually mean

Hedged translation, based on observed behavior rather than Microsoft documentation:

• Green: Your mail is mostly landing in the inbox. Complaint and trap signals are low. Keep doing what you're doing.
• Yellow: Mixed. A meaningful share of your mail is being junked or bulked. Something in that day's traffic — a list segment, a new campaign type, a volume spike — drew complaints or trap hits. Investigate within days, not weeks.
• Red: Microsoft's filter is actively treating most of your mail as unwanted. Expect bulk-folder placement or throttling at minimum; severe cases see temp-fail deferrals or outright rejection.

Two traps to avoid: a single yellow day after a big campaign is data, not disaster; and green doesn't mean "everything is fine" — it means Microsoft's consumer filter isn't complaining. It says nothing about Gmail, corporate filters, or whether your open rates are healthy.

Before you panic over a status change, verify the underlying signals. Run a test message through the free email deliverability tester to confirm your authentication and DNS posture didn't silently break the same week, and check your setup against the sender compliance checker — a surprising share of "Outlook hates me" cases turn out to be a DKIM key that stopped signing after an ESP migration.

Pairing SNDS with JMRP

SNDS tells you that users complained. JMRP (Junk Mail Reporting Program) tells you which messages they complained about.

JMRP is Microsoft's complaint feedback loop: you register an abuse address per sending domain, and when an Outlook.com user hits "Report junk" on your mail, Microsoft forwards a copy of that message to you. That lets you:

1. Suppress the complainer immediately (they just told you, in the strongest possible terms, that they don't want your mail).
2. Identify which campaign, segment, or template is generating complaints.
3. Spot list-quality problems — e.g., complaints arriving on messages sent to addresses you acquired last month.

The pattern that matters: SNDS shows the trend, JMRP shows the cause. If SNDS complaints climb while JMRP shows the complaints cluster on one re-engagement campaign, you have your answer. For the full mechanics of feedback loops across providers, see our email feedback loops guide.

One operational note: unlike Gmail's FBL (which is aggregate and identifier-based), JMRP sends the actual message. That carries privacy obligations — treat JMRP feeds as sensitive data, restrict access, and automate suppression rather than letting reports pile up in a mailbox.

Automating SNDS: API access

Manual dashboard checks don't scale past one or two IPs. Microsoft exposes SNDS data programmatically: after account approval, you can request an automated access key and pull daily data files via HTTP, one file per IP per day, in a structured text format.

What teams actually build with it:

• Daily ingestion into a monitoring dashboard. Pull yesterday's data for every IP, store it, chart complaint rate and trap hits over time. Status changes become alerts, not surprises.
• Alert thresholds. Page someone when complaint rate crosses 0.2% or trap hits go nonzero.
• Correlation with your own send logs. Match yellow days against campaign IDs to find which mailstreams drive reputation down.

If you'd rather not build the pipeline, WillItInbox imports SNDS data directly into its domain and reputation monitoring — alongside Microsoft SNDS, we also sync Google Postmaster Tools and Yahoo complaint data, so your Outlook reputation shows up next to your deliverability scores and DMARC drift alerts in one place. The DMARC monitoring dashboard is where that consolidated view lives: SNDS imports alongside continuous domain drift scans, so an authentication change and an Outlook reputation dip show up on the same timeline.

What to do on a yellow or red day

A runbook, in order:

1. Check trap hits first. Nonzero traps = a list problem. Find which send introduced the addresses (JMRP data, your own logs, signup timestamps) and cut that source.
2. Segment the complaint rate. If you can tie complaints to a campaign via JMRP, pause that mailstream.
3. Verify nothing technical broke. DKIM still signing? SPF still under the lookup limit? PTR record still intact? One broken record during a yellow streak turns a reputation problem into an authentication rejection problem (550 5.7.515 territory).
4. Reduce volume to Microsoft consumer domains. Throttle back to your most engaged segment — opens/clicks in the last 30 days — for a few days. Complaint rates drop when you stop mailing the disengaged.
5. Don't chase the color. The status is a lagging indicator of yesterday's behavior. Fix the inputs (list quality, engagement targeting, frequency) and the color follows in days to weeks.

If the red persists beyond two weeks of clean sending, Microsoft's sender support form exists and does get answered — but arrive with SNDS data, JMRP suppression evidence, and authentication proof in hand. "Please unblock us" with no evidence goes nowhere.

Pair SNDS with domain monitoring, DMARC monitoring, the email deliverability tester, and email validation before resuming Outlook-heavy volume.

Continue this inbox placement and reputation monitoring workflow with the commercial page, the core guide, the implementation docs.