Microsoft has stopped including spam-trap hit counts in the Smart Network Data Services (SNDS) Data Report, with the change taking effect on 22 July 2026. The company’s SNDS announcement says the removal is “to protect the integrity and effectiveness of our anti-abuse systems”, and cautions that values shown during the transition may differ from previous reports and should not be treated as exact. For senders into Outlook.com, Hotmail, and Microsoft’s consumer mailboxes worldwide, this removes one of the few first-party signals available for identifying acquisition, hygiene, and infrastructure problems, and it lands on top of a June overhaul that has already disrupted complaint processing pipelines.
What changed on 22 July
Trap-hit counts have long been the bluntest and most useful warning in SNDS. A pristine trap hit points at acquisition problems. A recycled trap hit points at stale data and broken bounce handling. Neither shows up in engagement metrics or complaint rates until real damage is done, which is precisely why the SNDS column mattered. From 22 July it is gone, and Microsoft’s transition caveat means even recent historical values should be treated as directional rather than exact.
Senders do not lose the consequences of hitting traps. They lose the visibility. Reputation damage from poor list hygiene will still arrive, but the earliest first-party indicator of why has been switched off.
The June overhaul it sits on top of
The trap-data removal compounds the broader SNDS and JMRP migration Microsoft has been rolling out through 2026, which we detailed in our guide to the SNDS and JMRP overhaul and what to fix. The old portal and automated-access model have been replaced, with legacy automated access URLs on the sendersupport.olc.protection.outlook.com domain deprecated from 22 June and senders required to generate and maintain new access links.
The complaint side is where the operational pain concentrates. JMRP reports have moved to header-only ARF format. Original message headers and selected authentication headers survive, but the complainant’s address is redacted and the original message body is removed entirely. JMRP feeds must also be correctly associated with SNDS accounts to keep flowing. Any complaint-processing parser that identified complainants from the forwarded body, or from visible recipient information, no longer has that data to parse.
Why this matters
The immediate risk is silent suppression failure. If a parser cannot identify who complained, the complainant is not suppressed, and a recipient who has already told Microsoft they consider the mail spam keeps receiving it. That compounds: unsuppressed complainants generate repeat complaints, repeat complaints degrade reputation, and the sender now has less telemetry with which to diagnose the decline. A complaint feed that quietly stopped working is worse than one that visibly broke.
The structural story is the steady narrowing of first-party mailbox provider data. Redacted complaint reports, removed message bodies, and now withdrawn trap telemetry all follow the same logic: mailbox providers protecting anti-abuse systems and recipient privacy by sharing less. The reasoning is defensible. The consequence for senders is that attribution must now be self-supplied. If your identifiers do not travel in headers, they do not travel at all.
What senders should do now
Audit every Microsoft complaint parser and SNDS integration, and do it against live data rather than assumptions. Confirm that Message-ID, Feedback-ID, DKIM selector, sending IP, and your internal campaign identifiers survive intact in the new ARF reports, because these headers are now the only complaint-attribution path you have.
Verify end to end that automated suppression still functions without message-body data, ideally by tracing a known test complaint through the pipeline. Check that JMRP feeds are correctly associated with the right SNDS account, and that automated access links have been regenerated on the new model rather than pointing at deprecated URLs. With trap-hit telemetry gone, bring forward the disciplines it used to backstop: stricter acquisition standards, tighter bounce handling, and sunset policies that retire unengaged addresses before they can become recycled traps you will no longer see yourself hitting.
Additional info:
Microsoft SNDS announcement confirming removal of trap-hit counts from the Data Report.
Microsoft SNDS FAQ noting the automated access URL deprecation.
