Most senders discover SNDS the same way: an Outlook deliverability incident, a search for what tooling Microsoft provides, and then a long afternoon trying to register an IP that the form refuses to accept. SNDS — Smart Network Data Services — is genuinely useful, but its access model is built for network operators and IP block holders, not for the average ESP customer. This lesson explains what SNDS actually measures, why most senders cannot see their own data, and what to use instead when SNDS is closed to you.
The mental model: SNDS scores IPs, JMRP scores domains
Microsoft splits its sender feedback into two systems with different scopes. SNDS aggregates per-IP behaviour: how many messages came from that IP, how many were complained about, how many hit traps, and the resulting colour code. JMRP — the Junk Mail Reporting Program — is a complaint feedback loop that delivers per-message ARF reports when an Outlook recipient marks a message as junk. JMRP is scoped to a registered email address that you control, not to an IP, so it works regardless of whether you own the sending IP.
A complete Microsoft signal therefore requires both: SNDS for aggregate IP-level health (if you can see it), JMRP for per-recipient suppression and campaign attribution (which any sender can register for). Almost every Outlook deliverability programme starts with JMRP regardless of SNDS access.
Why most senders see no SNDS data
SNDS enrolment requires you to claim an IP range, not an individual IP. Microsoft's verification process expects either a SWIP record (Shared WHOIS Project) or a reverse DNS pattern that proves you control the /24 block containing the IP. ESPs typically own those blocks themselves — Resend, Postmark, SendGrid, Mailgun, and similar providers register the entire /24 once, and the SNDS data flows to them rather than to their tenants. Even on dedicated IPs leased from an ESP, the underlying /24 is the ESP's, not yours.
This is the structural reason SNDS is not the universal Outlook equivalent of Postmaster Tools. If you operate your own MTAs on IPs from a cloud provider where you control the SWIP attestation (rare in 2026, but still possible on Hetzner, OVH, and similar), SNDS becomes available. Otherwise, JMRP is the available channel.
Reading the signals: what SNDS surfaces
The colour code (RED / YELLOW / GREEN)
SNDS assigns each scored IP a daily colour. GREEN is the desired state: Microsoft considers the IP a normal sender and applies standard filtering. YELLOW indicates additional scrutiny — more mail will land in the Junk folder, throughput will be slower, and content sensitivity will rise. RED indicates Microsoft is filtering aggressively and may be rejecting outright; expect 550-5.7.x policy bounces with S3xxx tokens.
Colour codes lag the underlying behaviour by 24 to 48 hours and respond to rolling windows rather than single days. A clean campaign the day after a bad one will not move the colour; sustained corrected behaviour over a week will.
Message volume and filter result
SNDS reports the message count Microsoft saw from the IP and the breakdown of how messages were filtered: inbox, junk, or rejected. The ratio is informative. A high inbox percentage on a YELLOW IP suggests the rating is being driven by trap data rather than user complaints. A low inbox percentage on a GREEN IP suggests the colour will degrade soon.
Complaint rate
The percentage of delivered messages that triggered a Junk report. Microsoft has not published a formal threshold, but operational data across thousands of senders converges on roughly 0.3 percent as the soft warning line and 0.5 percent as the IP-level YELLOW trigger over a sustained week. The complaint rate is the metric you can act on fastest: tighten segmentation, suppress aggressive re-engagement cohorts, and the rate will respond within days.
Trap hits
Counts of messages sent to addresses Microsoft has classified as spam traps. Trap hits are weighted heavily — a small number can move an IP to YELLOW faster than a high complaint rate. Two categories appear in practice: pristine traps (never legitimately used) and recycled traps (formerly active, now reclaimed by Microsoft). Pristine hits signal list-buying or scraping; recycled hits signal stale list hygiene. Both remediation paths are covered in list hygiene.
Sample HELO and reverse DNS
SNDS shows the HELO string and reverse DNS Microsoft observed from your IP. Mismatched or generic reverse DNS (cloud provider defaults like ec2-x-x.compute-1.amazonaws.com) hurts your IP's standing independent of complaint data. Set a meaningful reverse DNS that resolves forward and back consistently.
Action playbook
If you have SNDS access and see YELLOW
- Identify whether YELLOW is driven by complaints or traps. The two columns sit side by side in the SNDS data table.
- For complaint-driven YELLOW: suppress the most aggressive segments and cold cohorts. Expect recovery in 7 to 14 days of clean sending.
- For trap-driven YELLOW: stop sending to any segment older than 12 months without explicit re-engagement signal. Trap hits do not decay quickly — recovery often takes 3 to 4 weeks.
If you have no SNDS access
- Register for JMRP at the Microsoft postmaster site using the Return-Path address that handles your bounces. JMRP reports flow to a mailbox you specify; pipe them into your suppression list automatically.
- Parse Outlook bounce diagnostics for S3140, S3150, and AS-series tokens. These are Microsoft's actual filter verdicts and are more actionable than the generic 5.7.1.
- Cross-reference any Outlook regression with Postmaster Tools for Gmail. Provider-specific regressions are usually content or authentication; cross-provider regressions are usually reputation or list quality.
If you cross into RED
Pause sending from the affected IP immediately. Continuing to send into RED status accumulates additional negative signal and extends recovery. Once underlying behaviour is corrected — list hygiene, lower complaint rate, no trap hits — submit the sender mitigation form at the Outlook postmaster site with specific remediation evidence. Do not submit a generic appeal; Microsoft's response cadence is much faster for submissions that name the specific corrective actions taken.
Pairing SNDS with the broader stack
SNDS and JMRP cover Outlook. For Gmail, see Google Postmaster Tools. For blocklist surface area across providers, run the blacklist checker against your sending IPs and your From domain on a weekly cadence. Outlook regressions often correlate with a Spamhaus or SORBS listing event, and catching the listing before SNDS turns YELLOW saves a week of recovery.
The unvarnished truth about SNDS is that most senders never get to see it. JMRP, parsed Outlook bounce diagnostics, and disciplined list hygiene get you 80 percent of the value. SNDS access, when it is available, is the missing aggregate confirmation — useful, but not the gating tool it is sometimes presented as.