Microsoft SNDS & JMRP for Outlook.com

Microsoft’s postmaster surface for consumer Outlook.com (the mailboxes at outlook.com, hotmail.com, live.com, and msn.com) is two free services that now live in one portal: SNDS (Smart Network Data Services) for per-IP sending data, and JMRP (the Junk Email Reporting Program) for complaint feedback. This page is deliberately split into what Microsoft’s public pages verifiably state and what sits behind login - because much of the SNDS data view is only visible to an authorized account, and inventing its specifics would violate everything this library stands for.

Scope note up front: SNDS and JMRP are about consumer Outlook.com. Microsoft 365 / Exchange Online (enterprise) deliverability is a separate world and is not what these tools report.

The 60-second version

• SNDS is keyed by sending IP address, not domain. You request access to “the IPs for which you are responsible” with a Microsoft account.
• SNDS “gives senders access to detailed data about individual IPs, and it also includes our Junk Email Reporting Program.”
• JMRP is Microsoft’s complaint feedback loop: it “lets you receive reports when users junk your messages.”
• As of mid-2026 the service moved to a new SNDS portal; the old sendersupport.olc.protection.outlook.com/snds/ automated URLs are being deprecated (Microsoft’s stated date: June 22, 2026). Enrollment and data now run through the new portal.
• Microsoft’s IP-centric model is the structural opposite of Google’s and Yahoo’s domain-centric tools - which is why shared IPs are far more consequential at Outlook.com.
• The granular SNDS data grid (per-IP complaint bands, filter results, color status, trap hits) is behind login. We describe it only at the level Microsoft documents publicly.

SNDS: what it is and how access works

Microsoft’s framing is reputation-first: “Deliverability to Outlook.com is based on your reputation. The Outlook.com Smart Network Data Services (SNDS) gives you the data you need to understand and improve your reputation at Outlook.com.” It is explicit that “Reputation is always the responsibility of the sender.”

What SNDS provides, per the portal:

• “detailed data about individual IPs” - the service is organized per IP address, reflecting how Outlook.com weighs IP reputation.
• an integrated feedback loop: “it also includes our Junk Email Reporting Program, which lets you receive reports when users junk your messages. Now you can view IP data and manage feedback loop settings from one convenient website.”
• a secondary safety use: “It can help IP owners to detect compromised servers, malware, viruses, and botnets” - SNDS is also how a network operator spots a hijacked sending host.

Access is IP-authorization, not domain verification. Microsoft: “To access SNDS, please log in with a Microsoft Account and then request access to the IPs for which you are responsible. You’ll be taken through a simple authorization process.” That authorization step is the gate - you prove control of the IP space, then the data for those IPs opens up. The portal’s own navigation exposes the surface: View Data, View IP Status, Request Access, Access Control, Edit Profile, FAQ, and Junk Mail Reporting Program.

The 2026 portal migration

If you have older automation pointed at SNDS, this matters. The portal announcement (last updated June 19, 2026) states: “Welcome to the new SNDS portal. This site is replacing the previous site.” And critically: “Automated access URLs beginning with https://sendersupport.olc.protection.outlook.com/snds/ are to be deprecated by June 22nd 2026. Please update your URLs.” Requests to the old snds/ paths now redirect to the new portal host. If you pull SNDS data programmatically, re-generate the automated-access link in the new portal.

What the SNDS data view shows - and what we will not claim

SNDS’s value is its per-IP data grid. Publicly, Microsoft confirms it is “detailed data about individual IPs.” The specific columns and semantics - the message-volume buckets, the complaint-rate bands, the spam-trap counts, the filter-result breakdown, and the color-coded IP status - are rendered only inside the authenticated portal and are not stated in Microsoft’s public page text. Rather than repeat third-party descriptions as if they were Microsoft’s words, we flag those specifics as unverified from primary sources here. The honest, verifiable summary: SNDS reports per-IP sending health and a reputation/status signal that you act on by cleaning lists and watching the IPs you control “for unusual behavior.”

JMRP: the Outlook.com feedback loop

JMRP is Microsoft’s complaint feedback loop, and it is the reason senders enroll even when they read no dashboards. The verifiable core, from the SNDS portal: JMRP “lets you receive reports when users junk your messages.” When an Outlook.com user marks your mail as junk, Microsoft generates a feedback report to your enrolled address so you can suppress that recipient.

A few points held to the verifiable level:

• JMRP lives inside SNDS now. You “manage feedback loop settings from one convenient website” - the Junk Mail Reporting Program tab in the SNDS portal. (The legacy enrollment URL postmaster.live.com/snds/JMRP.aspx predates the migration; manage enrollment through the current portal.)
• It is complaint feedback, not a metrics dashboard. JMRP’s job is to forward the signal that a user complained; the rate/volume picture is SNDS’s job.
• Report format. Provider feedback loops are delivered in ARF (Abuse Reporting Format, RFC 5965) - a multipart/report message whose machine-readable part identifies the complaint and includes the original message or its headers, so you can match the complaint to a subscriber and suppress them. The exact set of fields Microsoft populates is not published in the public pages, so treat field-level detail as implementation-specific.

What JMRP does not give you is engagement or placement - it is a complaint stream. And unlike Google’s campaign-aggregate Feedback loop, a per-message complaint feedback loop like JMRP is what lets you suppress an individual complainer. For the contrast, see Google Postmaster Tools and Yahoo Sender Hub & CFL.

The enforcement context you should read alongside

Outlook.com’s postmaster site also carries the high-volume sender enforcement that frames why SNDS/JMRP matter now. Verbatim from the Postmaster announcements: “Starting May 5th, 2025, Outlook.com is enforcing stricter email authentication standards (SPF, DKIM, DMARC) for domains sending over 5,000 emails per day… Non-compliant messages will be sent to … the junk folder. Shortly we will reject the messages until the DNS records are corrected.”

So the picture is: meet SPF/DKIM/DMARC if you send over 5,000/day to Outlook.com, then use SNDS to watch the IPs and JMRP to suppress complainers. The full requirement breakdown is on the Microsoft sender requirements page; note the source blog is internally layered with edits, so the “junk first, reject later” sequencing is the last stated action with the rejection date still to be announced.

What it will not tell you

• Domain-level reputation. SNDS is per-IP. A domain reputation problem does not surface here the way it does at Google or Yahoo - see IP vs Domain Reputation.
• Enterprise (Microsoft 365) mail. These tools are for consumer Outlook.com.
• Placement. Like every provider tool, it reports perception and complaints, not which folder you landed in.
• Engagement. JMRP is complaints only.
• Anything before you authorize the IPs. SNDS data is gated on the IP-authorization step.

What this means for you, and what Egressif does

For Outlook.com, think in IPs. Get the sending IPs authorized in SNDS, enroll those IPs’ streams in JMRP, and treat the complaint feedback as a suppression input, not a vanity metric.

Egressif requests SNDS access for the sending IPs we operate for a client, enrolls them in JMRP, and routes the resulting complaint reports into suppression inside our pipeline so a user who hits “junk” at Outlook.com stops receiving mail - the single highest-value action a feedback loop enables. We watch the SNDS per-IP signals for the unusual-behavior patterns Microsoft built the tool to catch, and we keep authentication aligned to the 5,000/day enforcement so Outlook.com is not foldering or rejecting on authentication in the first place. Where Microsoft keeps detail behind login, we report what we can actually see rather than guess. We make no inbox-placement promise; we make sure the complaint signal is captured and acted on, and that the IPs stay clean.