Postmaster 5 min read

Use Microsoft SNDS to diagnose Outlook sending reputation.

What Microsoft's Smart Network Data Services covers, who can use its IP data, how JMRP fits, and what to do when Outlook placement weakens.

By Sendlander editorial team Published August 20, 2026 Last reviewed August 20, 2026 Technical review: Sendlander deliverability team

SNDS is IP evidence for Outlook.com

Microsoft Smart Network Data Services gives authorized senders data about traffic from individual IP addresses to Outlook.com. Microsoft describes it as data for understanding and improving reputation, keeping lists clean, and detecting unusual behavior on IPs you control. The service now incorporates management of the Junk Email Reporting Program, Microsoft's feedback loop for user junk reports.

The boundary matters: SNDS is not a universal domain reputation score, and it is not a folder-placement report for a particular campaign. If you use a shared ESP IP you do not control, you may be unable to authorize the range or separate your traffic from other customers. Ask the provider what reputation and complaint data it can expose for your account.

Request access to the IPs you control

Sign in with a Microsoft account and request access to the sending IP range for which you are responsible. Microsoft uses an authorization process to confirm control. Use the smallest accurate range and keep ownership contacts current. A cloud or ESP relationship does not automatically mean you control its outbound IPs.

Microsoft moved SNDS to a newer portal in 2026 and announced changes to older automated-access URLs. If your monitoring depends on exported data, verify the current portal documentation before building automation. Treat screenshots and field names in older articles cautiously because the interface and available data can change.

Read the data in context

SNDS data is most useful as a trend across IPs and time. Look for changes that line up with a new customer, a compromise, a volume spike, a list source, or an Outlook placement drop. Color or status summaries are starting points, not verdicts. Inspect the underlying period and traffic before escalating.

Microsoft announced that trap-hit counts would no longer be included in the data report from July 2026 to protect anti-abuse systems. Older guides that treat exact trap counts as a permanent field are now stale. The safer operational lesson is to monitor unusual reputation movement, complaint feedback, and delivery behavior without assuming every internal signal will remain exposed.

Use JMRP to close the complaint loop

The Junk Email Reporting Program can send complaint reports when Outlook.com users mark your messages as junk. Route those reports into a process that suppresses the complaining recipient and connects the event to the original list source, message stream, and customer or campaign. Storing reports without acting on them does not protect reputation.

Complaint data needs careful handling because it can contain recipient and message information. Restrict access, retain only what your operational and legal requirements justify, and make suppression fast. The objective is not to persuade a recipient they were wrong; it is to stop sending unwanted mail and find why that person received it.

Troubleshoot an Outlook placement drop

First confirm the pattern with more than one controlled Outlook or Microsoft 365 inbox. Check Microsoft delivery responses, SNDS movement for the sending IP, complaint feedback, authentication on the delivered message, recent volume, audience sources, and link-domain changes. Compare personal Outlook.com with professional Microsoft 365 results because corporate gateways and tenant policies can behave differently.

Fix broad safety issues first: compromise, invalid recipients, complaint-heavy sources, or broken authentication. Then stabilize cadence and investigate provider-specific message or reputation factors. Do not rotate domains or IPs merely to escape a history you have not understood; the behavior that damaged one identity can damage the next.

Shared IP and dedicated IP tradeoffs

On a shared IP, the provider manages infrastructure and pools reputation across customers. This can protect a smaller sender from the burden of warming and operating an IP, but it can also make IP-level evidence harder to isolate. A reputable ESP should control abuse and provide enough account-level metrics to manage your own audience and traffic.

A dedicated IP gives you clearer control and makes SNDS more directly attributable, but only if you have enough consistent wanted volume and operational discipline. It is not a deliverability upgrade by definition. A quiet or erratic dedicated IP can be harder to build than a well-managed shared pool.

Pair SNDS with a placement test

SNDS explains the sending IP's recent relationship with Outlook.com. A placement test asks where one current message landed across Outlook, Gmail, Yahoo, and business inboxes. Use both when available. If the Outlook seeds worsen and SNDS also changes, the IP trend becomes a strong lead. If SNDS is stable while one template fails, inspect the message and audience-specific factors.

Record the provider mix and time of each test. Some results arrive slowly, and a missing seed is not automatically spam. Retest the same sending path after the repair so the team can distinguish a real recovery from a different campaign sent under different conditions.

Questions readers ask

Does Microsoft SNDS show domain reputation?

SNDS is primarily IP-focused. Do not present it as a universal domain reputation score.

Can I use SNDS with a shared ESP IP?

Usually only the party authorized for the IP range can access the data. Ask your ESP what account-level Outlook reputation and complaint evidence it provides.

Is a green SNDS status an inbox guarantee?

No. Reputation data is one input. Message, audience, authentication, tenant policy, and recipient-specific factors can still change placement.