Microsoft SNDS: what it shows and when it is actually useful

Microsoft SNDS is useful when you control the IP address sending mail to Microsoft.

If you are sending through standard Microsoft 365, Google Workspace, or another provider’s shared infrastructure, that condition may not be true. You cannot claim a provider’s shared IP space just because your messages travel through it. In that case, chasing SNDS access is usually the wrong first move.

Start with ownership. Then decide what SNDS can add to the evidence you already have.

What Microsoft SNDS is

Smart Network Data Services, usually called SNDS, is Microsoft’s sender portal for data connected to mail reaching Microsoft’s consumer email network from specific IP addresses.

It is an IP-level view. It is not a domain-reputation dashboard, a mailbox-health score, or a guarantee that a message will land in the inbox.

Microsoft also operates the Junk Mail Reporting Program, or JMRP. A participating sender can receive copies of messages that Microsoft users report as junk when the reports map to enrolled IP space.

The two services answer different questions:

• SNDS: what Microsoft is showing about traffic from an IP you control.
• JMRP: which individual messages generated eligible junk reports.

Use them together when you own the sending IPs. Do not use either one as the only source of truth.

First: determine whether SNDS applies to your setup

This distinction matters for cold-email operators because “inbox provider” and “sending network” are often mixed together.

A reseller can make a real difference in setup quality, domain isolation, control, lifecycle operations, and customer support. But standard Google Workspace and Microsoft 365 mailboxes still use provider-controlled transport. SNDS is not a way for a reseller or customer to inspect all of Microsoft’s sending infrastructure.

Custom SMTP is different. If a provider assigns an IP exclusively to your account, ask who owns it, who can enroll it, whether reverse DNS is managed, and what happens when reputation degrades.

How SNDS access works

Microsoft requires a Microsoft account to sign in. From the portal, request access to the IP addresses or ranges you want to monitor.

The portal then needs evidence that you are authorized to view them. The available authorization path can depend on the registration and contact data attached to the IP range. If a hosting or SMTP provider owns the range, the provider may have to grant access or handle SNDS monitoring on your behalf.

Before requesting access, make a simple ownership record:

If you cannot fill out those fields, the access problem is exposing a more basic infrastructure-ownership problem.

Do not request a broad range because it is convenient. Request only the addresses you are authorized to monitor.

What to capture from SNDS

The SNDS interface and terminology can change. Microsoft has also moved sender-support experiences and retired pieces of older reporting. Treat screenshots of old red, yellow, and green tables as historical examples—not a permanent contract for what the current portal will display.

Capture the current fields the portal actually provides for the affected IP and date. At minimum, your incident record should include:

• IP address.
• Date or reporting window.
• Message or recipient activity shown by Microsoft.
• Complaint-related signal available in the current view.
• Any filtering, status, or anomaly indicator shown.
• The sending domains and campaigns using the IP at that time.
• The changes made before the signal moved.

Take an export or screenshot when the data is relevant to a decision. A dashboard that updates later cannot reconstruct what the operator saw during the incident.

The important comparison is not “green versus red.” It is:

1. What changed for this IP?
2. When did it change?
3. Which traffic used the IP during that window?
4. Did Microsoft delivery, complaints, or SMTP responses change at the same time?

What SNDS cannot tell you

SNDS cannot prove that a message reached the inbox. It cannot explain performance at Gmail. It does not give you a complete view of domain reputation, campaign relevance, or business results.

It also cannot isolate a sender when many unrelated customers share the same IP unless the operator has accurate routing logs. The portal sees the IP. Your own system has to map that IP back to a stream, customer, domain, mailbox cohort, and campaign.

Without that mapping, a shared-pool operator knows there is a problem but not who caused it.

SNDS also does not replace message-level evidence. Preserve SMTP responses and inspect received headers. A policy deferral, invalid recipient, authentication failure, and user complaint are not the same problem.

Add JMRP for complaint evidence

JMRP can send eligible junk reports to an address you configure. The report contains the message a Microsoft user marked as junk, which makes it more actionable than an aggregate complaint count.

Set up a dedicated intake process:

1. Use a monitored mailbox built for automated reports.
2. Parse and store the original sender, recipient where available, campaign, domain, IP, timestamp, and message identifier.
3. Suppress the complaining recipient across every system that could send again.
4. Map the event back to the audience source, campaign owner, and sending infrastructure.
5. Review clusters of complaints for a shared cause.

Treat complaint messages as sensitive operational data. Limit access and retention to what the team actually needs. Do not copy recipient data into public issue trackers or general chat channels.

A complaint is not only an infrastructure event. It can be a targeting, list-source, offer, frequency, or copy problem. The route back to the campaign matters.

A useful Microsoft deliverability view

SNDS becomes much more valuable when it sits beside other evidence.

No row replaces the others.

For a domain-focused explanation of these layers, read Email sender reputation: what it is and how to protect it. For the full monitoring routine, use the email deliverability monitoring guide.

A weekly SNDS workflow

If you operate dedicated IPs, a lightweight weekly review is enough when nothing is moving.

1. Pull current IP data

Review only the active sending IPs. Record the reporting window and current portal fields rather than relying on memory.

2. Compare against your baseline

Look for a material change from the same IP’s normal pattern. A large IP and a low-volume IP should not share one arbitrary threshold.

3. Map the period to actual traffic

Identify the domains, campaigns, customers, and message categories routed through the IP. If your logs cannot answer that, fix the logging before adding another reputation tool.

4. Review JMRP and SMTP evidence

Check whether complaints, deferrals, or rejections moved with the SNDS signal. Preserve representative examples.

5. Check the change log

Look for new list sources, volume changes, template changes, routing changes, domain additions, or suppression failures.

6. Assign one action and owner

The action might be to pause one stream, correct authentication, remove a list source, reduce a sudden pattern, ask a provider about a shared pool, or continue monitoring because the evidence is incomplete.

Write down why. “Reputation issue” is not a useful ticket.

How to respond to a bad signal

Do not rotate an IP before identifying what is using it. A new address carrying the same traffic and the same process is not a fix.

Start with containment:

• Pause the affected stream if complaints or policy failures are continuing.
• Stop sending to hard bounces and prior complainers.
• Separate unrelated traffic only when you understand the current routing.
• Confirm authentication from a received message.
• Review the audience source and the exact messages behind JMRP reports.

Then make the smallest supported change. Keep other variables stable long enough to see whether the signal and delivery behavior respond.

If the IP belongs to a provider, send the provider a specific packet: IP, dates, SMTP responses, relevant SNDS evidence, affected domains, routing details, and what changed. Asking “Why is deliverability bad?” gives support almost nothing to work with.

Do not promise a recovery time. Microsoft does not publish one universal timetable for every reputation condition.

The decision SNDS should help you make

SNDS is not a badge to add to a deliverability report. It should help an operator decide whether a Microsoft-specific problem is tied to an IP they control—and what traffic and change deserve investigation.

If you do not control the IP, move up the stack. Inspect the mailbox, domain, authentication, SMTP responses, provider notices, and campaign behavior you can actually change.

The right monitoring tool starts with the identity you own.

Build the SNDS-to-stream map before an incident

An IP-level signal only becomes actionable when you can map it to the traffic that used the IP during the reporting window.

For each address, record the routing window, sending domains, mailbox or application, campaign or message class, recipient provider, volume, and related deployment or campaign change. This map must come from your own mail and campaign logs. SNDS cannot create it after the fact.

If a provider manages the SMTP layer, ask what evidence it can supply during a Microsoft-specific incident. A useful answer covers the assigned IP or pool, dates, full SMTP responses, routing changes, and containment process. A generic “everything looks fine” status is not enough to close the investigation.

Separate Microsoft consumer and Microsoft 365 evidence

SNDS belongs to Microsoft’s sender-support environment for Outlook.com consumer properties. Exchange Online organizations can apply their own tenant policies, security products, and filtering decisions.

Do not treat one SNDS view as a complete explanation for every address hosted on Microsoft technology. Preserve the recipient domain, SMTP response, and message headers so you know which receiving environment produced the evidence.

A blended “Microsoft” outcome can hide a problem concentrated in consumer domains or one business tenant. Split the evidence before changing the infrastructure.

Decide what closes the investigation

Define recovery using the original failure. The affected SMTP responses should return to their normal range, complaint clusters should stop after the supported campaign change, the IP signal should stabilize across complete reporting windows, and a controlled send should no longer reproduce the problem.

Do not close the incident only because time passed or the current portal view changed. Write down the evidence, the change made, and the remaining uncertainty.

Access and data problems to expect

SNDS work often stalls before anyone reaches the dashboard.

The authorization email goes to the wrong party

The hosting company or network owner may control the contact Microsoft can use to authorize the IP range. Confirm the registered owner and support path. Do not misrepresent control of an address to force access.

If a vendor owns the range, ask the vendor to monitor it or delegate the appropriate visibility. Put that responsibility in the service review before an incident.

The IP is not the one your mail used

Inspect a received message and the provider logs. NAT, relays, gateways, and pool routing can make the external handoff address different from the server an operator configured.

SNDS data for the internal or wrong public address will not explain the delivery event. Save the IP and timestamp from the actual route.

The portal has no useful data

Check the date range, address, traffic volume, and whether messages actually went to the Microsoft consumer network covered by the service. Missing data is not a zero complaint rate.

Preserve the absence as part of the incident record, then rely on SMTP responses, JMRP, headers, campaign evidence, and provider support that cover the affected path.

An old guide shows fields you cannot find

Microsoft’s sender-support interfaces and reported fields change. Use the current portal as the contract. Record the field name and date instead of forcing a legacy color label into a current report.

In July 2026, Microsoft also removed spam-trap hit counts from the SNDS experience. An older workflow that depends on that field needs to be updated rather than filled with a guessed value.

When not to use SNDS

Skip SNDS as the first diagnostic when the failure is a mailbox credential, tenant restriction, broken DKIM record, invalid-recipient spike, or Gmail-only problem. Those cases already point to a different identity and evidence source.

Also skip it when nobody can prove control of the IP. The time is better spent mapping the real sending path and getting actionable evidence from the provider that owns it.

Use SNDS because it answers an IP-level Microsoft question—not because a deliverability checklist says every sender should have an account.

Sources

• Smart Network Data Services — Microsoft
• SNDS FAQ — Microsoft
• Junk Mail Reporting Program — Microsoft
• Policies, practices, and guidelines — Outlook.com Postmaster
• Email authentication in Microsoft 365 — Microsoft Learn