Microsoft SNDS (Smart Network Data Services) is one of the most underutilised tools in the commercial email sender's toolkit. Al Iverson at Spam Resource documented some of the January 2026 SNDS changes in his tracking of the Microsoft deliverability landscape, but the practical implications of these changes for senders who are actually trying to use SNDS for deliverability improvement have not been thoroughly covered. SNDS is not Gmail Postmaster Tools. It provides different data, requires different interpretation, and tells you things about Microsoft deliverability that Postmaster Tools fundamentally cannot tell you about Gmail.
This guide covers SNDS as it actually operates in 2026, including what changed in the first quarter, how to read the data without being misled by its limitations, and how to build it into a functional Microsoft deliverability monitoring practice.
What SNDS Is and Why Most Senders Underuse It
SNDS is Microsoft's sender reputation portal for Outlook.com and Hotmail.com (the consumer Microsoft email products). You register your sending IPs at postmaster.live.com, and Microsoft provides daily data on how those IPs performed delivering to Outlook.com/Hotmail.com recipients: how much email was sent, what fraction was delivered versus filtered, the complaint rate from Outlook users who marked email as junk, and — distinctively — whether any email from the IP hit Microsoft's spam trap addresses.
The trap data is the part most senders don't use and should. Gmail Postmaster Tools does not show spam trap data. Your ESP bounce reports don't show spam trap data — traps are typically valid addresses that accept email, so they never generate a bounce. You can be hitting spam traps consistently and have no way to know unless you are looking at SNDS. The trap data SNDS provides is the closest thing to an early warning system for list quality problems that is available in standard sender tooling.
Why SNDS is underutilised: the registration process is moderately annoying (requires proving IP ownership via ARIN WHOIS verification for North American IPs), the interface is dated, and the data is IP-level rather than domain-level, which means you need to register every sending IP individually. For senders with large IP pools this registration overhead is real. But the data is valuable enough that the registration effort is worth it for any sender with significant Microsoft-domain recipient volume — and almost everyone sending commercial email at scale has significant Microsoft-domain recipient volume.
What Changed in Early 2026
The January 2026 SNDS changes documented by Al Iverson at Spam Resource were less dramatic than the headline "changes" suggested — they were primarily interface and data presentation updates rather than fundamental changes to what SNDS measures or how it operates. However, there are a few specific changes worth understanding:
JMRP platform migration (separate from SNDS but related): Microsoft's JMRP (Junk Mail Reporting Program) — the FBL equivalent that sends complaint reports — was rebuilt on a new platform and the old JMRP enrollment ended. Senders who were enrolled in the old JMRP system needed to re-enroll in the new system, which is accessible through the SNDS portal. If you were enrolled in JMRP before mid-2025 and have not re-enrolled since, you may have been silently missing complaint data. This is worth checking immediately.
Interface updates: The SNDS dashboard received a visual refresh in the January 2026 timeframe that affected how some data is presented but not what data is available. Senders who bookmarked specific SNDS pages or built monitoring scripts that scraped the old interface may need to update their bookmarks or scripts to reflect the new URLs.
Data access API improvements: Microsoft made minor updates to the SNDS Data Access API (available to senders with registered IPs at postmaster.live.com) that provide better programmatic access to SNDS data. For senders who have been using the API to pull SNDS data into their own monitoring systems, review the updated API documentation to see if the improvements affect your integration.
What did NOT change: The fundamental data SNDS provides (delivery rate, complaint rate, trap hits), the IP-level granularity (still IP-based, not domain-based), the registration process, or the colour-coded status system. Reports that SNDS "fundamentally changed" in early 2026 overstate the modifications — the January changes were evolutionary, not revolutionary.
The JMRP Transition: What You Need to Do Right Now
This is the most operationally important SNDS-related action for most senders in 2026. If you are enrolled in SNDS and were previously receiving JMRP complaint reports, verify that your enrollment transferred to the new platform and that you are currently receiving complaint reports:
# Verification steps: # 1. Log in to postmaster.live.com # 2. Look for a "JMRP" or "Complaint Feedback" section # 3. Verify your sending IPs are enrolled and a working email address is configured # 4. Send a test campaign to Microsoft-domain recipients # 5. Check whether complaint reports arrive at the configured address within 24 hours # If you find you are NOT receiving JMRP reports: # 1. Go to postmaster.live.com → JMRP enrollment # 2. Re-register each sending IP for JMRP # 3. Provide an email address that can receive JMRP reports # (typically a distribution group or a deliverability monitoring mailbox) # 4. JMRP reports look like forwarded messages with the original email content # and X-JMRP headers identifying the complaint event # What you lose without JMRP: # - Per-message complaint data (which specific campaigns generated complaints) # - Recipient identification (Microsoft redacts the recipient address, but # you can use X-Campaign-ID custom headers to identify the campaign) # - The ability to suppress specific complainers
The JMRP transition gap — the period between when the old JMRP stopped sending reports and when senders re-enrolled in the new system — means that some senders have been operating without Microsoft complaint data for months without knowing it. During that gap, complaint rate at Microsoft domains was building invisible reputation damage that shows in SNDS colour status but without the per-message data that would let you identify which list segments are generating the complaints. If your SNDS shows Yellow or Red status for any sending IP, and you have not been receiving JMRP data, the first diagnostic step is to confirm JMRP enrollment on the new platform before attempting other remediation.
Reading SNDS Data: The Metrics That Actually Matter
SNDS provides the following data fields for each registered IP, per day:
| SNDS field | What it measures | Target value |
|---|---|---|
| RCPT | Number of RCPT TO commands (email sent to Microsoft recipients) | — (baseline, not a quality signal) |
| DATA | Number of emails accepted by Microsoft after DATA command | Should be close to RCPT (low rejection rate) |
| Complaint rate | Fraction of delivered emails marked as junk by Outlook.com users | Below 0.3% (Yellow), below 0.5% to avoid Red |
| Trap rate | Fraction of email sent to Microsoft spam trap addresses | Zero. Any nonzero value requires immediate investigation |
| Status | Green/Yellow/Red colour based on complaint and trap data | Green for all IPs |
The ratio of DATA to RCPT is worth watching — a significant gap (say, RCPT of 10,000 and DATA of 8,000) indicates Microsoft is rejecting 20% of your messages at the SMTP level before accepting them. This rejection is invisible in your ESP delivery metrics (which record delivery as "accepted"), but it shows up in SNDS as a RCPT/DATA gap. If you see this pattern, check the sending IP's authentication configuration — most pre-DATA rejections are PTR-related (550 5.7.25) or authentication-related.
Green, Yellow, Red: What the Colours Actually Mean in Practice
The SNDS colour coding is simpler than Postmaster Tools' gradient reputation tiers but requires careful interpretation. The common mistake: treating Yellow as "concerning but probably fine." It is not. Yellow means Microsoft is increasing filtering for email from that IP — more email is going to Junk, and if the complaint rate trend continues, the IP will transition to Red. Yellow should be treated as an urgent signal requiring immediate investigation, not a comfortable middle ground.
What drives each colour in practice (not just the documented thresholds, but what I've observed in real SNDS data):
Green → Yellow transition: Usually driven by a sustained period of complaint rate between 0.3% and 0.5%. The transition does not happen on the day complaint rate crosses 0.3% — Microsoft's system looks at trends over multiple days. A single bad day at 0.4% typically does not cause a Yellow transition; a week of 0.4% usually does.
Yellow → Red transition: Sustained complaint rate above 0.5%, or any trap hits. Even a very small number of trap hits (1-2 per million messages) can drive a transition from Yellow to Red, especially if combined with elevated complaint rates. This is why the trap data is so critical — a single trap hit is a strong signal of list quality problems, and Microsoft's reputation system weights it accordingly.
Red → Yellow recovery: Requires approximately 30 days of clean sending (complaint rate below 0.3%, no trap hits) before Microsoft's system begins transitioning back. The recovery is not linear — you may see Red status for three weeks with clean sending before any improvement. This is frustrating, but the pattern is consistent: patient, disciplined clean sending is the only path.
A Yellow/Red IP and a Green IP on the same server: Because SNDS is IP-level, different IPs on the same server can have different colours simultaneously. This happens when different types of email (transactional vs promotional) are routed through different IPs — the promotional IP may turn Yellow while the transactional IP stays Green. This is the reputation isolation benefit of PowerMTA VMTA architecture in practice.
SNDS vs Gmail Postmaster Tools: Different Data, Different Use
Senders who are accustomed to Gmail Postmaster Tools often interpret SNDS in the wrong frame of reference. The differences matter:
Postmaster Tools reports domain reputation — your entire sending domain's reputation based on how Gmail users engage with email from @yourdomain.com regardless of which IP it came from. SNDS reports IP reputation — how a specific sending IP has performed delivering to Outlook.com/Hotmail.com users. The same email campaign can simultaneously show Good domain reputation in Postmaster Tools (excellent engagement from Gmail users) and Yellow IP reputation in SNDS (elevated complaint rate from Outlook.com users) — and both can be accurate. Microsoft and Gmail users are different populations with different spam reporting behaviour.
Gmail Postmaster Tools shows engagement signals (open rate trends, spam rate) that reveal whether recipients want your email. SNDS shows delivery signals (trap hits, complaint rate, RCPT/DATA ratio) that reveal whether your infrastructure is sound and your list quality is adequate. They are complementary, not redundant. A complete deliverability monitoring stack uses both.
The temporal resolution is different: Postmaster Tools updates with a few days of lag; SNDS data is available for the prior day. For active deliverability problem diagnosis at Microsoft, SNDS gives you more recent data — yesterday's complaint rate rather than a 3-day average.
Using SNDS for Active Deliverability Diagnosis
When Microsoft deliverability problems occur — customers reporting Junk folder delivery, SMTP log showing 451 4.7.650 rate limiting, delist requests being declined — SNDS is the first diagnostic tool to open, not the last. The specific diagnostic questions SNDS answers:
Which IPs are affected? If you have multiple sending IPs, SNDS immediately identifies whether the problem is isolated to a single IP (which points to a specific email stream or list segment) or across all IPs (which points to an authentication or DNS problem that affects everything). A single Yellow/Red IP with other Green IPs is a very different problem from all IPs showing Yellow/Red simultaneously.
Is there a trap hit pattern? Trap hits are the clearest signal of list quality problems. If SNDS shows trap hits on any day, the diagnostic question is: what campaigns ran on that day, and which list segments were used? The overlap between "days with trap hits" and "specific campaigns" identifies the list segment or acquisition channel that contained the trap address. This is actionable in a way that vague "complaint rate is elevated" data is not.
Is the RCPT/DATA gap significant? A large gap indicates rejection before DATA — usually PTR or authentication failures. Combined with the 550 error codes in the MTA accounting log, this provides a complete picture of what Microsoft is rejecting and why.
Automating SNDS Monitoring with the Data Access API
Manual SNDS review — logging into the portal, navigating to each IP, reading the status — does not scale when you have 10+ registered IPs and need to check daily. Microsoft provides a Data Access API for SNDS that allows programmatic data retrieval. The API is available after logging into postmaster.live.com and navigating to the Data Access section.
# SNDS Data Access API — basic usage:
# The API endpoint requires authentication via your SNDS session token
# Full documentation at postmaster.live.com after login
# The API returns TSV-format data for each registered IP:
# Date, IP, RCPT, DATA, Complaint rate, Trap rate, Status
# Python script for automated SNDS checking:
import requests
import csv
import io
from datetime import datetime, timedelta
# After getting your SNDS access token from postmaster.live.com:
SNDS_TOKEN = "your_snds_token_here"
def check_snds_status(token, days_back=3):
"""Check SNDS data for all registered IPs for the past N days"""
end_date = datetime.now()
start_date = end_date - timedelta(days=days_back)
url = "https://postmaster.live.com/snds/data"
params = {
"startdate": start_date.strftime("%Y-%m-%d"),
"enddate": end_date.strftime("%Y-%m-%d"),
"token": token
}
response = requests.get(url, params=params)
reader = csv.DictReader(io.StringIO(response.text), delimiter=' ')
alerts = []
for row in reader:
status = row.get('Status', 'Unknown')
trap_rate = float(row.get('Trap rate', 0) or 0)
complaint_rate = float(row.get('Complaint rate', 0) or 0)
ip = row.get('IP address', 'unknown')
date = row.get('Date', 'unknown')
if status in ('Yellow', 'Red'):
alerts.append(f"SNDS {status}: {ip} on {date} "
f"(complaint: {complaint_rate:.3f}, trap: {trap_rate:.4f})")
if trap_rate > 0:
alerts.append(f"SNDS TRAP HIT: {ip} on {date} "
f"trap rate = {trap_rate:.4f} — IMMEDIATE INVESTIGATION REQUIRED")
return alerts
# Run and alert:
alerts = check_snds_status(SNDS_TOKEN)
for alert in alerts:
print(alert)
# Send to monitoring system / Slack / email alert
Run this script daily via cron. Any alert output should trigger investigation before the next campaign send to Microsoft-domain recipients. The trap hit alert specifically should trigger investigation within hours, not days — the window between a trap hit being detected in SNDS and a full Red status transition at Microsoft is typically 3-5 days of continued sending. Catching it in SNDS data the day after the trap hit, pausing sending, and investigating the list segment is the intervention that prevents the Yellow/Red transition and the 30+ day recovery period that follows it.
SNDS is unglamorous, modestly documented, and requires some registration overhead to access. For these reasons it gets less attention than the more polished Gmail Postmaster Tools. But the data it provides — particularly the trap hit data — is genuinely unavailable anywhere else, and for senders with significant Microsoft-domain recipient volume, that data is operationally valuable enough to justify the setup effort and the daily monitoring discipline that makes it useful.