SNDS — Smart Network Data Services

What SNDS shows you, and what it doesn't

SNDS exposes connection-layer reputation data — the signals Microsoft uses to decide whether to accept, throttle or reject your IP's mail before content even reaches the inbox decision. For each IP you control, the dashboard reports five columns:

How to enrol and what authorisation looks like

SNDS enrolment is free but gated on proof you control the IP range you want to monitor. Microsoft validates control via DNS or via a known administrative email contact.

The enrolment sequence

1. Log in to SNDS at https://sendersupport.olc.protection.outlook.com/snds/ (until the May 2026 migration; new URL announced at migration) with any Microsoft account.
2. Submit the IPs you want to monitor. Single IPs, /24 blocks, /25 blocks, or larger subnets are all valid.
3. Microsoft sends a verification email to one of the standard role addresses on the rDNS of those IPs (postmaster@, abuse@, hostmaster@, webmaster@) or to the technical contact published in the IP's WHOIS.
4. Click the verification link in that email.
5. The IPs appear in your dashboard within 24–48 hours, with data backfilled for the period Microsoft retained.

SNDS and JMRP — the paired data sources

JMRP (Junk Mail Reporting Program) is the per-message feedback loop that pairs with SNDS. When an Outlook.com user marks one of your messages as junk, JMRP forwards a copy of that original message to an email address you specify. JMRP gives you the message-level detail; SNDS gives you the aggregate per-IP rate.

You enrol JMRP through the SNDS interface, then nominate the destination email address that will receive complaint copies. The feed is free but easily overwhelms standard inboxes — for any sender at scale, the destination should be a parsed-by-process mailbox, not a human inbox.

The May 2026 SNDS migration

Microsoft announced in early 2026 that SNDS will migrate off its current URL (sendersupport.olc.protection.outlook.com) to a new portal during May 2026. The migration introduces five operational changes that affect any sender or tooling that integrates with SNDS:

1. New REST API for IP Status and IP Data reports. The previous HTML pages and emailed report links are deprecated. Existing scrapers will break and must be re-pointed at the API endpoints.
2. Authentication remains the same Microsoft login used to access the SNDS portal — no separate API credential is needed, but you must plumb that login into your tooling.
3. Updated calculation methodology. Microsoft has redesigned the data model behind IP Status and IP Data. Historical values are not directly comparable to post-migration values; the published columns themselves have changed.
4. Automated report links expire after 30 days instead of the previous indefinite retention. Long-lived dashboards must refresh the report URLs periodically.
5. JMRP feeds not linked to an SNDS account will be removed. Post-migration, any standalone JMRP feed without a matching SNDS account is dropped. Re-create them under your SNDS account before the cut-over.

Reading SNDS data well

The traffic light

IP Status is the headline indicator and the one most senders check first. The colour means:

• Green: reputation acceptable across all measured dimensions. Mail flows normally.
• Yellow: reputation degraded in at least one dimension. Mail still flows but at reduced rate and with increased filtering. Yellow is the warning band before throttling escalates.
• Red: reputation poor. Throttling or blocks active. Pause sending, audit list, fix root cause before resuming.

What a single number actually means

The data SNDS reports is aggregated, typically by day or by short rolling window. A complaint rate of 0.15% on a single day is not the same as 0.15% averaged over 30 days. The single-day spike may have already triggered SmartScreen filtering even if the rolling average is healthy. Read trends, not snapshots.

The lag

SNDS data lags real-world filtering by 24–48 hours. By the time SNDS turns Yellow, Microsoft has already been applying degraded handling for one to two days. This is why SNDS is best used for daily monitoring with alerting on movement — checking SNDS once a week tells you about a problem that has been live for most of that week.

What to do when SNDS turns Red

The instinct is to submit a delisting request. That is the wrong first action. Microsoft will refuse to mitigate an IP whose underlying behaviour has not changed; the right sequence is to fix the cause before requesting mitigation.

1. Pause sending from the affected IP. Continuing to send while red guarantees the situation worsens.
2. Read JMRP for the previous 7 days. If the complaint count is up, you have the message-level attribution to find which campaign or segment is driving it.
3. Audit your list against the campaigns that fired. Spike + recent list addition often correlates; spike + content change often correlates; spike + no change usually means a competitor or pattern caused a SmartScreen update.
4. Verify SPF, DKIM, DMARC pass with a test send. Authentication failures show up in SNDS as elevated Authentication Failure % and are often the easiest fix.
5. Wait 7–14 days of clean sending after fixing root cause. Microsoft's reputation calculation has memory; one day of clean sending does not flip Red to Green.
6. Submit delisting via sender.office.com only after the above. The form will ask what corrective action you took — answer specifically.

For the detailed delisting workflow and the specific code-by-code runbooks, see our troubleshooting guide on Microsoft Outlook policy rejects.

SNDS blind spots — what you cannot fix with it

SNDS is essential but it is not a complete picture. Four classes of Microsoft delivery problems do not show up in SNDS:

• SmartScreen content filtering. Your IP can be Green and your mail can still go to Junk because the content classifier scored the message poorly. SNDS does not expose SmartScreen output.
• Tenant-side rejections. The 5.7.703–5.7.750 family of NDRs is recipient-organisation policy, not Microsoft consumer-side reputation. SNDS does not report on individual Microsoft 365 tenants' mail flow rules.
• Domain reputation effects. SNDS reports by IP, not by domain. If your domain has reputation damage that follows it across IPs (e.g., post-migration after switching ESPs), SNDS on the new IP will look fine while delivery still degrades.
• Subnet-level filtering. Microsoft sometimes applies filtering at the /24 or /25 subnet level. The single IP you monitor in SNDS may be Green, but neighbouring IPs in the same subnet causing problems can degrade your delivery anyway.

SNDS in CSE managed infrastructure

SNDS monitoring is part of every managed infrastructure deployment we operate. We poll the SNDS API for every client IP daily, alert on movement from Green to Yellow within hours, and pair every SNDS account with a dedicated JMRP feed routed through our complaint-analysis pipeline. The May 2026 migration is being coordinated client-by-client so no JMRP feed is lost in the transition.

For senders running their own infrastructure, the SNDS portal is free and the enrolment is straightforward — the most important step is enrolling JMRP at the same time. The aggregate data without the message-level detail is operationally limited.

Related concepts

• Sender Reputation — the broader concept SNDS measures one provider's view of
• Spamhaus — the public RBL counterpart; SNDS is Microsoft-only, Spamhaus is cross-provider
• SPF, DKIM, DMARC — authentication signals SNDS reports failures of
• Microsoft Outlook policy rejects 2026 — the operational note covering 5.7.x rejection codes that pair with SNDS data
• Complaint rate spikes — how to use JMRP data to find the source of an SNDS complaint-rate increase