Microsoft SNDS: what it tells you, how to read it, and what to do about red status

Microsoft SNDS (Smart Network Data Services) is Microsoft’s free portal that shows how Outlook.com’s filters treated mail from IP addresses you control. Most people arrive at it in one of two moments: a sending IP has just turned yellow or red, or someone on the team has been told to “set up SNDS” with no clear idea of what it will show.

The answer depends on whose IPs you send from. For senders on dedicated IPs they control, SNDS is one of the few direct views into how Microsoft judges their mail. For most B2B outbound teams, sending from Google Workspace, Microsoft 365 or an ESP’s shared pool, it shows nothing at all, and it never covers the Microsoft 365 business tenants their prospects use. Several of its best-known metrics also changed or disappeared in 2026, so many guides now describe a report that no longer exists.

This guide covers what SNDS is and which mail it covers, how to set it up under the 2026 rules, and how to read its data the way Microsoft defines it. It then walks through what changed this year, what to do when an IP turns yellow or red, and what B2B teams should watch instead when SNDS cannot see their traffic.

‍

Key takeaways

• SNDS only covers consumer Outlook.com mail. It reports on mail from IPs you control to Outlook.com, Hotmail, Live and MSN mailboxes, not to Microsoft 365 business tenants.
• Most B2B teams cannot register their sending IPs. Mail sent from Google Workspace, Microsoft 365 or an ESP’s shared pool leaves from IPs the team does not control, so it cannot use SNDS directly.
• The filter result is not an inbox placement rate. It measures the share of recipients for which Outlook.com’s filter judged the mail as spam: green under 10%, yellow from 10% to 90%, red over 90%.
• SNDS changed significantly in 2026. It moved to a new portal, JMRP complaints stopped carrying the recipient’s address, and spam trap counts were removed from the data report.
• List quality now has to be caught before the send. With trap data gone, the clearest list signal left is the gap between RCPT commands and message recipients, and by the time it shows, the invalid addresses have already been sent to.

‍

What Microsoft SNDS is, and which mail it covers

Microsoft SNDS (Smart Network Data Services) is a free portal where the owner of an IP range can see how Outlook.com received and filtered mail from those addresses. Microsoft builds the data from the logs of its inbound mail servers: how many recipients each IP tried to reach, how many messages it actually transmitted, how the spam filter judged them, and how often users marked them as junk. SNDS sits alongside the Junk Mail Reporting Program (JMRP), which sends you a report each time an Outlook.com user flags your mail as junk.

The scope is narrower than most guides suggest. Microsoft writes its SNDS documentation around the Outlook.com system, which its Troubleshooting page defines as the consumer addresses at outlook.com, hotmail.com, live.com and msn.com. Mail to a company domain hosted on Microsoft 365 is filtered by Exchange Online Protection instead, and SNDS does not report on those tenants.

SNDS therefore shows how consumer Outlook.com mailboxes treat your mail, not how a company’s Microsoft 365 tenant does.

Google Postmaster Tools is the closest Gmail counterpart, with one structural difference: SNDS reports by sending IP, while Postmaster Tools reports by sending domain. Our guide to Google Postmaster Tools covers that side.

Who can and cannot use SNDS

You get access by proving you control an IP range, and Microsoft decides who can approve that from public records rather than a support ticket. It sends an authorization email to contact addresses it finds in public records for that range, and someone at one of those addresses has to approve it. Microsoft does not process manual requests, so if you cannot receive mail at those addresses, you cannot register the IPs.

That rule quietly excludes most B2B outbound teams. Mail sent from Google Workspace or Microsoft 365 mailboxes leaves from Google’s or Microsoft’s IPs, and mail sent through an ESP’s shared pool leaves from the ESP’s. None of these teams receive mail at the postmaster address for those ranges, so none of them can register the IPs. An ESP may monitor its own pools in SNDS, and it is worth asking what it sees.

Shared IPs carry a second limit. On a shared IP, JMRP shows every complaint about that IP regardless of which sender’s domain generated it, so even an ESP’s view mixes your complaints with everyone else’s.

SNDS is a tool for senders on dedicated IPs they control, typically high-volume marketing and transactional programs. For most cold outbound teams it is simply not available.

‍

How to set up SNDS

Setup is quick once you know which addresses Microsoft will email. The order matters, because each step depends on the one before it:

1. Sign in at the new SNDS portal with a personal Microsoft account. Microsoft’s FAQ asks for consumer Microsoft account credentials, so a Microsoft 365 work login is the wrong door.
2. Request access to your IP range. Enter the range you send from, starting narrow if you are unsure what Microsoft will accept.
3. Approve the authorization email. Microsoft sends it to the contact addresses it found for the range, and someone at one of those addresses has to approve it. Approvals now require signing in, a change Postmastery reports was made to stop security scanners and link previews from approving requests automatically.
4. Wait for data. Reports appear the day after sending, and only for days the IP sent at least 100 messages.

Microsoft finds those contacts through one of three routes. Reverse DNS authorizes postmaster@ and abuse@ at the domain your hostnames share, for ranges up to a /23 (about 500 addresses). The RDAP allocation record authorizes its listed contacts for a range no larger than that record. An ASN’s RDAP contacts can approve every subnet the ASN advertises. If a request fails, Microsoft’s advice is to retry with different inputs, such as a smaller range, since it does not process manual requests.

Access no longer lasts indefinitely. It now expires 10 months after approval or migration, with reminders around three, six and nine months in, and an authorized contact has to reattest before the deadline or the access is removed. Microsoft has flagged that the deadline date in its first reminder email is wrong, so check the real dates on the Access Control page.

Enroll in JMRP at the same time, from the JMRP section inside SNDS, so complaint reports start arriving alongside the data. For automated access, SNDS now offers a REST API secured with OAuth 2.0, which Microsoft targets at desktop applications rather than servers, and the automated CSV links expire after 30 days and must be renewed, so any script built on the old links needs updating.

‍

How to read the SNDS data

The data report gives you one row per IP per day. Each column answers a narrow question, and most misreadings come from treating a column as something it is not.

‍

The filter result is the column most guides get wrong. Microsoft defines it as the share of spam calls its filter made, counted per recipient, so one message to ten people counts ten times. Green means under 10% of those calls were spam, yellow means between 10% and 90%, and red means over 90%. It measures the filter’s judgment, not inbox placement, because users’ own settings and safe-sender lists can still move a message after the filter has made its call.

A green IP can still see mail land in junk.

The complaint rate is complaints divided by message recipients. Microsoft’s benchmark is that more than 30% of IPs sending to Outlook.com keep it below 0.3%, which it describes as a good bar to aim for. That figure is a target, not a color trigger: no complaint rate turns an IP yellow or red on its own.

Timing explains most “missing” data. Microsoft starts aggregating each day’s data at around midnight Pacific and the process can take a couple of hours, the data is kept for 90 days, and an IP that sent fewer than 100 messages on a given day may show nothing at all. The separate IP Status page flags IPs that are Blocked, Bot or Junked, but it only reflects the last 24 hours and keeps no history.

The RCPT-to-recipients gap is your list-quality signal

RCPT commands count the addresses you attempted. Message recipients count the ones Outlook.com accepted. The difference between the two is mostly addresses that do not exist, and Microsoft names out-of-date lists as the usual cause of a large gap.

Microsoft also gives a benchmark that almost no guide cites: more than a third of IPs sending to Outlook.com keep the share of RCPT commands that do not become recipients under 10%, and a small difference is normal. A gap well above that points at the list, not the infrastructure.

The catch is that the gap is a lagging signal. By the time it appears in SNDS, the invalid addresses have already been attempted and logged against your IP. The fix sits before the send, in verifying the list so those addresses never reach a sequence. You can check addresses with our free email verifier before they go into the next campaign.

‍

What changed in SNDS in 2026

SNDS went through its largest overhaul in years in 2026, and most of the changes alter what you can see or how you get to it.

The first is complaint tracing. Since JMRP moved to ARF, complaints no longer carry the recipient’s address, so the only way to tie a complaint back to a send is through what survives in the headers: the Message-ID, the envelope sender if you use VERP, and any identifier you add yourself, such as a campaign or message ID in a custom X-header. Teams that matched complaints to recipients and suppressed them automatically need that header in place before the next complaint arrives, or the suppression loop breaks.

The second is list quality. Trap counts were the most direct sign in SNDS that a list contained abandoned or never-real addresses, and Microsoft removed them on 22 July 2026, citing the need to protect its anti-abuse systems. What remains is the RCPT-to-recipients gap covered above, so catching bad addresses now has to happen in verification before the list is used. Our guide to spam traps covers how they work and how lists pick them up.

Most guides on this topic still describe the old report, so readers following them will look for trap fields and a portal address that no longer exist.

‍

What to do when your IP turns yellow or red

A yellow or red filter result tells you Outlook.com’s filter judged a large share of your mail as spam, but not why. The cause is usually one of five things, and checking them in order saves time, because the early checks rule out the problems that make the later ones irrelevant.

Start with the IP Status page, since a Blocked or Junked flag there changes everything that follows. Then check authentication: Microsoft has required SPF, DKIM and DMARC from domains sending more than 5,000 messages a day to Outlook.com since 5 May 2025, and mail that fails is rejected with a 550 5.7.515 error. Next, look at the complaint rate and the JMRP feed for a spike. After that, check the RCPT-to-recipients gap for a list problem. Last, look for a volume jump or a newly imported list on the days the color changed.

Once you know the cause, the response follows the same sequence whatever it was:

1. Pause the affected stream so the damage stops compounding while you investigate.
2. Remove the segment behind the spike, usually the newest list or the campaign that coincided with the color change.
3. Suppress complainers and hard bounces across every stream that sends from the IP.
4. Verify the list before resuming, so the addresses that caused the problem are not sent to again.
5. Ramp volume back gradually, watching the filter result and the RCPT gap each day before adding more.

If the problem persists after the fix, escalate through the right channel. For consumer Outlook.com mailboxes, that is Microsoft’s sender support form, linked from its Troubleshooting page. The delist portal at sender.office.com is a different system: it handles blocks on mail to Microsoft 365 recipients, and sending an Outlook.com problem there goes nowhere.

Set expectations accordingly. Microsoft states that a support request does not guarantee delivery and makes no promise on timing, and a delisting request without a fix behind it rarely holds, because the same traffic produces the same result. Our email blacklist guide covers the third-party lists that can block mail at the same time.

‍

What B2B teams should watch instead

For most B2B teams, the Microsoft traffic that matters is business-tenant traffic. In our census of Fortune 500 primary domains, run from April to June 2026, 412 of the 500 companies (82%) received mail on Microsoft 365. SNDS reports on none of it.

Three signals do reflect how Microsoft 365 tenants treat your mail, and each answers a different question:

• Bounce codes in non-delivery reports tell you whether a tenant refused the message and why. Microsoft documents each 5.7.x code, from authentication failures to blocked sending IPs, so the code itself usually names the problem.
• The anti-spam headers Microsoft adds to delivered mail tell you how the tenant’s filters classified a message that got through. You can read them when you send to a Microsoft 365 mailbox you control, and Microsoft explains what each header field means.
• The Microsoft 365 delist portal at sender.office.com tells you an IP has been blocked outright, since a block shows up as a 5.7.6xx rejection pointing you there.

All three report after the send, which is why list quality has to be handled earlier for this audience. B2B teams cannot see SNDS, trap counts are gone for everyone, and a bounce at a Microsoft 365 tenant still counts against your sending reputation whether or not any portal shows it. That reputation follows the sending domain as well as the IP, which our guide to domain and IP reputation explains in more detail.

This is the gap Allegrow is built for. Its verification returns a conclusive valid or invalid on Microsoft 365 and catch-all company domains before the send, where basic checks return unknown, so the addresses SNDS would only have exposed afterwards never reach a sequence. Its domain reputation monitoring measures placement across real B2B inboxes rather than consumer seed lists, which is the view of Microsoft 365 that SNDS does not give you.

‍

Conclusion

SNDS is worth setting up if you send from IPs you control. It is free, it comes directly from Microsoft, and it becomes far more useful once you read the filter result and the RCPT-to-recipients gap the way Microsoft defines them, rather than the way most guides describe them.

For B2B outbound, SNDS is mostly invisible. The sending IPs belong to Google, Microsoft or an ESP, and the prospects sit on Microsoft 365 tenants the portal does not cover. With trap counts removed for everyone in 2026, list quality is now something you protect before the send rather than something a portal reports after it.

To see what that looks like on your own data, start a 14-day free trial and run up to 1,000 of your own B2B contacts through Allegrow. That includes the Microsoft 365 and catch-all addresses other verifiers return as unknown, so you get a conclusive valid or invalid before the send instead of a bounce after it.

‍

Frequently asked questions about Microsoft SNDS

What does SNDS stand for?

SNDS stands for Smart Network Data Services, Microsoft’s free portal that shows IP owners how Outlook.com received and filtered their mail. It reports daily data on recipients attempted, messages delivered, spam filtering and user complaints. Only the owner of an IP range can use it, after proving control of that range.

Is Microsoft SNDS free?

Yes. Microsoft describes both SNDS and the Junk Mail Reporting Program as free services. The only requirement is proving that you control the IP range, by approving an authorization email sent to the contacts Microsoft finds for it.

Where do I log in to Microsoft SNDS?

The current portal is at substrate.office.com/ip-domain-management-snds/snds, which replaced the old sendersupport.olc.protection.outlook.com address on 8 June 2026. The old URL redirects to the new site. Sign in with a personal Microsoft account, not a Microsoft 365 work account.

What is the difference between SNDS and JMRP?

SNDS reports daily filtering data for each IP you control, while JMRP sends you a report each time an Outlook.com user marks your mail as junk. Since June 2026, JMRP reports arrive in the standard ARF format without the recipient’s address, so tracing a complaint depends on identifiers you add to your headers.

Why is my SNDS dashboard showing no data?

The usual causes are that the IP sent fewer than 100 messages that day, the range was never authorized or its access expired under the 10-month reattestation, the IP is not the one your mail actually leaves from, or the day has not finished aggregating. Data for each day appears a few hours after midnight Pacific time.