# Microsoft SNDS and JMRP: the Outlook.com data most senders cannot reach, and what to read instead

Published: 2026-11-04  
Author: Guanacos Tech (https://guanacostech.com)  
Canonical: https://guanacostech.com/blog/microsoft-snds-jmrp-outlook-complaints

> See which Outlook.com sending data you can actually get, who has to hold the IP it depends on, and which domain-level signals to watch when you cannot.

**Short answer:** Smart Network Data Services (SNDS) is Microsoft's free portal for Outlook.com sending data, and it carries the Junk Email Reporting Program feedback loop. Access is granted per IP address to whoever can prove they hold that address, so senders on shared Google Workspace, Microsoft 365 or platform infrastructure cannot enroll: their provider holds it. Approved access lapses after ten months.

A client calls with a narrow complaint. Order confirmations reach Gmail, invoices reach the accountant at a company domain, and then four or five customers a month insist nothing ever arrived. All of them read their mail at `outlook.com`, `hotmail.com` or `live.com`.

On the Gmail side there is something to open. Postmaster Tools reports a spam rate for a domain you have verified, and that number either moves or it does not. On the Microsoft side there is no domain dashboard. What Microsoft publishes instead is Smart Network Data Services, and the first thing to know about it is that most small businesses cannot use it, for a reason that has nothing to do with whether their mail is any good.

This is the part of Outlook deliverability work where we spend the first hour explaining what is not available, then pointing at what is. Here is the whole picture so you can tell in two minutes which half applies to you.

## What SNDS and JMRP actually are

Smart Network Data Services, almost always written SNDS, is Microsoft's data portal for the people who run sending infrastructure. Microsoft's own description is plain: the service gives senders detailed data about their individual IPs, and it includes the Junk Email Reporting Program, which lets you receive reports when users junk your messages. Two services, one sign-in.

The first is a view per IP address. Microsoft's own wording is detailed data about individual IPs, and that is the honest summary of it: the reporting is attached to addresses, it is visible only to whoever has been approved for those addresses, and it says nothing at all about your domain. The second, usually written JMRP, is a feedback loop. When someone on Outlook.com presses the junk button on one of your messages, Microsoft mails a copy of that complaint to an address you register. Microsoft's services page lists it as a free service and says feedback can begin within as little as 72 hours of enrolling.

For a small sender the feedback loop is the more valuable half. A rate on a chart tells you something went wrong last Tuesday. A complaint report tells you which message, which list and often which campaign, which is the difference between knowing and guessing.

## The catch: access is granted per IP, not per domain

Everything else follows from one structural difference, so it is worth stating carefully.

Google Postmaster Tools is domain based. You enter the domain you sign mail with, the DKIM `d=` domain or the SPF return path, and you prove you hold it by publishing a TXT record in DNS. Anyone who controls the domain can finish that in ten minutes, no matter whose servers the mail leaves from.

SNDS is address based. You sign in with a Microsoft account, request access to the IPs you are responsible for, and then complete an authorization step whose entire purpose is to confirm that you really do hold those addresses. It is built to reach the party that owns the range, not the party filling in the form. For a 12-person company sending through a hosted platform, those are not the same party, and no amount of persistence makes them the same party.

## Which route applies to the way you send

Find your row before you spend an afternoon on a request that cannot be approved.

| How you send | Who holds the sending IP | SNDS and JMRP | What you can read instead |
| --- | --- | --- | --- |
| Google Workspace, Gmail or SMTP relay | Google, from shared pools published through `_spf.google.com` | Not open to you | Postmaster Tools for Gmail, DMARC aggregate reports, bounce codes |
| Microsoft 365, Exchange Online | Microsoft, on its own outbound infrastructure | Not open to you | DMARC aggregate reports, message trace, bounce codes |
| Marketing or transactional platform on a shared IP pool | The platform | Held by the platform, not by you | The platform's own complaint and bounce reporting, DMARC reports |
| The same platform on a dedicated IP | Still the platform, which holds the range | Usually enrolled by the platform; ask what it will share | Platform dashboards, plus any SNDS view it passes on |
| Your own mail server on a VPS or colocated address | You, or the hosting provider above you | Open, once the authorization clears | All of the above, plus SNDS itself |

The first two rows cover most of the businesses we work with, and both land in the same place: the address your mail leaves from belongs to a provider that serves an enormous number of other senders. Google says as much about what that means for reputation, that the activity of any sender using a shared IP address affects the reputation of all senders on it. So even if the numbers for a Gmail outbound address were handed to you, you would be reading the behaviour of a fleet rather than your own.

That is not a reason to shrug. It changes what you are responsible for. On shared infrastructure the IP reputation is the provider's problem and the domain reputation is yours, which is exactly the thing the domain-level signals further down will show you.

## When you do hold the IP: the path, in order

For a client running their own mail server, a VPS relay or a colocated box, SNDS is worth setting up in the first week, not after the first complaint. The order we work in:

1. **Confirm the address is yours to authorize.** If it sits inside a hosting provider's range, the provider has to complete the authorization or forward the confirmation to you. Ask them first. Several providers publish their own procedure for this and will not act on a request filed around them.
2. **Set reverse DNS, and make it match.** A PTR record that resolves to a hostname on your sending domain is the baseline for any Microsoft delivery work. It is also the first thing we check when mail to consumer addresses behaves differently from everything else.
3. **Request access from Microsoft's SNDS page**, signed in with a Microsoft account, for the specific addresses you send from and nothing more.
4. **Register the JMRP address.** Point complaints at a monitored mailbox or a ticket queue, never a personal inbox, and decide in advance what happens to an address that complains. In practice it should be suppressed immediately, the same way a hard bounce is.
5. **Put the expiry in a shared calendar.** See below, because this is the step that gets skipped.

Step five is the one that quietly undoes the other four. Microsoft's SNDS FAQ states that network access lapses ten months after it was approved, so whoever holds the range has to reattest periodically, and reminder mail goes out ahead of the deadline. Ten months is long enough for the person who filed the original request to have changed roles and for the reminder to land in a mailbox nobody reads. Put the date somewhere a team can see it, with the authorization details attached, and treat a sudden empty dashboard as an expiry until proven otherwise.

One more practical note: Microsoft has moved this portal before, and its own SNDS page points at the current location. Start from Microsoft's page rather than a saved bookmark, and the same goes for any walkthrough you find, including this one.

## What to watch when SNDS is out of reach

This is the common case and it reads worse than it is. The Outlook-side signals you cannot get are IP level. The signals you can get are domain level, and for a business sending its own transactional and relationship mail, domain level is the right altitude anyway.

**DMARC aggregate reports.** Microsoft sends them. That means the daily XML already contains a row for every source that sent mail claiming to be your domain, with message counts and authentication results. It will not tell you who complained. It will tell you that an invoicing system, a booking tool or a forwarder is sending unauthenticated mail in your name, and that is a more common cause of an Outlook-only failure than reputation is. Two weeks of reports is usually enough to see the full list of senders.

Free tool

Read your DMARC aggregate report in seconds

Upload the XML a mailbox provider sent you and see who is sending as your domain and whether they align.

[Open the DMARC analyzer](https://guanacostech.com/dmarc-analyzer)

**Bounce codes, read properly rather than pasted into a search box.** Microsoft is unusually specific about why it refused a message, and the code tells you which door you are standing at. An authentication refusal is a DNS and alignment job. A banned address is a different process: Microsoft's delist portal at `sender.office.com` covers its blocked sending IP errors and takes one email address and one IP address per visit, while a `5.7.511` is handled by mail to `delist@microsoft.com` with the full non-delivery report and the address included. Microsoft is also clear that delisting is not absolution, since mail is delivered afterwards only if it still passes the security checks, and the address can be blocked again.

**Nothing bouncing at all.** If messages are accepted and then filed in Junk, you are looking at filtering rather than blocking, and that is precisely the gap a feedback loop would have filled. Without it, fall back to the unglamorous controls: list hygiene, a visible unsubscribe that works on the first click, consistent sending volume, and a small set of seed addresses on Microsoft's consumer domains that you check by hand before any large send.

**The Gmail side, used as a control.** Postmaster Tools needs the authentication domain verified with a TXT record, and Google notes that most of its dashboards only populate once there is sizable daily volume, up to the order of hundreds of messages a day, so a 20-person firm may well see empty charts. Where there is data, Google's sender guidelines ask you to keep the reported spam rate below 0.10% and never to reach 0.30%. Gmail numbers are not Outlook numbers. A clean Gmail picture next to an Outlook-only complaint still narrows the problem quickly to the Microsoft-specific checks.

## How Guanacos Tech helps

On a deliverability engagement we start by establishing which of the rows in that table you are in, because it decides the whole plan. Where SNDS is reachable we enroll the addresses, wire JMRP complaints into suppression, and diary the ten-month reattestation. Where it is not, we build the domain-level view instead: DMARC reporting that someone actually reads, bounce handling that distinguishes an authentication refusal from a blocked address, and a seed list for Microsoft's consumer domains. If you want that done once and handed over rather than pieced together from forum threads, that is what our [email deliverability consulting for small business](https://guanacostech.com/email-deliverability) covers. Book a 30-minute call, bring one bounced message and the name of whatever sends your mail, and we will tell you on the call which signals you can get and which you cannot.

## Sources

- [Microsoft, Smart Network Data Services (SNDS)](https://sendersupport.olc.protection.outlook.com/snds/index)
- [Microsoft, SNDS FAQ (access expiry and reattestation)](https://sendersupport.olc.protection.outlook.com/snds/faq)
- [Microsoft, Services for senders and ISPs (JMRP)](https://sendersupport.olc.protection.outlook.com/pm/services.aspx)
- [Microsoft, Remove yourself from the blocked senders list and address 5.7.511 errors](https://learn.microsoft.com/en-us/defender-office-365/external-senders-use-the-delist-portal-to-unblock-yourself)
- [Google, Set up Postmaster Tools](https://support.google.com/mail/answer/9981691)
- [Google, Email sender guidelines](https://support.google.com/mail/answer/81126)
- [Google, IP address ranges for outbound mail servers](https://support.google.com/a/answer/60764)

## Frequently asked questions

### Is there a Microsoft equivalent of Google Postmaster Tools for my domain?

Not in the same shape. Postmaster Tools reports on a domain you verify with a TXT record. Microsoft's SNDS reports on individual IP addresses and is granted to whoever can prove they hold those addresses, so a business sending through a hosted platform has no equivalent domain dashboard to open.

### Can I enroll in JMRP if I send through Google Workspace or Microsoft 365?

No. Enrollment runs through SNDS and is tied to the sending IP addresses, which in both of those cases belong to the provider rather than to you. The complaint data goes to the provider. Your usable signals are DMARC aggregate reports, bounce codes and, for Gmail recipients, Postmaster Tools.

### Why did my SNDS data stop appearing after about a year?

Most likely the authorization expired. Microsoft's SNDS FAQ says network access lapses ten months after approval and the holder of the range has to reattest, with reminder mail sent beforehand. If that reminder went to a mailbox nobody reads, the dashboard simply goes quiet. Re-request access for the same addresses.

---

Guanacos Tech is an independent consultancy with Google-certified engineers: email deliverability, Google Workspace and Google Cloud, in English and Spanish. Book a free 30-minute call: https://calendar.app.google/pq2seCCcch9U2GFV8