Microsoft SNDS (Smart Network Data Services) shows how Microsoft scores your sending IPs for Outlook, Hotmail, Live, and MSN, reporting reputation status, complaint rates, and trap hits. JMRP (Junk Mail Reporting Program) is Microsoft's complaint feedback loop, forwarding a report each time a user marks your mail as junk. Both are free and register through the same portal. Microsoft shipped breaking changes in 2026: a portal migration, ARF complaint reports that now contain headers only with no message body, removal of complaint sample downloads, and deprecation of old automated access URLs. Any pipeline built on the old behavior needs updating.
If Google Postmaster Tools tells you what Gmail thinks of you, Microsoft SNDS and JMRP are how you learn what Outlook thinks. For B2B senders especially, where Microsoft mailboxes often dominate the list, these two free tools are not optional. And yet most senders either never set them up or set them up years ago and never touched the pipeline again.
That second group has a problem, because Microsoft pushed substantial changes to both services during 2026. Complaint reports no longer carry message bodies, sample downloads are gone, automated access links have changed, and the portal itself moved. Tutorials written before 2026 are now partly wrong. This guide covers what each tool does, how to set both up correctly today, how to read the data, and exactly which changes broke the old workflows.
SNDS and JMRP: Two Tools, One Portal
The two services are complementary and are managed through the same Microsoft account and portal, but they answer different questions.
SNDS: The IP Reputation Dashboard
Smart Network Data Services gives you visibility into how Microsoft perceives your outbound traffic at the IP level. It reports:
- IP reputation status using a traffic-light model (green, yellow, red).
- Spam complaint rates per IP, calculated against your delivered volume.
- Traffic volume and message recipient counts.
- Trap hits, one of the few direct spam trap signals available anywhere.
- Filtering status for each registered IP.
JMRP: The Complaint Feedback Loop
The Junk Mail Reporting Program is Microsoft's feedback loop. When a Microsoft user marks your email as junk, JMRP forwards a report to a complaint address you designate. This lets you identify exactly which recipients complained so you can suppress them immediately, which is the entire point.
Setting Up SNDS
- Sign in to the SNDS portal with any Microsoft account.
- Register your sending IPs or CIDR blocks. You are declaring which IPs you control.
- Validate ownership. Microsoft uses WHOIS and DNS records to determine who controls the range, then sends verification messages to standard administrative contacts (the usual abuse and postmaster style addresses for the range). You must be able to receive and confirm those messages.
- Wait for data, which typically appears within 24 to 48 hours once ownership is confirmed.
The ownership requirement is the real barrier: SNDS verification goes to the administrative contacts for the IP range, which means you need control of the range or cooperation from whoever does. If you send through a shared ESP pool, you do not control those IPs and cannot register them. In that case, ask your ESP whether they surface SNDS-derived metrics in their dashboard, and request JMRP feed access, since most ESPs route JMRP complaints back to senders. SNDS is most valuable for operators on dedicated IPs and self-hosted infrastructure.
Setting Up JMRP
- Register through the JMRP page using the same Microsoft account you used for SNDS.
- Provide a complaint feedback address that will receive forwarded junk reports.
- Confirm your IP ranges, the same ownership validation process as SNDS.
- Wire up automated processing. This is the step most teams skip, and it is the one that matters.
Every JMRP report should automatically trigger immediate suppression of that address. This data is uniquely valuable because Gmail provides nothing comparable, and yet teams routinely let JMRP reports pile up in an unmonitored mailbox for months, then wonder why Microsoft deliverability collapsed. A complaint you receive and ignore is worse than no feedback loop at all, because you had the signal and did nothing with it. Point the complaint address at an automated processor, not a human inbox.
The 2026 Changes That Broke Old Tutorials
Microsoft shipped several substantial changes during 2026. If your setup or documentation predates them, parts of it are now wrong.
JMRP Reports Are Now Header-Only ARF
Historically, JMRP feedback included the full original message body when a recipient marked mail as junk, which made content-level diagnosis easy: you could see exactly which message triggered the complaint and what the recipient saw.
That is gone. JMRP reports are now fully ARF-standardized and include only the original message headers plus selected authentication headers such as Authentication-Results and Received-SPF. The sender address is redacted and the message body is removed entirely.
What this breaks: any complaint attribution workflow that parsed body content for customer IDs, order references, campaign identifiers, or account tokens. Those pipelines are now broken.
What to do: move attribution into headers. Add campaign IDs, message UUIDs, or custom X-headers to your outbound mail so you can correlate a complaint back to the specific send using header data alone. If your abuse handling depends on reading bodies, it needs to change.
Complaint Sample Downloads Removed
The SNDS portal no longer provides downloadable complaint samples for manual investigation. Previously you could click into a complaint rate and retrieve a sample of the message being complained about. That capability is gone, which reinforces the same lesson: your own internal tracking now has to carry the diagnostic load.
The Portal Moved
Microsoft migrated SNDS out of the old portal in mid-2026 after roughly two decades at the original location. Old bookmarks should redirect, but you should confirm that they do and update your documentation to the new portal.
Automated Access URLs Changed
Automated data access links built on the old SNDS path are being deprecated, and access links now expire rather than living forever. Static URLs embedded in scripts, cron jobs, and dashboards will silently fail once the token lapses, which is the worst failure mode: your monitoring stops without telling you.
Microsoft also added structured API access for SNDS data reports and IP status reports with OAuth-based authentication and optional date and IPv4 filtering. This is the better long-term path: OAuth access is easier to secure, monitor, and wire into existing systems than a rotating CSV link.
Audit your integration now: If you built SNDS automation before 2026, check three things today. Do your automated access URLs still work, or are they silently returning nothing? Does your complaint processor handle header-only ARF, or is it failing to parse bodies that no longer exist? And does anyone still hold the credentials, since access governance is now stricter and links are tied to the account that created them? Silent failure is the default here, so nobody will tell you it broke.
Reading Your SNDS Data
Once data is flowing, the signals to watch:
| Signal | What It Means | Action |
|---|---|---|
| Green status | Microsoft considers the IP healthy | Maintain |
| Yellow status | Warning; complaint or quality issues developing | Investigate immediately |
| Red status | Serious problem; filtering or blocking likely | Urgent; pause and diagnose |
| Rising complaint rate | Recipients marking mail as junk | Identify the campaign or segment driving it |
| Trap hits | List quality or acquisition problem | Treat as urgent; traps lead to blocklisting |
If you see mixed status across your IPs, some green and some yellow or red, isolate the problem IP rather than treating it as a global issue. One sending source is usually dragging the rest down, and identifying which one is exactly what per-IP data is for.
What SNDS Does Not Cover
An important scope limitation: SNDS data covers Microsoft's consumer email services (Outlook.com, Hotmail, Live, MSN). It does not include mail delivered to Microsoft 365 or Exchange Online business and enterprise accounts. For B2B senders whose recipients are mostly on corporate Microsoft 365 tenants, SNDS gives you only partial visibility, and you will need to lean on bounce-log analysis and seed testing for the enterprise side.
Watch your bounce logs for Microsoft enforcement rejections in particular, since Microsoft's bulk sender enforcement introduced specific SMTP rejection codes for non-compliant high-volume senders. Those codes in your logs tell you about enforcement that SNDS itself will not surface.
Combining SNDS With Your Wider Monitoring
SNDS is one input, not the whole picture. Architect your monitoring so Microsoft data sits alongside everything else rather than in a separate tab someone checks after a campaign tanks:
- Google Postmaster Tools for Gmail domain and IP reputation and spam rate.
- SNDS and JMRP for Microsoft consumer IP reputation and per-recipient complaints.
- Blocklist monitoring with a blacklist checker, so Microsoft reputation sits next to your broader blocklist picture.
- Bounce log analysis for enforcement-related rejection codes.
- Seed testing to measure actual inbox placement at Microsoft consumer mailboxes, which fills the gap SNDS leaves.
- Authentication monitoring to confirm SPF, DKIM, and DMARC are passing, verified with a DMARC checker.
With OAuth-based API access you can pull SNDS data into an internal dashboard daily, alert when an IP moves to yellow or red, and line complaint spikes up against specific campaigns. That turns reputation monitoring into something repeatable rather than something dependent on a person remembering to check a portal.
The underlying reason to bother: deliverability failures surface late. By the time open rates dip or support tickets climb, the reputation problem has been active for a while. SNDS exists to shorten that gap by giving you Microsoft-specific signals early, which you can compare against your bounce logs, complaint rates, and authentication results as part of a routine deliverability practice. Free, first-party, and specific to the provider that dominates the B2B inbox is a combination worth the setup effort.
Frequently Asked Questions
Smart Network Data Services is a free Microsoft tool that shows how Microsoft scores your sending IPs for its consumer email services (Outlook.com, Hotmail, Live, MSN). It reports IP reputation status as green, yellow, or red, plus complaint rates, traffic volume, filtering status, and spam trap hits. It is the Microsoft counterpart to Google Postmaster Tools and is essential for senders with significant Outlook audiences.
SNDS is a dashboard showing aggregate IP-level reputation, complaint rates, and trap hits. JMRP is the complaint feedback loop that forwards you an individual report each time a Microsoft user marks your mail as junk, so you can suppress that specific address. SNDS tells you how you are doing; JMRP tells you exactly who complained. Both are free and register through the same Microsoft account and portal.
Microsoft standardized JMRP on ARF format in 2026 with a privacy-conscious change: reports now include only original message headers plus selected authentication headers, with the sender address redacted and the body removed. This breaks any workflow that parsed body content for campaign or customer identifiers. The fix is to put attribution data in headers, such as campaign IDs or message UUIDs in custom X-headers.
Generally no, because SNDS registration requires validating that you control the IP range, and Microsoft sends verification to the range's administrative contacts. On a shared ESP pool you do not control those IPs. Instead, ask your ESP whether they surface SNDS-derived metrics in their dashboard and request JMRP feed access, since most ESPs route JMRP complaints back to senders. SNDS is most valuable on dedicated IPs and self-hosted infrastructure.
No. SNDS data covers Microsoft's consumer services (Outlook.com, Hotmail, Live, MSN) and does not include mail delivered to Microsoft 365 or Exchange Online business and enterprise tenants. For B2B senders whose recipients sit mostly on corporate Microsoft 365, SNDS gives partial visibility only, so pair it with bounce-log analysis for enforcement rejection codes and seed testing for actual placement.