What do the SNDS filter results GREEN, YELLOW, and RED mean?

The filter result is the share of a sending IP's daily mail that Microsoft's spam filtering flagged as spam. GREEN means less than 10% of the day's messages were spam-flagged — a healthy IP. YELLOW means between 10% and 90% were flagged — reputation is degrading and mail is increasingly junk-foldered. RED means more than 90% were flagged — the IP is effectively junk-foldered or blocked for Outlook.com recipients. The verdict is per IP per day, so one bad campaign shows up as a one-day YELLOW/RED transition while a compromised server shows as a sustained RED.

What is a healthy complaint rate in SNDS?

SNDS renders anything below 0.1% as "< 0.1%", which is the healthy baseline — fewer than one complaint per thousand delivered messages. Sustained complaint rates above roughly 0.3% are the industry threshold where junk-folder placement begins across major mailbox providers, and rates above 1% indicate a serious list-quality or consent problem. Because the SNDS complaint rate only counts Outlook.com users who clicked "Junk", the true dissatisfaction rate is usually higher than the reported number — many users delete unwanted mail without reporting it.

Why did my SNDS Automated Data Access key stop working after about 30 days?

Since the June 2026 SNDS overhaul, Automated Data Access keys and links silently expire roughly every 30 days. Expiry is silent: the data URL does not return an HTTP 401 — it returns a 404, an empty body, or an HTML login page instead of CSV, so naive scripts keep "succeeding" while collecting nothing. The fix is to sign in to the SNDS portal (substrate.office.com), generate a fresh Automated Data Access key, and update whatever tooling pulls the CSVs. Monitoring tools should treat two consecutive failed daily pulls as key expiry and alert the operator to rotate the key.

What changed in the June 2026 Microsoft SNDS/JMRP overhaul?

Four things. First, the portal moved from sendersupport.olc.protection.outlook.com to substrate.office.com on 2026-06-08, and the legacy automated-access URLs stopped working on 2026-06-22. Second, Automated Data Access keys now silently expire roughly every 30 days and must be re-generated. Third, JMRP complaint reports are redacted since 2026-06-11 — no complainant email address and no message body — so senders must embed custom X-headers (such as X-Campaign-ID) for attribution. Fourth, spam-trap hit counts were removed from SNDS data reports as of 2026-07-22.

How is SNDS different from DMARC reporting?

They answer different questions from different sides. DMARC aggregate reports (RFC 7489) are domain-centric and receiver-agnostic: every participating mailbox provider tells the DOMAIN owner how messages claiming that domain authenticated (SPF/DKIM alignment), regardless of which IPs sent them. SNDS is IP-centric and Microsoft-only: it tells the IP OWNER how the Outlook.com network filtered traffic from those IPs, regardless of which domains the mail claimed. DMARC detects spoofing and authentication gaps; SNDS detects reputation and content problems on infrastructure you already control. Serious senders monitor both: DMARC for identity, SNDS/JMRP for Microsoft-network reputation.

Who can enroll in SNDS and JMRP?

Only the owner of the sending IP space. Microsoft verifies control by emailing an authorization request to the technical contacts of the IP range (WHOIS/abuse contacts or the network's registered admin), so you can only monitor ranges you or your network provider actually control. Senders on shared infrastructure (a SaaS email provider's IPs) cannot enroll those IPs themselves — the provider owns the range and runs the enrollment; ask the provider for their SNDS/JMRP posture instead. Once enrolled, one SNDS account covers all of that owner's registered ranges, and JMRP enrollment is configured from the same portal.

Microsoft SNDS and JMRP Explained: Outlook.com Sender Reputation, GREEN/YELLOW/RED Filter Results, Complaint Feedback, and the 2026 Program Overhaul

Q: What is Microsoft SNDS?

SNDS (Smart Network Data Services) is Microsoft's free sender-reputation portal for the Outlook.com consumer mail network (Outlook.com, Hotmail, Live, MSN mailboxes). The owner of a sending IP range registers the range and gets a per-IP, per-day report of how Microsoft's network experienced that IP's traffic: SMTP activity window, RCPT and DATA command counts, message recipients, a spam-filter verdict (GREEN, YELLOW, or RED), the complaint rate from Outlook.com users, and sample HELO / MAIL FROM values. A separate report lists any of your IP ranges currently blocked by Outlook.com. Since June 2026 the portal lives at substrate.office.com; data access is per-IP-owner only.

Q: What is JMRP (Junk Mail Reporting Program)?

JMRP is Microsoft's complaint feedback loop for the Outlook.com network. After enrolling a sending IP range, every time an Outlook.com user clicks "Junk" on a message from one of those IPs, Microsoft emails an ARF (Abuse Reporting Format, RFC 5965) complaint report to the address the sender registered. Senders use JMRP reports to suppress complainers from future mailings and to spot campaigns that generate disproportionate complaints. Since 2026-06-11 the reports are redacted: the complaining user's address and the message body are removed, so attribution relies on the Message-ID, Authentication-Results, Received-SPF headers, and any custom X-headers (for example X-Campaign-ID) the sender embedded in the original message.

Q: Why did my SNDS Automated Data Access key stop working after about 30 days?

Since the June 2026 SNDS overhaul, Automated Data Access keys and links silently expire roughly every 30 days. Expiry is silent: the data URL does not return an HTTP 401 — it returns a 404, an empty body, or an HTML login page instead of CSV, so naive scripts keep "succeeding" while collecting nothing. The fix is to sign in to the SNDS portal (substrate.office.com), generate a fresh Automated Data Access key, and update whatever tooling pulls the CSVs. Monitoring tools should treat two consecutive failed daily pulls as key expiry and alert the operator to rotate the key.

Q: What changed in the June 2026 Microsoft SNDS/JMRP overhaul?

Four things. First, the portal moved from sendersupport.olc.protection.outlook.com to substrate.office.com on 2026-06-08, and the legacy automated-access URLs stopped working on 2026-06-22. Second, Automated Data Access keys now silently expire roughly every 30 days and must be re-generated. Third, JMRP complaint reports are redacted since 2026-06-11 — no complainant email address and no message body — so senders must embed custom X-headers (such as X-Campaign-ID) for attribution. Fourth, spam-trap hit counts were removed from SNDS data reports as of 2026-07-22.

Q: How is SNDS different from DMARC reporting?

They answer different questions from different sides. DMARC aggregate reports (RFC 7489) are domain-centric and receiver-agnostic: every participating mailbox provider tells the DOMAIN owner how messages claiming that domain authenticated (SPF/DKIM alignment), regardless of which IPs sent them. SNDS is IP-centric and Microsoft-only: it tells the IP OWNER how the Outlook.com network filtered traffic from those IPs, regardless of which domains the mail claimed. DMARC detects spoofing and authentication gaps; SNDS detects reputation and content problems on infrastructure you already control. Serious senders monitor both: DMARC for identity, SNDS/JMRP for Microsoft-network reputation.

Q: Who can enroll in SNDS and JMRP?

Only the owner of the sending IP space. Microsoft verifies control by emailing an authorization request to the technical contacts of the IP range (WHOIS/abuse contacts or the network's registered admin), so you can only monitor ranges you or your network provider actually control. Senders on shared infrastructure (a SaaS email provider's IPs) cannot enroll those IPs themselves — the provider owns the range and runs the enrollment; ask the provider for their SNDS/JMRP posture instead. Once enrolled, one SNDS account covers all of that owner's registered ranges, and JMRP enrollment is configured from the same portal.

Microsoft SNDS and JMRP Explained: Outlook.com Sender Reputation, GREEN/YELLOW/RED Filter Results, Complaint Feedback, and the 2026 Program Overhaul

Operator reference for Microsoft's two sender-reputation feedback programs for the Outlook.com consumer network: what SNDS reports per IP per day (SMTP activity, RCPT/DATA counts, GREEN/YELLOW/RED filter results, complaint rates, blocked ranges), how JMRP delivers redacted ARF (RFC 5965) complaints since June 2026 and how to attribute them via Message-ID and custom X-headers, the Automated Data Access key workflow with its silent 30-day expiry, the substrate.office.com portal migration, and how SNDS/JMRP complements domain-centric DMARC reporting.

This reference is provided in English. SNDS and JMRP are Microsoft programs documented in English, and the canonical vocabulary (filter result, Automated Data Access, ARF per RFC 5965) does not translate. We keep the body in the source language so technical terms remain consistent with the programs' own documentation.

TL;DR

SNDS (Smart Network Data Services) and JMRP (Junk Mail Reporting Program) are Microsoft's two free sender-reputation feedback programs for anyone who owns IP space that sends mail to Outlook.com, Hotmail, Live, or MSN mailboxes. SNDS reports how Microsoft's filters experienced each of your IPs per day; JMRP forwards a complaint report every time an Outlook.com user clicks "Junk" on your mail.

SNDS is IP-centric and Microsoft-only: per IP per day you get SMTP activity, RCPT / DATA command counts, message recipients, a filter result — GREEN (< 10 % spam-flagged), YELLOW (10–90 %), RED (> 90 %) — the Outlook.com user complaint rate (healthy is "< 0.1 %"), and sample HELO / MAIL FROM values.
JMRP is the complaint feedback loop: each "Junk" click from an Outlook.com user produces an ARF report (RFC 5965) emailed to your registered address. Since 2026-06-11 the reports are redacted — no complainant address, no body — attribution runs on Message-ID and custom X-headers such as X-Campaign-ID.
June 2026 overhaul: the portal moved to substrate.office.com (2026-06-08), legacy automated URLs died (2026-06-22), Automated Data Access keys now silently expire about every 30 days, and spam-trap hit counts were removed from the data (2026-07-22).
Enrollment requires IP ownership: Microsoft authorizes access via the IP range's registered network contacts. Senders on shared provider IPs monitor through their provider, not directly.
SNDS/JMRP complements DMARC: DMARC aggregate reports are domain-centric and cover all receivers; SNDS is IP-centric and covers only the Microsoft consumer network. Monitoring both closes the identity view AND the reputation view.

What is Microsoft SNDS?

SNDS (Smart Network Data Services) is Microsoft's free sender-reputation portal that shows the owner of a sending IP range how the Outlook.com consumer mail network — Outlook.com, Hotmail, Live, and MSN mailboxes — experienced traffic from each of those IPs, one row per IP per day.

Where a blocklist lookup answers "is my IP listed anywhere right now", SNDS answers the more useful operational question: "what did Microsoft's spam filtering actually do with the mail my IPs sent yesterday". The data is first-party — it comes from the same filtering pipeline that decides whether your message lands in the inbox or the junk folder of hundreds of millions of consumer mailboxes.

Microsoft publishes a data row for an IP on days when the IP generated meaningful traffic to the network (roughly 100 or more messages); quiet IPs simply have no row that day. Reporting days are tracked in Pacific time on Microsoft's side, and a day's data becomes available once the day is complete.

SNDS matters because the Outlook.com network is one of the three consumer mailbox pools (with Gmail and Yahoo) that dominate B2C deliverability. A RED filter verdict at SNDS means your mail is effectively invisible to those users — regardless of how clean your SPF, DKIM, and DMARC are.

What is JMRP (Junk Mail Reporting Program)?

JMRP (Junk Mail Reporting Program) is Microsoft's complaint feedback loop for the Outlook.com network: after a sender enrolls their IP ranges, every time an Outlook.com user clicks the Junk button on a message from one of those IPs, Microsoft emails an abuse report to the address the sender registered.

The report format is ARF — the Abuse Reporting Format standardized in RFC 5965, with usage guidance for mailbox providers in RFC 6650. An ARF message is a three-part MIME container: a human-readable summary, a machine-readable message/feedback-report part (Feedback-Type: abuse, Source-IP, Arrival-Date and friends), and the original message or its headers.

Operationally, JMRP serves two purposes. First, list hygiene: a user who clicks "Junk" has withdrawn consent — continuing to mail them increases your complaint rate and erodes the very SNDS reputation described above, so the complainer must be suppressed from future sends. Second, campaign diagnostics: complaints clustering on one campaign, one list segment, or one mail stream point exactly at the content or acquisition source that recipients reject.

Enrollment, Automated Data Access keys, and the 30-day expiry

Who can enroll

Only the owner of the sending IP space can register a range. Microsoft verifies control by sending an authorization mail to the range's registered network contacts (the WHOIS / abuse / admin contacts of the netblock), so you can monitor exactly the address space you or your network provider control — and nothing else. One SNDS account covers all of that owner's registered ranges. JMRP enrollment is configured from the same portal and applies per range.

If you send through a shared provider (a SaaS email platform, a marketing ESP), the provider owns the IPs and runs the enrollment — you cannot enroll their ranges yourself. Ask the provider how they monitor SNDS/JMRP and how complaint suppression feeds back into your account.

The 2026 portal migration

In June 2026 Microsoft overhauled the programs. The portal moved to substrate.office.com on 2026-06-08, and the legacy sendersupport.olc.protection.outlook.com automated-access URLs stopped resolving data on 2026-06-22. Any script still fetching from the legacy host is collecting nothing.

Automated Data Access

Beyond the interactive dashboard, SNDS offers Automated Data Access: a key-based URL that returns the same data as CSV, suitable for daily cron ingestion. Two endpoints matter:

# Per-IP daily data (latest complete day, or a specific date)
https://substrate.office.com/ip-domain-management-snds/snds/data.aspx?key=YOUR_KEY
https://substrate.office.com/ip-domain-management-snds/snds/data.aspx?key=YOUR_KEY&date=7/15/2026

# Current blocked-range status
https://substrate.office.com/ip-domain-management-snds/snds/ipStatus.aspx?key=YOUR_KEY

The key silently expires roughly every 30 days. This is the single most important operational fact about post-2026 SNDS automation. Expiry is silent in the worst way: the endpoint does not return an HTTP 401 — it returns a 404, an empty 200 body, or an HTML login page instead of CSV. A naive script that only checks the HTTP status keeps "succeeding" while your monitoring quietly goes blind. Robust tooling treats any non-CSV response as a failed pull, flags the key as expired after two consecutive failures, and alerts the operator to generate a fresh key in the portal.

Parse the CSV by header name, never by column position: Microsoft has changed the column set before (spam-trap hit counts were removed on 2026-07-22) and positional parsers break silently when columns move.

The SNDS per-IP data report, field by field

Each row of the data report describes one sending IP on one reporting day:

IP address: The sending IPv4 address the row describes. SNDS reporting is per literal IP, not per domain — one row per IP per day.
Activity start / Activity end: The first and last hour (Pacific time) in which the IP was seen sending. A server that should only send during business hours but shows 24-hour activity is a classic compromise indicator.
RCPT commands: How many SMTP RCPT TO commands the IP issued — attempted recipients, including ones the network rejected at the SMTP level.
DATA commands: How many SMTP DATA commands followed — messages actually transmitted. A large gap between RCPT and DATA counts means recipients were being rejected before message transmission (bad addresses, early reputation blocks, or a dictionary-attack pattern).
Message recipients: Recipients on messages that were actually transferred — the delivered-traffic denominator the complaint rate is computed against.
Filter result — GREEN / YELLOW / RED: The share of the day's mail Microsoft's filtering flagged as spam. GREEN: under 10 % flagged — healthy. YELLOW: 10–90 % flagged — reputation degrading, mail increasingly junk-foldered. RED: over 90 % flagged — the IP is effectively dead to Outlook.com recipients. Track transitions: GREEN→YELLOW on one day is a campaign problem; sustained RED is an infrastructure or compromise problem.
Complaint rate: The percentage of delivered messages that Outlook.com users reported as junk. "< 0.1 %" is the healthy floor Microsoft renders for anything below one complaint per thousand; sustained rates above ~0.3 % are where junk-folder placement starts industry-wide, and > 1 % signals a consent or list-quality failure. Remember the number undercounts real dissatisfaction — most unhappy users delete without reporting.
Trap hits (removed 2026-07-22): Historical field: the count of messages the IP sent to Microsoft's spam-trap addresses. Microsoft removed trap-hit counts from SNDS reports as of 2026-07-22 — treat the column as permanently optional in any parser, and treat historical non-zero values as the serious list-quality signal they always were.
Sample HELO / Sample MAIL FROM: Example SMTP HELO and MAIL FROM values observed from the IP that day. A HELO or bounce domain you do not recognize on your own IP is a strong compromise or misconfiguration indicator.
Comments: Free-form annotations from Microsoft, populated rarely (typically for blocks or special handling).

The IP-status (blocked ranges) report

The second SNDS report is a point-in-time snapshot of your registered ranges' block status at the Outlook.com network edge: each row names a range (first IP – last IP), whether it is currently blocked, and a reason string when Microsoft provides one.

A block here is Microsoft-network-specific — it is not a public DNSBL listing and will not show up in a blocklist lookup. That makes the ipStatus report the only reliable way to learn that Outlook.com specifically has stopped accepting your mail. When a range shows blocked, the remediation path is Microsoft's sender-support / delisting process for the Outlook.com network; fix the underlying cause first (see the SNDS data for the offending IPs' filter results and complaint rates), because repeat blocks after delisting get progressively harder to lift.

Inside a JMRP complaint: ARF, the 2026 redaction, and attribution

A JMRP complaint arrives as an ARF message per RFC 5965: a multipart/report; report-type=feedback-report container with three parts:

Content-Type: multipart/report; report-type=feedback-report; boundary="..."

--boundary
Content-Type: text/plain                      # human-readable summary

This is an email abuse report for an email message received
from IP 203.0.113.25 ...

--boundary
Content-Type: message/feedback-report          # machine-readable block

Feedback-Type: abuse
User-Agent: SMP-FBL
Version: 1
Source-IP: 203.0.113.25
Arrival-Date: Tue, 14 Jul 2026 08:31:02 +0000

--boundary
Content-Type: message/rfc822-headers           # redacted original (headers only)

Message-ID: <campaign-4711.42@mail.example.com>
Authentication-Results: hotmail.com; spf=pass ...; dkim=pass ...; dmarc=pass ...
Received-SPF: pass (...)
X-Campaign-ID: summer-sale-2026-wave3
From: [redacted]
To: [redacted]
--boundary--

Since 2026-06-11 Microsoft redacts JMRP reports. The complaining user's email address is removed, the message body is removed, and address-like values are masked even inside custom headers. The days of reading the To: header to suppress the complainer are over. What survives redaction — and therefore what your attribution must be built on — is:

Message-ID — the primary key. If your sending system logs the Message-ID of every send together with the recipient, campaign, and list segment, one join recovers everything the redaction hid.
Custom X-headers — e.g. X-Campaign-ID, X-Mailer-RunID, or an opaque per-recipient token. Values that look like email addresses are masked, so use opaque IDs, not addresses.
Authentication-Results and Received-SPF — how the complained-about message authenticated, useful for distinguishing your genuine mail from spoofed mail complained about "as you".
Source-IP and Arrival-Date from the feedback-report part — which of your IPs sent it and when.

The operational consequence is simple: embed an opaque per-send identifier in a custom header before you need it. Attribution is only possible for mail that carried the identifier when it was sent — you cannot retrofit it onto complaints already in flight.

SNDS/JMRP vs DMARC reporting — what each one sees

SNDS/JMRP and DMARC aggregate reporting are complementary feedback channels, not alternatives. DMARC (RFC 7489) reports on your domain from every participating receiver; SNDS reports on your IPs from exactly one network.

Dimension	SNDS / JMRP	DMARC aggregate reports
Subject of the report	Your sending IP addresses	Your domain (header From)
Who reports	Microsoft only (Outlook.com consumer network)	Every participating receiver (Google, Microsoft, Yahoo, …)
What it measures	Filtering outcome, complaint rate, blocks — reputation	SPF/DKIM alignment outcomes — authentication
Detects spoofing of your domain	No (only traffic from YOUR registered IPs)	Yes (reports cover any IP claiming your domain)
Detects content/list-quality problems	Yes (filter verdicts + complaints)	No (a spam campaign can be 100 % DMARC-aligned)
Enrollment requirement	Proof of IP-range ownership	A DNS `rua=` tag — domain control only
Data format	CSV (SNDS) + ARF per RFC 5965 (JMRP)	Compressed XML per RFC 7489 Appendix C
Per-recipient feedback	JMRP: one report per Junk click (redacted since 2026-06)	No (aggregated counts only)

The practical reading: a deliverability incident at Outlook.com with clean DMARC reports points at reputation (check SNDS filter results and complaint rates); DMARC failures with clean SNDS data point at authentication or spoofing. Seeing both streams side by side is what turns guessing into diagnosis — which is exactly why DMARC Analyzer ingests both.

Best practices

Enroll every range you send from — in both SNDS and JMRP. The data is free, first-party, and invisible until you register.
Automate the daily pull and alert on transitions, not states. A persistently YELLOW IP does not need a daily email; a GREEN→YELLOW flip, a complaint-rate crossing above 0.3 %, or a new blocked range does.
Plan for the 30-day key expiry. Treat two consecutive failed pulls as an expired key, alert the operator, and rotate the key at the portal. Never rely on HTTP status alone to detect failure.
Embed an opaque campaign/send identifier in a custom X-header (e.g. X-Campaign-ID) in all outbound mail, and log Message-ID → recipient at send time. Post- redaction, these are your only JMRP attribution keys.
Suppress every JMRP complainer immediately. A "Junk" click is a consent withdrawal; mailing that user again converts one complaint into a recurring complaint-rate tax.
Parse SNDS CSVs by header name. Columns have been added and removed (trap hits, 2026-07-22); positional parsing fails silently.
Correlate with DMARC data. Join SNDS per-IP rows against the source-IP breakdown in your DMARC aggregate reports to see whether an IP with a degrading filter result is also drifting on authentication.
Watch the RCPT-vs-DATA gap. A widening gap means recipients are rejected before message transfer — early-warning for reputation blocks and list decay before the filter verdict moves.

Common mistakes

Still fetching from the legacy host. Problem: scripts pointed at sendersupport.olc.protection.outlook.com stopped getting data on 2026-06-22 — often without erroring. Fix: move automation to the substrate.office.com endpoints and verify actual CSV rows arrive.
Checking only the HTTP status of automated pulls. Problem: an expired key returns 200-with-empty-body or an HTML login page. Fix: validate the body is CSV with a recognizable header row; treat anything else as failure.
No suppression pipeline behind JMRP. Problem: complaints are received but never remove recipients from lists — the complaint rate compounds. Fix: wire an automated suppression flow keyed on Message-ID / campaign-ID lookup.
Address-shaped custom headers. Problem: since the 2026 redaction, values that look like email addresses are masked even in X-headers, destroying the attribution they were meant to carry. Fix: use opaque tokens.
Alerting on every bad day. Problem: a stable-YELLOW IP that emails the on-call daily trains everyone to ignore SNDS alerts. Fix: transition-gated alerting (color got worse, threshold newly crossed, range newly blocked).
Assuming SNDS covers Microsoft 365. Problem: SNDS reflects the consumer network (Outlook.com/Hotmail); enterprise Microsoft 365 tenant filtering is a separate system with separate reputation. Fix: treat SNDS as the consumer-side signal; monitor enterprise deliverability via bounces and DMARC.
Treating "< 0.1 %" as an exact zero. Problem: the healthy floor is a display convention — complaints may exist below it. Fix: read "< 0.1 %" as "at or below the healthy baseline", and keep watching JMRP volume.

Troubleshooting

My automated pull suddenly returns an empty file or HTML: Cause: the Automated Data Access key expired (silent ~30-day lifetime) or the fetch still targets the dead legacy host. Fix: sign in at the portal, generate a fresh key, update the fetch URL to the substrate.office.com endpoint, and add non-CSV-body detection to the pipeline.
An IP flipped GREEN → YELLOW overnight: Cause: usually one campaign — a content pattern, a stale segment, or a purchased list. Fix: identify the day's sends from that IP, check the complaint rate on the same row, and cross-reference JMRP complaints (campaign X-header) from that date.
An IP is sustained RED: Cause: ongoing spam-classified traffic — commonly a compromised host, an open relay, or an abusive tenant on shared infrastructure. Fix: check activity hours and sample HELO / MAIL FROM for traffic you do not recognize; quarantine the host; after remediation expect days-to-weeks of clean traffic before the verdict recovers.
A range appears in the blocked-ranges report: Cause: Outlook.com's edge is refusing mail from the range — typically after sustained RED verdicts, trap hits, or complaint spikes. Fix: remediate the cause first, then use Microsoft's sender-support process for the Outlook.com network to request delisting; repeat blocks get harder to lift.
JMRP complaints stopped arriving: Cause: the registered destination mailbox is bouncing or full, enrollment lapsed during the 2026 portal migration, or the ranges were re-registered without re-enrolling JMRP. Fix: verify the destination address accepts mail and re-check JMRP enrollment in the portal. Note: zero complaints with healthy volume is possible but rare — validate before celebrating.
I cannot attribute a redacted complaint to a recipient: Cause: the original message carried no opaque identifier, and send-time Message-ID logging is missing. Fix: log Message-ID → recipient at send time and embed a campaign header going forward; complaints already received without identifiers are attributable only to (source IP, arrival date) granularity.

Frequently Asked Questions

What is Microsoft SNDS?: SNDS (Smart Network Data Services) is Microsoft's free sender-reputation portal for the Outlook.com consumer network: per-IP, per-day filtering verdicts, complaint rates, activity data, and a blocked-ranges report for IP owners who register their ranges.
What is JMRP (Junk Mail Reporting Program)?: Microsoft's complaint feedback loop: every "Junk" click by an Outlook.com user on mail from your enrolled IPs produces an ARF (RFC 5965) report to your registered address — redacted since 2026-06-11 (no complainant address, no body).
What do the SNDS filter results GREEN, YELLOW, and RED mean?: The share of the day's mail from an IP that Microsoft flagged as spam: GREEN under 10 %, YELLOW 10–90 %, RED over 90 %.
What is a healthy complaint rate in SNDS?: "< 0.1 %" is the healthy baseline; sustained rates above ~0.3 % are where junk-folder placement starts; above 1 % indicates a consent or list-quality failure.
Why did my SNDS Automated Data Access key stop working after about 30 days?: Post-2026 Automated Data Access keys silently expire roughly every 30 days, returning 404 / empty body / login HTML instead of a 401. Generate a fresh key at the portal and rotate it in your tooling.
What changed in the June 2026 Microsoft SNDS/JMRP overhaul?: Portal moved to substrate.office.com (2026-06-08); legacy automated URLs died (2026-06-22); keys expire every ~30 days; JMRP reports are redacted (2026-06-11); trap-hit counts removed from SNDS data (2026-07-22).
How is SNDS different from DMARC reporting?: DMARC is domain-centric, all-receiver, and measures authentication; SNDS is IP-centric, Microsoft-only, and measures reputation. They answer different questions and are monitored together.
Who can enroll in SNDS and JMRP?: Only the owner of the sending IP space — Microsoft authorizes via the range's registered network contacts. Senders on shared provider IPs monitor through their provider.

Monitor SNDS and JMRP from your DMARC dashboard

DMARC Analyzer's SNDS & JMRP monitor pulls your SNDS data automatically every day from a pasted Automated Data Access key, tracks per-IP filter results and complaint rates over time, detects the silent 30-day key expiry and emails you a rotation notice, alerts on reputation transitions (never daily repeats), ingests redacted JMRP ARF complaints with Message-ID / X-header attribution, and shows it all next to your DMARC aggregate data — the two feedback channels this page explains, on one screen.