SNDS

SNDS lives at sendersupport.olc.protection.outlook.com/snds/. It exposes per-IP signals from Microsoft's Outlook, Hotmail, and Live mailbox infrastructure. The primary signals:

• Color rating per IP. Red (treated as spam), yellow (filtered), green (good standing). The most important top-line signal.
• Volume sent to Microsoft mailboxes per day, per IP.
• Complaint rate from JMRP enrollment plus Microsoft's own observations.
• Trap hits. Count of Microsoft spam-trap addresses your IP mailed. Even a small number is a strong negative signal.
• Sample message rejection reasons. When Microsoft rejects your mail, this shows why (rate-limited, blocked, content-detected, etc).

What SNDS doesn't show: per-domain reputation (IP-only), inbox vs spam folder placement (only delivery vs rejection at the network level), projections.

Three ratings, mapped approximately to:

• Green. Good standing. Mail is reaching mailboxes. Filtering is light. Aim for green. Defend it once achieved.
• Yellow. Warning. Mail is being filtered more aggressively. Some inbox placement, some spam folder routing. Address whatever signal triggered yellow before it becomes red.
• Red. Active reputation problem. Significant spam folder routing or outright rejection. Recovery requires identifying the cause, fixing it, waiting 14-30 days for the rating to recover.

A common pattern: an IP can be green at SNDS but still hit corporate Outlook tenants' filtering. SNDS measures consumer Microsoft (Outlook, Hotmail, Live), not corporate Exchange Online tenants. Corporate tenants apply their own filtering on top.

SNDS needs per-IP enrollment. Setup:

1. Sign in at sendersupport.olc.protection.outlook.com/snds/ with a Microsoft account.
2. Request access to specific IPs or IP ranges. CIDR ranges are accepted.
3. Verify ownership. Microsoft sends a test message to the abuse@ or postmaster@ address of the rDNS hostname for the IP. Reply to confirm.
4. Wait 24-48 hours for data to populate.

For senders with multiple IPs, enroll each one. SNDS supports per-account access to multiple IPs.

SNDS shows aggregate signal. JMRP (Junk Mail Reporting Program) sends per-message complaint reports. Together they cover both views.

JMRP is Microsoft's FBL. When an Outlook/Hotmail/Live user marks one of your messages as junk, Microsoft forwards a copy to your designated address. You parse it (ARF format), extract the recipient, add to suppression. Sign up at sendersupport.olc.protection.outlook.com/snds/JMRP.aspx.

SNDS without JMRP gives you trends but not specific complainers. JMRP without SNDS gives you specific complainers but no aggregate view. Production senders enroll in both. There's no good reason to skip one.

Common reasons SNDS shows nothing:

• Volume too low. Microsoft needs ~100+ daily messages to a given IP's Microsoft audience before populating the dashboard.
• Recent enrollment. 24-48 hour delay between verification and first data.
• Blocked at network level. If your IP is on Microsoft's S3140-block list, mail isn't reaching their infrastructure to be measured. The IP shows in SNDS without rating data, often with rejection notes.
• IP changed ownership recently. Microsoft sometimes lags 1-2 weeks updating IP-to-sender mapping after IP transfers.

The 24-48 hour data delay matters more than most operators initially expect. By the time SNDS shows red, the events that caused it happened a day or two earlier; remediation you start today affects ratings you'll see in another 24-48 hours. Total feedback loop from incident to confirmed-fix: 3-5 days minimum.

Three operational implications. First, you cannot use SNDS for real-time incident response; by the time the dashboard shows the problem, the bad sending has already happened and reputation damage has already accumulated. Pair SNDS with real-time signals (bounce-rate spikes, sudden 5xx response patterns from Outlook MX hosts, JMRP complaint rate) for actual incident detection.

Second, A/B testing changes via SNDS requires patience. Change one variable, wait 72 hours minimum to observe the effect, only then change another. Operations that change three things in a week have no signal for which change moved the rating.

Third, expect rating to lag your actual sending health by ~2 days during recovery. If you fixed the underlying cause on Monday, expect the rating to reflect the fix by Wednesday or Thursday at earliest. Customers sometimes panic when their rating stays red for a few days after they remediate; this is the data delay, not a remediation failure.

Multi-IP sending creates patterns SNDS reveals that single-IP sending doesn't. When you operate 5-50 IPs, the rating distribution itself becomes diagnostic. A few patterns worth knowing.

All-green across all IPs: ideal. Indicates Microsoft sees your sending uniformly well across the pool. Maintain.

Mixed green/yellow with no clear pattern: usually a noise effect; some IPs randomly pick up signals from specific recipient cohorts. Wait a week before reacting; isolated yellow ratings often return to green without intervention if the underlying sending health is good.

Specific IPs consistently yellow while others stay green: investigate. The yellow IPs are likely sending to a different recipient cohort (different list segment, different campaign, different time-of-day pattern), and that cohort is generating worse signals. List segmentation analysis follows.

All IPs trending yellow simultaneously: systemic issue affecting all sending. Could be content-classifier drift (template change went out a week ago and now affects all IPs), authentication misconfiguration (DKIM key rotation broke something), volume spike across the pool, or upstream infrastructure issue.

Most-sent IPs red while low-volume IPs stay green: classic sign of volume-driven reputation problem. The IPs hit hardest with volume show damage first; low-volume IPs benefit from looking like organic sending. Either reduce volume across the pool or improve sending quality before volumes increase further.

Microsoft SNDS remains the primary external visibility tool for senders targeting Outlook, Hotmail, and consumer Microsoft mail properties. The dashboard interface has evolved through 2024-2026 but the underlying signal model has not changed materially. What has changed is the receiver-side enforcement that SNDS data correlates with.

Microsoft completed the bulk-sender enforcement rollout on April 30, 2026 with 550 5.7.515 rejections on non-compliant bulk mail to consumer Outlook properties. The enforcement applies to senders with 5,000 or more daily messages to consumer Outlook accounts. Before April 2026, non-compliant mail typically routed to the Junk folder where recipients could theoretically retrieve it; after April 2026, non-compliant mail is rejected at SMTP time and never reaches the receiver. SNDS data continues to surface the signals (filter result percentages, complaint rates, spam-trap hits) that drive the enforcement decision, which makes SNDS more important rather than less under the new conditions.

The SNDS data refresh cadence is still daily with a 24-48 hour lag. The IP/24 grouping (range view) and per-IP view are both still available. The reputation scoring still uses the red/yellow/green tertiary scale rather than the binary Pass/Fail that Gmail moved to with Postmaster Tools v2. This makes SNDS one of the few external monitoring tools still providing a usable warning band that allows operators to identify deteriorating reputation before enforcement triggers.

The structural implication for operators sending to Outlook audiences: SNDS monitoring should be set up before sending begins on any new IP, not as a reactive measure after an incident. The lag means yellow-going-to-red transitions are visible 24-48 hours before the underlying receiver behaviour catches up, which is the difference between proactive remediation and reactive recovery.

SNDS is the IP-level reputation visibility tool. JMRP (Junk Mail Reporting Program) is the complaint-flow tool that surfaces specific user complaints back to senders. The two work together and the operational value of either is substantially reduced without the other. Most operators set up both at the same time during initial Outlook deliverability work.

JMRP delivers feedback loop reports to a sender-specified address whenever a Microsoft consumer mail user marks a message from the sender as spam. Each report includes enough information to identify the specific recipient (so the sender can suppress them from future mailings) and the specific message (so the sender can correlate to a specific campaign or send event). The reports arrive as ARF-formatted email messages, which most modern bounce-processing infrastructure parses natively.

The operational baseline for JMRP processing is: suppress every reported recipient within 24 hours of report receipt, never send to a reported recipient again from any sending infrastructure under the same domain or business, aggregate complaint patterns to identify list segments or content patterns with elevated complaint risk. Suppressing within 24 hours is below the receiver expectation; under 2026 enforcement conditions, repeat-send to a previously-reported recipient is a strong negative signal that compounds quickly.

Beyond JMRP, the broader FBL ecosystem includes Yahoo, AOL, Comcast, Cox, USA.net, and several smaller receivers that publish feedback loop data. Each requires a separate registration process and delivers reports through provider-specific paths. For senders with any meaningful Yahoo or AOL audience, the Yahoo CFL (Complaint Feedback Loop) is the analogous tool to JMRP and follows similar operational patterns.

The SNDS dashboard surfaces several specific data points per IP. Operators monitoring SNDS at scale develop intuition for which patterns indicate which underlying conditions; the summary below captures the most common patterns.

Green status with sustained low filter result percentages: healthy IP operation. No action required beyond continuing to monitor and maintaining the operational discipline that produced the clean state. Most successfully-warmed sending IPs reach this state within 30-45 days and remain there indefinitely with proper list hygiene.

Yellow status appearing after weeks of green: early warning of deteriorating reputation. The yellow window is typically 7-21 days before transition to red occurs if the underlying condition is not addressed. Diagnostic steps: check Postmaster Tools (Gmail) for parallel deterioration, check Spamhaus and major RBLs for any listings, audit recent campaign content and list-acquisition sources for changes, examine bounce-rate trends for elevated hard-bounce volume that indicates list-quality decay. Most yellow-status events resolve within 7-14 days once the underlying cause is identified and addressed.

Red status without prior yellow warning: typically indicates a discrete event rather than gradual deterioration. Common causes include spam-trap clustering (a list segment with multiple seeded trap addresses, often from purchased or scraped data), sudden complaint-rate spike from a specific campaign with poor content or audience mismatch, or blocklist listing that the SNDS dashboard surfaces with delay. Recovery from sudden red status takes 30-60 days typically; the underlying condition needs to be addressed before any reputation recovery begins.

Yellow or red on specific IPs within a larger pool: isolates the affected infrastructure for targeted remediation. The non-affected IPs continue operating normally; the affected IPs should pause sending while diagnosis proceeds. Mixing yellow IPs with green IPs in active rotation extends recovery time because the green IPs accumulate some of the receiver-side scrutiny that the yellow IPs trigger.

Mixed signals: green with high filter percentage or red with low filter percentage: indicates that the headline status and the underlying data have diverged, usually due to recent campaign volume changes. Trust the underlying data over the headline status when this happens; the headline status updates with delay relative to the source data.

SNDS registration requires demonstrating control over the IP space the operator wants to monitor. The mechanism is one of several allowed: reverse DNS containing a specific phrase that Microsoft suggests, abuse.net listing for the network, ARIN/RIPE/APNIC contact for the IP range, or specific email-confirmation against the abuse contact published in WHOIS for the range. Most operators successfully register through the reverse DNS path because it requires the fewest external dependencies.

The most common registration pitfall is requesting IPs not yet provisioned to the operator. Microsoft cross-checks the registration request against current allocations; requesting IPs that were recently transferred can produce confusing rejection messages if the WHOIS update has not propagated. The fix is to wait 24-72 hours after IP allocation before submitting the SNDS request, ensuring that all the verification paths Microsoft uses have current data.

The second common pitfall is registering at the wrong granularity. SNDS allows registration of CIDR blocks at various sizes. Operators who register at /24 see aggregate data across the whole /24, which is the natural unit for many sending pools but can mix signals from different sending categories. Operators with internal isolation between sending categories (separate IPs for marketing, transactional, cold outreach) typically register at /29 or /30 to get per-pool signal separation. Both granularities are valid; the choice depends on operational needs.

The third pitfall is forgetting that SNDS access is per-Microsoft-account, not per-IP-range. An operator with multiple Microsoft accounts can register the same IP range under multiple accounts for redundancy or team-access purposes. An operator with one Microsoft account that loses access to the account loses access to the SNDS data; the recovery mechanism is through Microsoft account recovery, not through SNDS-specific support. We recommend that operators set up a dedicated Microsoft account for SNDS monitoring rather than using a personal account that might have unrelated recovery complications.

SNDS as a standalone dashboard is operationally insufficient for production senders. The data needs to flow into monitoring infrastructure that surfaces status changes through the same alerting paths as other production signals (Slack, email, PagerDuty, on-call rotation, ticket system). The integration mechanics are not difficult but the patterns matter for operational reliability.

Microsoft does not publish an SNDS API. The data is accessible through the SNDS dashboard interface and through the CSV export functionality. Most operators integrate by scraping the SNDS interface daily with an authenticated browser session, parsing the resulting data, and storing it in a time-series database for trend analysis. Several open-source tools implement this pattern; the integration logic is straightforward enough that internal implementation is also viable for teams that prefer not to depend on third-party scraping tools.

The alerting thresholds that have worked well across 2024-2026 deployments: alert on any IP transitioning from green to yellow (early warning, no immediate action required but investigation should begin), alert urgently on any IP transitioning to red (immediate action required, pause sending on the affected IP and investigate root cause), alert on aggregate volume changes exceeding 20% week-over-week without corresponding business explanation (often indicates either undocumented campaign changes or list-quality decay producing higher bounce rates), alert on filter result percentage above 1% sustained for any IP (early signal that complaint or trap activity is elevating).

The integration should consider data lag. SNDS updates daily with 24-48 hour delay from the underlying sending activity. Alerts based on SNDS data are reactive to events that already occurred; they cannot prevent the original event but they enable faster response than alternative monitoring paths that surface the same information through customer complaints or blocklist listings. Pairing SNDS monitoring with Postmaster Tools monitoring (Gmail) and active blocklist monitoring (Spamhaus and major RBLs) produces the multi-source visibility that catches deteriorating reputation across the major receiver ecosystems.

SNDS provides visibility into Microsoft consumer mail (Outlook.com, Hotmail.com, Live.com, MSN.com) reputation only. Senders with audiences concentrated outside this user base get reduced operational value from SNDS monitoring, but the data still provides useful baseline reputation visibility that other tools do not cover.

For senders with primarily Gmail audiences, SNDS data correlates with overall reputation trends even when it does not directly measure the receiver mix that the sender cares about. Sustained green status in SNDS typically corresponds to clean overall sending operations; sustained yellow or red SNDS status often correlates with broader reputation issues that Gmail Postmaster Tools also surfaces. The directional correlation makes SNDS useful as supplementary monitoring even when Microsoft consumer mail is not the primary audience.

For senders with primarily enterprise audiences (Microsoft 365, corporate gateways), SNDS data does not directly measure the receiver mix but the underlying reputation factors overlap significantly. Microsoft enterprise mail filtering uses some of the same reputation signals as the consumer side; SNDS reputation status often correlates with enterprise placement even when the data points are not identical.

For senders with non-Microsoft audiences entirely (Yahoo-focused, regional providers, B2B operations through Google Workspace), SNDS provides limited operational value. The monitoring overhead is still trivial (the dashboard is free, registration is one-time), so most operators set up SNDS for the small amount of visibility it provides even when it is not central to their audience strategy. The exception is operators with very specific audience targeting where SNDS data is operationally irrelevant; for those operators, focusing on the relevant receiver-specific tools (Postmaster Tools for Gmail, FBL programs for specific providers) is more efficient than maintaining SNDS monitoring that does not surface useful signal.