Microsoft SNDS 2026 changes: what senders need to know before June 8
News
Michael Ko
Co-founder & CEO, Suped
Published 7 Jun 2026
Updated 7 Jun 2026
11 min read
Summarize with
Microsoft is sunsetting the old Smart Network Data Service portal on June 8, 2026, after roughly 20 years of senders using it to monitor Outlook.com reputation. The direct answer is simple: before June 8, senders need to confirm SNDS account access, refresh ownership of controlled IP ranges, prepare for SNDS and JMRP downtime, update any automated report workflows, and plan for a new reporting model that has REST API access, changed report columns, 30-day report link expiry, and updated JMRP complaint data.
Microsoft posted the current details on Microsoft SNDS. The old page has View Data, View IP Status, Request Access, Access Control, Edit Profile, FAQ, and Junk Mail Reporting Program sections. Microsoft first said the move would happen in May 2026, removed that notice, then reposted the migration notice with the June 8 date. It still has not clearly named the replacement portal, so I would treat every old SNDS bookmark, feed, and report URL as temporary.
- Before June 8: Log in with the Microsoft Account used for SNDS, confirm it is a valid email address, and check that all responsible IP ranges still show access.
- During migration: Expect downtime for the portal, reports, and Junk Mail Reporting Program feeds. Do not treat missing data during the cutover as a sudden reputation recovery or failure.
- After migration: Refresh automated report links within 30 days, plan recurring refreshes every 30 days, and watch for network reattestation reminders before the 10-month access window closes.
- For deliverability: Use SNDS as one signal. Pair it with authentication results, complaint trends, bounces, blocklist data, and message tests before changing volume or routing.
What is changing on June 8
The June 8 change is not only a cosmetic portal move. It changes how senders reach SNDS, how report access works, what JMRP complaints contain, how long automated links remain useful, and how network ownership is renewed. Old SNDS links are expected to redirect after migration, but the migration window includes downtime for the portal, report data, and JMRP feeds.
|
|
|
|---|---|---|
Portal | New URL | Update bookmarks |
Reports | REST API | Revise pulls |
Links | 30-day expiry | Refresh monthly |
Networks | 10-month access | Reattest ownership |
JMRP | Header-only ARF | Update parsing |
Profile | UTC time zones | Check schedules |
Compact summary of sender-facing SNDS migration changes.
Mock screenshot of the Microsoft Smart Network Data Services portal layout.
The biggest operational risk is stale automation. If a team has scripts that download SNDS reports from saved links, those links migrate but still need a refresh 30 days after migration and every 30 days after that. Treat old report links as expiring credentials, not permanent endpoints.
The old portal also has a small but important account issue. Accounts with names that are not valid email addresses will not function as expected. If that applies to an old login shared by an operations team, move access to an alternate Microsoft Account before the migration instead of waiting for a failed login during an active deliverability issue.
Why this matters for Outlook.com reputation
SNDS gives senders data needed to understand Outlook.com reputation, but Microsoft is explicit that viewing the data is not enough. Reputation remains the sender's responsibility. I read that as a warning against dashboard watching without list hygiene, complaint management, authentication checks, and fast investigation when a controlled IP starts behaving differently.
Old operating model
- Portal checks: Teams often opened View Data or View IP Status manually after complaints, throttling, or a Microsoft bounce spike.
- Saved links: Automated exports often depended on report links that stayed in runbooks longer than anyone remembered.
- JMRP body data: Some complaint workflows expected the full complaint message body to be appended to ARF feedback.
New operating model
- API reports: IP Status and IP Data reports move to a REST API using the same login as the SNDS portal.
- Monthly refresh: Report links expire after 30 days, so automation needs a planned refresh process.
- Header data: JMRP ARF feedback keeps original headers and selected authentication headers, with the sender address redacted.
For senders with real Outlook.com volume, I would also review authentication and inbox testing at the same time. SNDS tells you how Microsoft sees your IP behavior. It does not prove that a specific campaign has the right SPF, DKIM, DMARC, TLS, content, or unsubscribe setup. A practical workflow is to send a test message through an email tester before large sends, then compare the result with SNDS complaint and status data after the campaign.
SNDS migration readiness
Use these bands to decide whether the June 8 migration is a routine change or a deliverability risk.
Ready
Low risk
Valid account, active IP access, known JMRP feeds, and documented report refresh process.
Watch
Medium risk
Access works, but report automation or complaint parsing has not been tested against the new model.
Fix now
High risk
Unknown account owner, stale IP access, unlinked JMRP feeds, or old scripts using saved report URLs.
Unknown
No baseline
No confirmed SNDS owner for the sending IPs or no central record of who receives JMRP data.
JMRP and ARF feedback changes
The Junk Mail Reporting Program change is the one most likely to break downstream complaint processing. Microsoft says the updated ARF feedback format includes only the original message headers from the complaint email, plus selected authentication headers such as Authentication-Results and Received-SPF. The sender address is redacted, and the full complaint body is no longer appended.
Simplified ARF feedback shape after migrationtext
Original message headers Authentication-Results Received-SPF Redacted sender address No appended complaint body
That is a sensible privacy change, but it shifts more work to your identifiers. If your complaint tooling relied on body content, full sender address visibility, or campaign text, it needs another way to map a complaint back to a stream. The safer approach is to use stable headers, campaign IDs, outbound IP, DKIM selector, and sending platform metadata that survive header-only complaint reports.
JMRP feeds not linked to SNDS accounts are removed after migration. Recreate those feeds from an SNDS account that has current network access, then keep the network approval current so complaints do not silently stop.
For teams sending through an email service provider, the hard part is often proving who controls the responsible IPs. If that is your setup, I would keep the Microsoft-side owner, ESP-side support contact, and internal deliverability owner in one runbook. The same logic applies to ESP SNDS access, because the person with portal access is not always the person who can change sending infrastructure.
Reporting and API impact
After migration, IP Status and IP Data reports are accessible through a new REST API using the same login as the SNDS portal. Microsoft also says calculations for IP Status and IP Data use updated data, and report columns change to match the updated data model. That means trend comparisons need care during the first reporting period after the move.
Flowchart showing old SNDS reports moving through downtime to the new portal and REST API.
- Rebuild parsers: Do not assume old column names or positions remain stable. Parse by documented field names once Microsoft publishes the final API details.
- Tag cutover dates: Mark June 8, 2026 in reporting so updated calculations do not get confused with a normal reputation change.
- Refresh links: Create a 30-day report link refresh task with an owner, backup owner, and calendar reminders.
- Compare sources: Match SNDS data against bounces, complaint data, authentication results, and Microsoft sender support responses when troubleshooting.
The new API detail matters because SNDS often sits inside alerting and daily reputation checks. If a script fails quietly after migration, a sender can miss early warning signs such as traffic appearing on an unexpected IP, a complaint spike, or a status change for a controlled netblock. For deeper Outlook.com analysis, keep a separate SNDS troubleshooting runbook rather than relying on the portal alone.
Access, ownership, and renewal work
SNDS access starts with a Microsoft Account, then a request for access to the IPs the sender is responsible for, followed by authorization. After migration, approved users keep network access for 10 months before renewal. Microsoft says users receive reminders before network access expires, and approving networks requires authentication through the new renewal and approval experience.
- Confirm owner: Identify the human owner for each sending IP range and the backup owner for renewals.
- Validate account: Make sure the login account name is a valid email address and not a legacy username.
- Check networks: Review every approved network and remove ranges that are no longer controlled.
- Renew access: Create a 10-month renewal process that is not tied to one employee's calendar.
- Recreate feeds: Rebuild any JMRP feed that is not linked to an SNDS account with current network access.
Do not wait for an urgent Outlook.com block to discover that the only SNDS account owner left the company. Microsoft says urgent deliverability issues should be handled by the person most familiar with the mail infrastructure and sender support. That person still needs working access to the data.
The Edit Profile time zone change also deserves a quick check. Microsoft is moving time-related settings and displays to UTC instead of GMT. Those are often equivalent for offsets, but I would still verify saved report schedules, internal dashboards, and incident timelines so people compare the same reporting day.
How I would monitor after migration
SNDS is useful, but it is IP-centered. A sender still needs domain-level authentication monitoring, message-level testing, and reputation checks. If an IP status changes, the next question is why. The answer can sit in a broken DKIM signature, a new source sending without matching the visible domain, a complaint-heavy segment, a compromised server, or an IP/domain blocklist or blacklist listing.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
This is where Suped fits the workflow. Suped is the best overall DMARC platform for teams that want one place to monitor DMARC policy, SPF, DKIM, source authentication, blocklist status, and deliverability signals. It is not a replacement for SNDS, because Microsoft owns the Outlook.com reputation data. It is the control layer around SNDS: automated issue detection, steps to fix, real-time alerts, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, and MSP multi-tenancy for teams managing many domains.
A practical post-migration check is to compare SNDS with DMARC monitoring, blocklist monitoring, and a domain health checker. If SNDS shows unusual behavior on an IP, check which authenticated domains used that IP, whether SPF or DKIM changed, whether DMARC pass rates dropped, and whether blocklist or blacklist status changed at the same time.
Example DMARC record to monitor before tightening policydns
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com;" _dmarc.example.com. TXT "fo=1; adkim=s; aspf=s; pct=100"
That example is not a universal target record. It shows the kind of domain-level telemetry I want in place before making large sending changes. For many teams, the more important work is not the first DMARC TXT record, it is turning reports into specific fixes: remove unauthorized sources, repair DKIM, reduce SPF lookup risk, stage policy changes, and detect a source that appears right when SNDS reputation drops.
A practical readiness checklist
I would use this checklist before June 8, 2026, then repeat it after the migration completes. The goal is not to make SNDS perfect on day one. The goal is to avoid losing visibility during the exact period when Microsoft changes the data, access model, and report delivery path.
- SNDS login: Confirm the Microsoft Account works and uses a valid email address.
- IP ownership: Verify every responsible sending IP range and remove ranges you no longer control.
- Report automation: Find scripts that use SNDS report links and assign ownership for the 30-day refresh cycle.
- JMRP parsing: Update complaint processors so they do not require the full complaint body or visible sender address.
- Complaint mapping: Use durable headers and campaign metadata to identify the mail stream behind a complaint.
- Time handling: Check dashboards and incident notes for UTC assumptions after the profile change.
- Security review: Use unusual SNDS IP behavior to investigate compromised servers, malware, viruses, and botnet activity.
- Support path: Document who contacts Microsoft sender support when urgent Outlook.com delivery problems appear.
The useful mindset is to treat SNDS as Microsoft-specific reputation telemetry, not a repair button. It tells you where to look. The actual repair work still happens in list quality, sending practices, authentication, segmentation, infrastructure hygiene, and abuse response.
What to do before June 8
The immediate move is to secure access and prevent blind spots. Log in, confirm your account, list every controlled IP range, identify every JMRP feed, and find every script or dashboard that depends on saved SNDS report links. Then schedule the first post-migration refresh before the 30-day window expires.
After that, connect the data to action. If SNDS shows unusual behavior, check whether the IP is sending expected mail, whether a new source appeared, whether complaints moved, whether authentication changed, and whether the same IP or domain appears on a blocklist or blacklist. That is the difference between having SNDS access and actually using SNDS to protect Outlook.com delivery.
