Microsoft Smart Network Data Services (SNDS) is the closest thing senders have to a reputation dashboard for Outlook.com, Hotmail, Live.com, and MSN mailboxes. It shows how Microsoft sees the IPs you send from: status color, complaint activity, and traffic volume (spam trap hit counts leave the Data Report on July 22, 2026). It does not fix anything. It tells you where to look.
In 2026 Microsoft changed how you access that data. None of the changes alter what SNDS reports, but several of them quietly break the pipelines teams built around it. If your password resets, invoices, onboarding mail, or campaigns land in Microsoft consumer inboxes, treat this as a monitoring operations issue, not a portal cosmetic update.
What Changed in 2026
Four things moved at once.
The portal moved to a new URL. Microsoft migrated SNDS to a new address on June 8, 2026. The old sendersupport.olc.protection.outlook.com/snds/ host now redirects to https://substrate.office.com/ip-domain-management-snds/snds. The redirect works today, but saved bookmarks, hardcoded report URLs, and any undocumented workflow pointing at the old host should be treated as temporary. Redirects get retired.
Automated access links now expire after 30 days. SNDS automated access lets you pull CSV data without logging in through a browser. Those links used to feel permanent. They are not. An expired link can return a 404, and a 404 in a cron job is exactly the kind of failure nobody notices until reputation has already slipped. If a scheduled download silently stops, your dashboard keeps showing the last good data and everyone assumes things are fine.
There is now a REST API with OAuth 2.0. Microsoft added structured API access for SNDS data reports and IP status reports, reportedly with optional date and IPv4 filtering. This is the better long-term path: OAuth-based access is easier to monitor, secure, and wire into existing systems than a rotating CSV link. Two caveats before you build on it. Microsoft has published no documentation for the API, so everything circulating about it comes from people poking at it. And the OAuth flow issues an eight-hour access token with no refresh token, so a scheduled pull stops every eight hours until a human re-authenticates.
JMRP reports are now header-only. On June 11, 2026, Microsoft removed the X-HmXmrOriginalRecipient header, which carried the complainant's raw address, and stopped appending the message body to Junk Mail Reporting Program complaints. What arrives now is headers, Authentication-Results and Received-SPF among them. Your own custom X-headers survive, with one wrinkle: if the value looks like an email address, it gets redacted too, which breaks VERP-style attribution. If your abuse handling depends on parsing message bodies or the original recipient, it needs to change.
Why This Breaks Monitoring
Deliverability failures show up late. By the time open rates dip or support tickets climb, the reputation problem is usually already active. SNDS exists to shorten that gap by giving you Microsoft-specific signals you can compare against bounce logs, complaint rates, and authentication results.
That only works if the data keeps flowing. A 30-day link that expires mid-quarter, a script still pointed at the old portal, or a JMRP parser that assumes a message body it no longer receives are all single points of failure. Each one fails silently, which is the worst way to lose visibility. The fix is to make these failures loud: alert when a download returns no rows, when a link is near expiry, or when a parse step hits an unexpected format.
What to Audit Now
Work through this in order. Most of it is account hygiene you should have anyway.
- Confirm the Microsoft account behind SNDS still works and belongs to a current team, not a former employee or an undocumented mailbox.
- Review IP ownership. Every active sending IP should be covered, and any range you no longer control should be removed.
- Inventory every script, cron job, dashboard, alert, and data-warehouse import that pulls SNDS CSV data. Flag anything depending on an automated access link.
- Check link expiry. Document who owns each link, where it is used, when it refreshes, and how a failure gets detected.
- Update JMRP processing so complaints map from durable identifiers instead of message bodies.
- Compare SNDS against your other reputation signals rather than reading it alone.
Migrate to the REST API
Reputation monitoring should be repeatable, not dependent on someone remembering to download a report when a campaign tanks. The REST API gets you closer, as long as you plan around the eight-hour token. With OAuth-based access you can pull SNDS data into an internal dashboard daily, alert when an IP moves to yellow or red, line complaint spikes up against specific campaigns or customer streams, and keep a history for incident review.
If you would rather not build and babysit that pipeline yourself, Generator Labs blacklist monitoring tracks IP and domain reputation across hundreds of data sources and alerts the right people when something flags, so Microsoft reputation sits next to your broader blocklist picture instead of in a separate tab. The TLS certificates on your sending hosts belong in that picture too: an expired cert quietly blocks mail to Outlook and everywhere else, which is what certificate monitoring is for.
Strengthen Complaint Mapping
JMRP feedback is only useful if you can trace a complaint back to its source. With less body content available, that mapping has to come from headers and stable metadata. Make sure your system can connect a complaint using identifiers like:
- Message-ID
- Campaign ID and customer or tenant ID
- Sending IP address and mail stream or pool name
- DKIM selector, sending domain, and Return-Path domain
- Authentication-Results and Received-SPF
If you cannot connect a complaint to a campaign, customer, or sending stream, your abuse response slows down. That matters most for ESPs, SaaS platforms, and anyone sending on behalf of multiple brands, where one noisy stream can drag down reputation for everyone in the pool.
SNDS Is One Signal, Not the Whole Picture
A Microsoft delivery problem can come from poor list hygiene, a compromised account, weak authentication, spam trap hits, high complaint rates, a blocklist listing, or a sudden change in traffic. SNDS shows you how Microsoft sees your IPs. It does not tell you which of those caused the problem.
So pair it with the rest. Confirm your sending domain is configured correctly with an SPF, DKIM, and DMARC health check. Watch your IPs and domains against major reputation lists with a blacklist check. SNDS tells you Microsoft noticed something. The rest tells you what to fix.
The 2026 changes are a reminder that reputation monitoring needs an owner, automation, and context. Review your SNDS access, update the workflows that touch it, fix your JMRP mapping, and make sure your team can act the moment a signal turns. Start monitoring before a 404 in a forgotten cron job costs you an inbox.