Microsoft SNDS 2026 changes: what senders need to know before June 8
News
Updated on 25 Jun 2026: We updated this guide for post-migration SNDS cleanup, automated URL replacement, and JMRP complaint-address handling.
Microsoft moved SNDS out of the old Smart Network Data Service portal after the June 8, 2026 cutover, after roughly 20 years of senders using it to monitor Outlook.com reputation. The direct answer now is simple: senders should confirm that old bookmarks redirect, replace old automated access URLs before Microsoft deprecates them on June 22, 2026, refresh ownership of controlled IP ranges, verify JMRP feeds, update report automation, and confirm complaint processors handle the new header-only ARF format.
Microsoft posted the current details on Microsoft SNDS. The old page now redirects to the new portal. Microsoft says automated access URLs that begin with the old SNDS path are being deprecated by June 22, 2026. Microsoft also notes that some users who see an automated-link creation error can go to Edit Profile, make a change, save it, and retry the link creation. Treat every old SNDS bookmark, feed, and report URL as something to verify.
- Now: 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 in the new portal.
- By June 22, 2026: Replace old automated access URLs, test new report links, and confirm failures are visible in monitoring instead of silent.
- After migration: Refresh automated report links within 30 days, plan recurring refreshes every 30 days after that, 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.
Post-migration fixes to make now
Because the cutover already happened, the work is now verification rather than preparation. Check what actually broke: browser access, saved report URLs, API pulls, JMRP complaint delivery, and internal dashboards.
- Replace old automated access URLs: Old URLs that begin with the previous SNDS path need replacement before the June 22, 2026 deprecation deadline.
- Test automated link creation: If the portal returns a save error while creating a new automated link, use the Edit Profile save workaround and then retry.
- Confirm JMRP destinations: Check that each complaint feed is tied to an SNDS account with current network access and that the mailbox still forwards to the right complaint processor.
- Annotate reporting: Mark June 8 and June 22, 2026 in dashboards so API errors, missing rows, or changed columns are not mistaken for normal reputation movement.
What changed after June 8
The June 8 change was not only a cosmetic portal move. It changed 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 now redirect after migration, and the post-cutover window includes a June 22, 2026 deadline for replacing old automated access URLs.
|
|
|
|---|---|---|
Portal | New portal live | Update bookmarks |
Reports | REST API | Revise pulls |
Links | 30-day expiry | Refresh monthly |
Old URLs | June 22 deprecation | Replace now |
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.
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 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. That is a warning against dashboard watching without list hygiene, complaint management, authentication checks, and fast investigation when a controlled IP starts behaving differently.
For domains sending more than 5,000 messages per day to Outlook.com, SNDS also sits next to Microsoft's high-volume sender requirements. Those senders need SPF, DKIM, and DMARC with at least p=none, plus either SPF or DKIM matching the visible From domain. A 550; 5.7.515 rejection points to authentication compliance, not missing SNDS access.
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.
Post-migration 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, authentication and inbox testing deserve review 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 post-migration state is routine cleanup 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.
If the migration exposes a stale JMRP complaint address, do not try to fix it with SPF, DKIM, or DMARC DNS changes. The destination mailbox belongs to the JMRP feed configuration for the IPs. Keep the old mailbox forwarding if possible, confirm which Microsoft account controls the feed, and ask Microsoft or the IP owner to clear the stale association before recreating the feed with the new address.
For teams sending through an email service provider, the hard part is often proving who controls the responsible IPs. If that is your setup, 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 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 SNDS reports moving to the new portal, REST API, and monthly refresh.
- 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.
- Replace old URLs: Update automated access URLs that still begin with the old SNDS path before the June 22, 2026 deprecation deadline.
- 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 now uses UTC instead of GMT for time-related settings and displays. Those are often equivalent for offsets, but saved report schedules, internal dashboards, and incident timelines still need verification so people compare the same reporting day.
How to 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
Suped's product fits around this workflow. Suped is not a replacement for SNDS, because Microsoft owns the Outlook.com reputation data. Use Suped to monitor the controls around SNDS: DMARC policy, SPF, DKIM, source authentication, blocklist and blacklist status, issue 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; fo=1; adkim=s; aspf=s"
That example is not a universal target record. It shows the kind of domain-level telemetry to keep 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
Use this checklist after migration and again before the June 22, 2026 automated URL deadline. The goal is not to make SNDS perfect on day one. The goal is to avoid losing visibility while 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.
- Automated URLs: Replace old automated access URLs before Microsoft deprecates them on June 22, 2026.
- JMRP parsing: Update complaint processors so they do not require the full complaint body or visible sender address.
- Complaint address: Use a role mailbox or durable alias, and keep the old mailbox forwarding during any JMRP feed change.
- 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 hosts and botnet activity.
- Support path: Document who contacts Microsoft sender support when urgent Outlook.com delivery problems appear.
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 now
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 complaint address, replace old automated access URLs, 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.
