Microsoft SNDS: Read IP Reputation Before Campaign Changes

Microsoft SNDS is useful when you can connect a sending IP to the campaign and operator that control it. Its data is daily and IP-specific, while its filter colors are not inbox-placement rates. Map ownership first, then choose whether to pause your sending, escalate to a provider, or open a Microsoft Postmaster case.

Confirm that you are looking at your IP

Microsoft describes Smart Network Data Services as reputation data for individual sending IPs. That means the first task is not interpreting a color. It is proving which public IP sent the affected messages.

Pull the IP from real message headers or provider logs. Map it to the sending domain, mailbox provider, campaign, and date range. Then classify it as dedicated, shared, or unknown. An unknown answer is a stop condition because the data cannot yet support a campaign decision.

SNDS access also tests ownership. Microsoft's SNDS FAQ says authorization uses reverse DNS, registration data, and routing information to find an authoritative address for the IP range. If your team cannot authorize the range, the infrastructure provider owns the next action.

Record the fields without overreading them

For each affected IP, capture the activity period, message and recipient counts, aggregate filter result, complaint evidence, IP status, and security comments shown in the account. Add a lookup timestamp and the recent campaign or infrastructure changes that could overlap the period.

Microsoft defines green as less than ten percent of messages receiving a spam verdict, yellow as between ten and ninety percent, and red as more than ninety percent. Those are Microsoft filter-result bands. Microsoft explicitly says the result is one data point and does not directly represent inbox-versus-junk placement.

SNDS data is aggregated daily for the previous day and retained for ninety days. The separate IP-status view reflects roughly the last twenty-four hours, has no history, and is not real time. A change made this morning cannot be validated against yesterday's completed data.

On a shared IP, the complaint count can include mail across every domain using that IP. Do not assign the entire number to one campaign without provider-level attribution.

Connect the evidence to a change window

Place campaign changes beside the SNDS dates. Include send-volume changes, new domains, pool moves, authentication changes, list-source changes, and provider incidents. This is an internal evidence timeline, not a claim that any one event caused the result.

A worsening result that begins after a dedicated-IP pool move deserves infrastructure investigation. A complaint change isolated to one campaign deserves audience and expectation review. A red shared IP with no campaign-level attribution belongs with the provider. No visible change in SNDS while Outlook outcomes worsen means the cause may sit outside this tool.

Microsoft's Postmaster troubleshooting guidance says filtering considers IP, domain, authentication, list accuracy, complaint rate, content, and other factors. That is why one color cannot settle the diagnosis.

Use three action branches

Pause controllable sending when a dedicated or directly managed IP shows a material negative change tied to active traffic and continuing would add exposure. Preserve the logs before changing anything, then isolate the affected stream rather than stopping unrelated infrastructure.

Escalate to the provider when the IP is shared, the team cannot authorize the range, or the provider controls pool assignment and configuration. Send the IP, activity dates, visible SNDS fields, affected domains, message examples, and recent changes. Ask for attributable traffic evidence and a named remediation action.

Open Microsoft Postmaster support after authentication, policy, and provider checks when the issue remains Microsoft-specific. Microsoft says SNDS displays data affecting delivery but does not process support requests itself.

LeadHaste practice: we require each escalation to name the evidence owner and the next observation window. A ticket without an owner or a date becomes a description of the problem rather than a control.

Preserve the worksheet

Keep authorized IP ranges, sharing status, providers, domain mappings, SNDS observations, campaign changes, decisions, and ticket links in one record. The worksheet gives the next operator enough context to compare periods without repeating discovery.

That is the ownership test. If the team cannot map a campaign to an IP or name the person who can act on it, the sending system is not yet under control.

Trace Microsoft reputation evidence to the right owner

We can map your Microsoft-facing IPs and escalation paths during an ICP and campaign-fit discovery call. Book your free discovery call →