Microsoft SNDS Guide: IP Reputation and Outlook Deliverability

Estimated reading time: 9 minutes

Your email platform says “delivered,” but Outlook subscribers keep finding your campaigns in Junk. Microsoft SNDS can help you investigate by showing traffic and filtering data for your sending IPs. The challenge is reading that data correctly: a green result is useful, but it does not prove that a campaign reached the inbox.

This guide explains what to check, what the numbers mean, and how to turn them into specific deliverability fixes.

Key Takeaways

• SNDS reports on sending IPs and traffic to Microsoft’s consumer email service.
• Green, yellow, and red describe filtering results, not inbox placement percentages.
• Complaint data needs context: reporting dates and sending dates can differ.
• Use SNDS alongside complaint feedback, delivery logs, and inbox placement tests.
• Registration gives you visibility; it does not repair your reputation automatically.

What Is Microsoft SNDS?

Microsoft Smart Network Data Services, or SNDS, is a free service that helps senders understand how Outlook.com views traffic from their IP addresses. It supports reputation monitoring and can help identify unusual or abusive sending activity.

Its scope is Microsoft’s consumer email service, including Outlook.com, Hotmail, Live, and MSN addresses. An email being opened in the Outlook application does not, by itself, put that mailbox within SNDS’s scope. Keep investigations into Microsoft 365 business mailboxes separate.

SNDS is particularly useful when you need to compare sending IPs. If one IP deteriorates while the others remain stable, start by checking the campaigns and traffic assigned to that IP.

On a shared IP, investigate with your email service provider. The report can include activity from other customers, so you cannot safely attribute every change to your own campaigns.

How to Set Up Microsoft SNDS

Start by identifying the public IP addresses that actually send your email. Ask your provider for the current list, especially if it routes campaigns through several IPs. Your website’s IP address may have nothing to do with your email traffic.

Then:

1. Sign in to the current SNDS portal with a Microsoft account.
2. Request access to your sending IP or IP range.
3. Choose an offered authorization email address and complete verification.

If the available address belongs to your provider, ask its support team to help authorize access. Having a dedicated IP does not necessarily mean you control the contact information used to verify it.

Keep access maintenance on your calendar. Microsoft now requires network access to be reattested; approval lasts 10 months. Use the expiration date displayed in SNDS to plan renewal.

Microsoft moved SNDS to a new portal in 2026. If you maintain an older monitoring integration, check that it still retrieves current data.

How to Read SNDS Data

Start with traffic counts

The main traffic fields describe different stages of sending:

Field	What it records
Activity period	The reporting window for the IP’s activity
RCPT commands	Recipient-address attempts
DATA commands	Message-transmission commands
Message recipients	Recipients on transmitted messages

These counts are not interchangeable. One message can have several recipients, so comparing DATA commands directly with RCPT commands does not produce a reliable bounce rate.

Instead, investigate a widening gap between recipient attempts and message recipients. Match the affected period to your provider’s logs. Did an imported segment contain invalid addresses? Did retries increase? Did Microsoft begin refusing recipients?

Use the SMTP responses to establish the cause before deciding which addresses or campaigns need attention.

Understand green, yellow, and red results

SNDS summarizes spam-filter verdicts by IP:

Color	Microsoft’s documented spam-verdict range
Green	Below 10%
Yellow	Between 10% and 90%
Red	Above 90%

These are broad categories. A yellow result does not tell you exactly how much traffic was affected.

Green does not mean 100% inbox placement. Filtering verdicts and final folder placement can differ, including because of recipient settings. Treat a color change as a reason to investigate, rather than a complete diagnosis.

When the IP is green but subscribers report missing emails, send the affected campaign through GlockApps Inbox Insight using your normal sending setup. Check its Outlook placement results alongside SNDS to see whether the test message reaches the inbox or spam folder. Seed results describe those test mailboxes; they do not guarantee the same result for every subscriber.

Read complaint rates against the right dates

The SNDS complaint rate divides complaints by message recipients. Complaints are recorded on the day users report them, which may be later than the original send.

Consider this hypothetical example:

• Monday: you send a large campaign.
• Tuesday: you send only 1,000 messages.
• Tuesday: 20 complaints arrive about Monday’s campaign.

Those 20 complaints against Tuesday’s 1,000 recipients would produce a 2% rate. That does not establish that 2% of Tuesday’s campaign recipients complained.

Check the earlier sends before blaming the latest campaign. A useful review includes the reporting day, recent campaign dates, recipient volumes, and complaint feedback.

Set internal alerts against your normal performance, then investigate sustained increases. A single percentage without its volume and timing can send your team toward the wrong fix.

Treat older spam-trap columns as legacy reporting

Older SNDS guides describe “Trap hits” and “Trap message period.” These are absent from Microsoft’s current FAQ field list.

Do not build a monitoring process that depends on those columns. Their absence also gives you no basis to conclude that your mailing list contains no spam traps.

SNDS and JMRP: Use Both

Microsoft’s Junk Email Reporting Program, or JMRP, provides feedback about messages users report as junk or phishing. These reports can include the original message and headers.

SNDS helps you spot a complaint problem at the IP level. JMRP helps you investigate the messages involved.

A practical complaint-handling process should:

• Match reports to the relevant campaign or sending stream.
• Suppress identifiable complainants from the applicable marketing list.
• Check whether one signup source or older audience segment is overrepresented.
• Confirm that suppressions reach every platform used for that list.

Assign responsibility for processing the reports. Forwarding them to an unattended mailbox will not prevent another campaign from reaching the same unhappy subscribers.

If your provider handles feedback loops, ask how Microsoft complaints are processed and whether you can review campaign-level patterns.

How to Troubleshoot Outlook Deliverability with SNDS

Your IP changes from green to yellow or red

Build a short timeline around the first affected day. Record:

• Campaigns sent and the audiences selected.
• Changes in volume or frequency.
• New list imports or reactivated subscribers.
• Sending-platform, IP, or authentication changes.
• Delivery errors and complaints.

For example, if the change follows the first send to a six-month-old segment, pause that segment while you investigate. Review when those subscribers last interacted and what they originally signed up to receive.

Avoid changing the subject line, audience, sending domain, and infrastructure together. You need to be able to tell which correction helped.

Complaints rise after a campaign

Read the email from the subscriber’s perspective. Would someone recognize the sender? Did the signup form promise this type of content? Has the mailing frequency changed?

Check whether:

• A welcome sequence failed, leaving subscribers unfamiliar with the brand.
• A preference change increased the number of emails people received.
• An unsubscribe request was not applied across systems.
• A list upload restored previously suppressed contacts.

These are more useful questions than searching the copy for a single “spam word.”

Filtering worsens, but complaints stay low

Low complaints do not rule out a deliverability problem. Microsoft notes that messages filtered out of view are less likely to attract user complaints.

Check authentication, recent audience changes, message content, and delivery errors together. If only one sending IP is affected, ask what traffic differs on that IP.

Do not treat a quiet complaint report as proof that subscribers are satisfied.

SNDS shows no data

Low-volume IPs may have no traffic data; Microsoft notes that reporting can be absent below 100 messages a day. Data also arrives after daily processing.

Check the selected IP, reporting date, access status, and actual sending route. If your provider changed the outbound IP, you may be looking at a report for infrastructure your campaigns no longer use.

Missing data means limited visibility. It does not establish that the IP has a good reputation.

Outlook rejects or delays messages

Start with the full SMTP response in your sending logs. A temporary deferral, invalid recipient, and authentication rejection require different actions.

Separate these questions:

1. Did Microsoft accept the message?
2. If it did, where did the message land?
3. What changed in SNDS around the same period?

Keep the sending IP, timestamps, error text, affected recipient domains, and recent changes together. If the problem persists after you correct the cause, that record will make a support request much more useful.

Authentication Still Matters When SNDS Looks Healthy

A favorable SNDS report does not exempt a sender from Microsoft’s authentication requirements.

For domains sending more than 5,000 messages a day to Outlook.com accounts, Microsoft requires:

• SPF: passing authentication.
• DKIM: passing authentication.
• DMARC: at least a p=none policy, with alignment through SPF or DKIM.

Noncompliance can lead to junk placement or rejection, including error 550 5.7.515.

Check authentication on messages sent through the affected platform. A correct DNS record alone does not confirm that every application uses the expected sending domain or DKIM signature.

Also maintain valid reverse DNS, provide an easy unsubscribe process, and handle permanent delivery failures correctly. SNDS helps you observe sending behavior; these controls determine whether your setup meets Microsoft’s requirements.

Build SNDS into Your Deliverability Routine

For active sending programs, review SNDS after each reporting update. Microsoft processes data daily and makes it available for 90 days; CSV exports and automated access support longer-term analysis.

Keep a small working record:

Record	Why it helps
Sending IP and traffic owner	Identifies which team or provider can act
Campaign and audience changes	Gives a color or complaint change context
SMTP errors	Separates rejection from inbox placement problems
Complaint feedback	Identifies affected campaigns and list issues
Test results	Shows whether a specific message’s placement changed

During an investigation, write down each change and its date. “Removed inactive subscribers from the weekly promotion” is more useful than “improved list hygiene.”

After correcting the suspected issue, repeat the affected message’s inbox placement test in GlockApps before increasing volume. Compare the result with your earlier test and the next SNDS reports. Keep the sender, sending route, and message consistent unless one of them is the change you are testing.

Conclusion

Microsoft SNDS is useful when its data leads to a specific investigation: which IP changed, which traffic caused it, and what needs correcting. Read it alongside delivery logs, complaint feedback, and placement tests. A green report is encouraging; reliable delivery requires the rest of the evidence too.

FAQ