For years, Smart Network Data Services has been the closest thing senders had to a direct line into how Microsoft’s consumer mailboxes, Outlook.com and Hotmail, actually judge their traffic. It is free, it is first party, and unlike anything Google or Yahoo publish, it used to tell you exactly when your mail hit a spam trap. This summer, Microsoft rolled out the biggest set of changes SNDS has seen in years, and the headline change is one senders will feel immediately: as of July 22, 2026, trap hit counts are gone from the Data Report entirely.
What Actually Changed, and When
The update arrived in stages. On June 8, 2026, Microsoft moved SNDS to a new portal at a new address, substrate.office.com, with the old URLs redirecting for a transition window. On June 11, Microsoft rewrote how Junk Mail Reporting Program complaints are delivered, switching to standard ARF formatting, removing the header that carried a complainant’s raw email address, and no longer appending the original message body to the forwarded complaint. Automated access to the old SNDS URLs was cut off on June 22. Then, on July 22, trap hit counts disappeared from the Data Report altogether. Microsoft has also added stricter authentication for approving or denying SNDS access requests, closing off a path where security scanners and link preview tools could accidentally trigger an approval. In exchange, the platform now offers a modern OAuth 2.0 REST API for pulling data reports and IP status programmatically.
Why Losing Trap Hit Counts Is the Change That Stings
A pristine spam trap, an address that never opted in and never sent a real message, only exists on a list if it was bought, scraped, or harvested. A recycled trap, a formerly real address that went dormant and was reclaimed, only shows up if bounce handling is broken and stale data is still being mailed. Trap hit counts in SNDS were the bluntest, most actionable version of that signal available to any sender, free, without needing a third party seed list program. Losing that visibility does not mean Microsoft stopped tracking trap hits internally. It means senders can no longer see them coming before deliverability quietly degrades.
The JMRP changes compound the problem. Any complaint processing workflow that identified a complainant by parsing the forwarded message body or a header carrying their address now has nothing to parse. A parser that cannot match a complaint back to a recipient cannot suppress that recipient, which means someone who has already told Microsoft they consider your mail spam keeps receiving it, filing more complaints, and pushing your sender reputation down further.
Why This One Sits Inside Your DMARC Program, Not Outside It
Most of what gets covered here involves attackers finding channels DMARC was never built to police. This is different. SNDS and JMRP are tools deliverability teams use every day to keep the sending infrastructure that DMARC, SPF, and DKIM authenticate looking clean in the eyes of a major mailbox provider. When Microsoft narrows what it shares back, the value of your own independent authentication data goes up, not down. DMARC aggregate reports come from the receiving side of every domain that gets your mail, not just Microsoft, and they are not subject to a single provider deciding to stop publishing a field. They remain a first party record of exactly which infrastructure is sending as your domain, authenticated or not, regardless of what SNDS chooses to show.
What This Means for Your Program
Update your JMRP complaint parsing before it silently breaks. If your suppression workflow relies on the old header or the message body to identify complainants, it is already receiving less than it expects. Rebuild it against the standard ARF format Microsoft now sends.
Migrate to the new SNDS portal and API before your automated pulls fail. The old automated access URLs stopped working on June 22, 2026. Any dashboard or script still pointed at them is running on borrowed time.
Replace trap hit visibility with proxy signals. Watch complaint rate trends, hard bounce rate, and unknown user rate together. A spike across all three without a matching sending change is the closest available substitute for the warning trap hits used to give you.
Lean harder on DMARC aggregate reports for the visibility Microsoft is narrowing. They tell you which IPs and services are sending as your domain independent of any single mailbox provider’s product decisions, and that independence matters more with every signal a receiver decides to stop sharing.
The Takeaway
None of these changes are dramatic on their own, a new URL, a stripped header, a missing column in a report. Together they describe a mailbox provider pulling back the amount of raw signal it hands senders for free, while keeping the enforcement decisions those signals used to explain. That trend was already visible in how Gmail, Yahoo, and Microsoft have moved from routing suspect mail to junk toward rejecting it outright for repeat offenders. The senders who stay ahead of it will be the ones who stop depending entirely on a receiver’s dashboard and build their own independent record of what is actually leaving their infrastructure.
As mailbox providers share less of their own signal, your DMARC aggregate reports become one of the few sources of truth you fully control. Excello Mail turns that raw XML into a clear picture of every service sending as your domain, authenticated or not. Sign up for free to Excello Mail and keep your own visibility intact, no matter what a receiver decides to stop publishing next.