Using Microsoft SNDS and JMRP

31 March 2026 · 12 min read

Microsoft runs the inbound filtering for Outlook.com, Hotmail.com, Live.com, MSN.com and a large slice of corporate Microsoft 365 tenants. If you send any volume of email, Microsoft's filters are one of the three judges that decide whether your mail lands in the inbox or vanishes into Junk, alongside Gmail and Yahoo. Unlike Google, Microsoft gives you two free, direct feedback channels into that decision: SNDS (Smart Network Data Services) and JMRP (Junk Email Reporting Program, the Microsoft feedback loop). Used together, they tell you what your sending IPs look like from inside Microsoft's filter and who is hitting the "Junk" button on your mail.

This guide is specifically about those two Microsoft tools: how to enrol, what each field actually means, how the data connects to your DMARC and authentication setup, and where SNDS and JMRP stop being useful so you do not over-read them. It is not a generic "warm up your IP" piece. If you have already seen Outlook quietly throttle your mail and you want to understand why, this is the data source Microsoft hands you to find out.

A quick framing before we start. SNDS and JMRP report on IP reputation and recipient complaints. DMARC, SPF and DKIM report on domain authentication and alignment. They are different layers and they fail in different ways. You can have flawless DMARC at p=reject and still sit in Outlook's Junk folder because your sending IP has a poor complaint rate. The honest mental model is: authentication gets you permission to be judged as yourself, reputation decides whether being yourself is good enough. If you have not yet confirmed the authentication layer is solid, run your domain through the DMARC checker, SPF checker and DKIM checker first, because complaint and reputation data is far harder to interpret when authentication is failing underneath it.

What SNDS actually measures

SNDS is an IP-centric reporting portal at sendersupport.olc.protection.outlook.com/snds. You register the IP addresses you send from, prove you control them, and Microsoft then shows you aggregated, anonymised data about how mail from those IPs behaved when it reached Outlook.com mailboxes.

The core SNDS data view gives you, per IP per day:

• Activity period: the date range the row covers.
• RCPT commands / message count: roughly how many messages Microsoft saw from that IP. Volume is bucketed, not exact, so you get ranges like "1,000 to 9,999".
• Filter result: the headline reputation verdict. This is the field that matters most.
• Complaint rate: the proportion of delivered messages that recipients marked as junk, expressed as a band such as < 0.1%, 0.1% to 0.5%, or higher.
• Trap message period and trap hits: how many of Microsoft's spam-trap addresses your IP hit. Any non-zero number here is a red flag.

The filter result field is the one to internalise. Microsoft reports it in plain language:

GREEN  : mail from this IP is generally being delivered to the inbox
YELLOW : mail is being filtered to Junk for some recipients
RED    : mail is being filtered to Junk for most or all recipients

GREEN does not guarantee inbox placement for every message; it means the IP-level reputation is not actively working against you. YELLOW and RED are the states that explain the support ticket from a customer saying "your emails go to my junk folder on Outlook". When you see YELLOW or RED, the cause is almost always one of: a spike in complaint rate, trap hits, a sudden unexplained volume change, or a shared IP where someone else on the same address is sending badly.

The complaint rate band is the heart of it

Outlook's filtering is heavily complaint-driven. A recipient clicking "Junk" is the single strongest negative signal you can generate. SNDS shows you the band your complaint rate sits in, and the practical thresholds are stricter than most senders assume. Sustained complaint rates above roughly 0.3% start to drag reputation; above 0.5% you should expect throttling and YELLOW or RED filter results. For context, a 0.5% complaint rate means one in two hundred recipients is actively reporting you as spam, which over thousands of messages is a steady stream of negative votes into Microsoft's model.

SNDS gives you the band but not the addresses. To find out who complained, you need JMRP.

What JMRP actually measures

JMRP, the Junk Email Reporting Program, is Microsoft's feedback loop (FBL). When an Outlook.com user clicks "Junk" or "Report phishing" on one of your messages, JMRP forwards you a copy of that complaint as an ARF (Abuse Reporting Format) message to an address you nominate. You enrol per sending IP range at sendersupport.olc.protection.outlook.com/snds (JMRP shares the same portal and login).

The value of JMRP is that it closes the loop SNDS leaves open. SNDS says "your complaint rate is in the 0.1% to 0.5% band on this IP today". JMRP says "here are the specific messages that were reported, with enough headers to identify the campaign, the list, and often the recipient". With that, you can actually act: suppress the complaining address, identify the campaign that drew complaints, and stop mailing the segment that is unhappy.

A JMRP/ARF report is a structured email. The important parts look like this:

Content-Type: message/feedback-report

Feedback-Type: abuse
User-Agent: Microsoft-Antispam
Version: 1
Original-Mail-From: bounce-2381@mail.yourdomain.com
Arrival-Date: Mon, 22 Jun 2026 09:14:02 +0000
Source-IP: 203.0.113.24

Followed by the original message headers (and sometimes a redacted body). The redaction matters: Microsoft strips the recipient address from many ARF reports to protect user privacy, so you cannot always see exactly who complained. Where the recipient is redacted, you fall back on the headers you control, which is the entire reason the next section exists.

Make your complaints traceable before you need to

JMRP is only as useful as the headers you put into your own mail. If every message looks identical, a complaint tells you nothing actionable. Before you enrol, instrument your outbound mail so a single ARF report can be traced back to a campaign and a list:

• Add a custom header such as X-Campaign-ID and X-List-ID to every send. These survive into the ARF copy and let you map a complaint to its source instantly.
• Use a unique, parseable Return-Path / envelope sender per message or per recipient (VERP-style), for example bounce-<recipient-hash>@mail.yourdomain.com. Even when Microsoft redacts the To: line, the Original-Mail-From in the ARF report often preserves your envelope sender, which carries the encoded recipient. See header from versus envelope from for why these two addresses differ and why the envelope one is yours to design.
• Keep your DKIM signature aligned to your From: domain so the reported message is unambiguously yours and not a spoof. If you are unsure how selectors and d= values work, DKIM selectors explained covers it.

Do this and a JMRP complaint becomes a precise instruction: suppress this address, review this campaign, check this segment. Skip it and JMRP becomes a vague anxiety feed.

Enrolling: the practical steps

Both programmes use one Microsoft account and the same Sender Support portal. The flow is the same for SNDS and JMRP.

1. Create or sign in with a Microsoft account dedicated to deliverability operations, not someone's personal mailbox. People leave; the access should not.
2. Go to the SNDS portal and choose Request access to additional IP ranges. Enter the IPs or CIDR ranges you send Outlook-bound mail from. If you send through an ESP on shared IPs, you will not be able to register those, because you do not control them; that data belongs to the ESP.
3. Microsoft sends an authorisation email to a fixed set of role addresses at the domain that owns the IP's reverse DNS or the registered abuse contact (typically abuse@, postmaster@, and the addresses listed in the IP's WHOIS). You must be able to receive mail at one of those addresses to approve the request. This is the step most people get stuck on, because nobody monitors abuse@.
4. Click the authorisation link. SNDS data begins populating within a day or two; there is a natural lag because the data is daily-aggregated.
5. For JMRP, enrol the same IP ranges and specify the destination address that should receive ARF complaint reports. Point it at a parsed mailbox or an automation endpoint, not a human inbox, because volume can be significant.

A note on Microsoft 365 senders versus self-hosted senders. If you send through Microsoft 365 itself (your mail leaves via Microsoft's own outbound IPs), you do not register those IPs in SNDS, because they are Microsoft's, not yours. SNDS and JMRP are for senders operating their own sending IPs: self-hosted MTAs, on-premise gateways, or dedicated IPs from an ESP that has delegated control to you. If your authentication for Microsoft 365 itself is the open question, that is a DMARC and alignment problem, covered in DMARC for Microsoft 365, not an SNDS one.

Reading the data: what each signal means for deliverability

Here is how to translate SNDS and JMRP signals into decisions, with the honest caveats.

Filter result GREEN, complaint rate low, no trap hits

This is the healthy state. IP reputation is not your problem. If individual messages still land in Junk, the cause is now content, authentication alignment, or recipient-specific rules, not IP reputation. At this point the lever is your domain reputation and authentication, not your IP. Confirm DMARC is enforced and aligned with the DMARC checker, because a GREEN IP sending unauthenticated mail is leaving inbox placement on the table.

Filter result YELLOW or RED with an elevated complaint rate

This is the most common failure and it is almost always a list-quality problem, not an infrastructure one. The fix is operational, not technical:

• Stop mailing the segment generating complaints. Use JMRP to identify it.
• Tighten consent. Complaints spike when recipients do not remember opting in, which means single opt-in lists, purchased lists, or long-dormant lists.
• Make unsubscribe trivial and honour it instantly. Many "Junk" clicks are actually failed attempts to unsubscribe. Microsoft and the wider industry now expect a working one-click unsubscribe (List-Unsubscribe and List-Unsubscribe-Post headers) on bulk mail, and its absence directly raises complaint rates.

Reputation recovers slowly. Expect days to weeks of clean sending before YELLOW returns to GREEN, because Microsoft's model is weighted toward recent behaviour but does not reset instantly.

Trap hits above zero

Spam-trap hits are serious because traps are addresses that never opted in to anything: they are either recycled abandoned addresses or pristine addresses seeded to catch list-buying. A non-zero trap count tells you your list contains addresses you should not have. The response is list hygiene: remove hard bounces promptly, stop importing old or purchased data, and re-confirm any list segment you cannot account for. Traps are a strong negative signal and Microsoft weights them heavily.

Complaint rate sits in a band but JMRP is quiet

If SNDS shows complaints but JMRP reports are sparse, check three things. First, your JMRP enrolment may not cover all the IPs SNDS is reporting on; enrol the full range. Second, your ARF destination may be filtering or bouncing the reports; verify the mailbox accepts them. Third, ARF redaction means you see the complaint exists without seeing the recipient, which is expected, not a fault. The SNDS rate is the ground truth for "how bad"; JMRP is the tool for "which campaign".

Where SNDS and JMRP stop being useful

Honesty about the limits matters more than enthusiasm, because over-reading this data wastes time.

• It is IP-only, and IP reputation is a shrinking share of the decision. Microsoft, like Gmail, increasingly weights domain reputation on top of IP reputation. SNDS will not show you a domain-level problem. A clean IP can still see poor placement if your From: domain has a bad history. There is no Microsoft equivalent of Google Postmaster Tools' domain-reputation view, so DMARC aggregate reports become your proxy for domain-level visibility.
• It does not cover Microsoft 365 corporate filtering directly. SNDS reflects consumer Outlook.com mailboxes. A corporate Microsoft 365 tenant with its own Defender for Office 365 policies, connectors and tenant allow/block lists can filter your mail for reasons SNDS never sees. If a specific business recipient junks your mail while Outlook.com is GREEN, that is a tenant policy issue on their side.
• The data is aggregated and lagged. Volume is bucketed, complaint rate is banded, and everything is daily. You cannot debug a single message with SNDS. For per-message forensics you need the message headers and your own logs.
• JMRP recipients are often redacted. You frequently learn that a complaint happened without learning who made it, which is why instrumenting your own headers (above) is non-negotiable.

The right way to think about it: SNDS and JMRP are your IP-reputation early-warning system for the Microsoft consumer estate. They are necessary but not sufficient. The other half of the picture, domain reputation and authentication, comes from DMARC reporting.

Connecting Microsoft feedback to your DMARC data

This is where the two layers meet, and it is the part most senders miss. SNDS and JMRP tell you how your IPs and complaint rates look. DMARC aggregate reports (RUA) tell you which sources are sending under your domain, whether they authenticate, and whether they align. Microsoft is one of the mailbox providers that sends DMARC aggregate reports, so your DMARC data already contains Microsoft's view of your authentication, separate from the reputation view in SNDS.

Read them together:

• If SNDS is GREEN but your DMARC reports show Microsoft failing alignment for a source, you have an authentication gap that will eventually become a reputation problem. Fix the alignment before Microsoft's domain-reputation model penalises it. DMARC fails but SPF and DKIM pass is the usual culprit, and it is an alignment issue, not a pass/fail one.
• If SNDS is YELLOW or RED and DMARC alignment is clean, the problem is reputation and list quality, not authentication. No amount of DKIM tuning fixes a 0.5% complaint rate. Go clean the list.
• If both are bad, fix authentication and alignment first, because reputation signals are noisier and less trustworthy when Microsoft cannot even confirm the mail is genuinely yours.

To make sense of the DMARC side of this, parse your aggregate reports rather than eyeballing the XML. Drop a report into the DMARC report analyzer, or read reading your first DMARC report and DMARC reports show unknown sources to learn what Microsoft's rows are telling you. Microsoft's reporting org name appears in those reports as Outlook.com or Microsoft Corporation, so you can isolate exactly what Microsoft sees.

A practical monitoring routine

Pull this into a repeatable weekly habit rather than a panic response when a customer complains.

1. Weekly: check SNDS filter result and complaint band per IP. Note any movement from GREEN toward YELLOW, any non-zero trap hits, and any complaint band shift upward. Movement is the signal; a steady GREEN needs no action.
2. Continuously: parse JMRP/ARF reports into suppression. Every complaint should automatically suppress the address (where visible) and tag the campaign. This is the single highest-value automation, because acting on complaints is what keeps the SNDS band low in the first place.
3. Weekly: review DMARC aggregate reports for the Microsoft source rows. Confirm Microsoft is reporting pass for DKIM alignment on your legitimate streams. A drift here is an early authentication warning.
4. Monthly: reconcile the two views. If complaint rate is creeping up while authentication is clean, it is a list and content problem. If authentication drifts while complaints stay flat, it is an infrastructure or DNS change. Knowing which layer moved tells you which team to involve.

The reason to run SNDS, JMRP and DMARC together is that no single one of them sees the whole picture. SNDS sees your IPs at Outlook.com. JMRP sees the complaints those IPs generate. DMARC sees whether the world (Microsoft included) can confirm the mail is authentically yours. Watch all three and a deliverability dip at Outlook becomes a diagnosable event instead of a mystery.

The practical takeaway

Microsoft hands self-hosted senders two free, direct windows into its filtering: SNDS for IP reputation, complaint bands and trap hits, and JMRP for the individual complaints behind those bands. Enrol both for every IP you control, instrument your outbound mail with traceable headers and a parseable envelope sender so JMRP complaints become actionable, and treat the SNDS filter result as your weekly health check. Then remember the limit: this is IP and complaint data only. It says nothing about whether Microsoft can confirm the mail is genuinely yours, and increasingly that domain-level authentication is what decides inbox placement.

That second half is the part DMARC owns. Before you spend a week chasing a YELLOW filter result, make sure your authentication is solid and aligned, because reputation data is only trustworthy once Microsoft can confirm you are who you claim to be. Check the authentication layer with the DMARC checker, parse Microsoft's own verdict in your aggregate reports with the DMARC report analyzer, and if you would rather not run the DMARC, SPF, DKIM, MTA-STS and BIMI plumbing yourself, our hosted service takes a domain from p=none to p=reject without breaking a single legitimate Outlook send, and emails you change alerts the moment a source or record drifts. SNDS and JMRP watch your IPs; let us watch your domain.