Cold email deliverability monitoring after Microsoft pulled SNDS trap data

For years, the most useful number in Microsoft's Smart Network Data Services report wasn't the complaint rate or the IP reputation flag. It was the trap-hit count -- a small line that told you, plainly, whether you'd mailed an address Microsoft had specifically planted to catch bad list hygiene. As of July 22, 2026, that line is gone.

This piece is for anyone running cold email at real volume into Outlook.com, Hotmail, or corporate Microsoft 365 inboxes. It walks through exactly what changed, why the specific number that disappeared mattered more than it looked, and what to build in its place.

What Microsoft actually changed

Three separate changes shipped inside the same window, and it's worth separating them because they compound rather than repeat. First, on June 8, 2026, Microsoft migrated SNDS from its long-standing address at sendersupport.olc.protection.outlook.com to a new portal at substrate.office.com. Second, the legacy automated-access URLs -- the ones deliverability teams had scripted their monitoring around for years -- stopped resolving on June 22, 2026. Third, and most consequential, Microsoft removed spam-trap hit counts from the SNDS Data Report on July 22, 2026, stating the change protects the integrity and effectiveness of its anti-abuse systems.

None of this was hidden -- Microsoft published the change, and deliverability-focused coverage of the trap-hit removal landed on consistent dates and details independently of Microsoft's own notice. But "published" and "noticed by the team running your warmup schedule" are different things, and a portal migration that also quietly removes a monitoring signal is exactly the kind of change that gets absorbed as a UI annoyance rather than flagged as a strategy problem.

Why trap-hit data mattered more than it looked

A spam trap is an email address Microsoft controls specifically to catch senders with bad list hygiene. There are two kinds, and they told you different things. A pristine trap -- an address that was never a real inbox, just planted to catch scrapers and guessed addresses -- hitting it meant your list acquisition process itself was the problem: you were buying, scraping, or guessing addresses rather than collecting them with consent. A recycled trap -- a real address Microsoft reactivated after it went dead -- hitting it meant your list was stale and your bounce handling was broken, letting dead addresses sit in rotation instead of getting suppressed.

The reason this distinction mattered operationally is that the two failures have completely different fixes, and a team without the trap-hit split was flying blind on which one to run. A pristine-trap problem gets fixed upstream, at the sourcing and verification stage, before an address ever enters a sending list. A recycled-trap problem gets fixed downstream, in bounce processing and list-aging policy, regardless of how clean the original acquisition was. Conflate the two and you either over-correct on sourcing when your real problem is stale suppression, or you tighten suppression rules when your real problem is where the addresses came from in the first place. SNDS used to hand you that diagnosis for free. It doesn't anymore.

“Senders do not lose the consequences of hitting a trap. They lose the visibility into having hit one.”

The JMRP change compounds the problem

Junk Mail Reporting Program feedback -- the complaint reports Microsoft sends when a recipient marks your email as spam -- changed around the same window, and the change matters more than it sounds. Reports moved to a header-only ARF format: no original message body, and the complainant's address redacted. That's a reasonable anti-abuse decision on its own. But most automated suppression pipelines were built to parse specific fields out of a full report, and a header-only format with a redacted complainant can silently break exactly the automation that's supposed to catch bad sends before they repeat.

The failure mode is quiet by design: if your parser can't reliably identify who complained from the new format, that recipient doesn't get suppressed, and someone who has already told Microsoft they consider your mail spam keeps receiving it. Nothing errors out. Nothing alerts you. Your complaint rate just climbs for a reason your dashboard doesn't explain, in the exact same month the trap-hit signal that might have flagged the underlying list problem also went dark.

Two other operational details from the same migration are easy to miss and worth checking directly rather than assuming they don't apply to you. JMRP feeds are now required to be linked to an SNDS account with current, valid network access -- standalone feeds that used to run independently were removed at the cutover. And the new automated-access URLs carry a 30-day expiry, which means a monitoring script that authenticated once and has been running unattended since is very likely already pulling stale or empty data without anyone noticing, because a 404 buried inside a scheduled job rarely gets the same attention as a dashboard that visibly stops updating.

What replaces the visibility you lost

Microsoft's own documentation doesn't offer a replacement signal, so the plays here are what we're recommending to clients running Microsoft-heavy sends, not a Microsoft-endorsed workaround.

Start by auditing your complaint-processing pipeline against a live sample of the new ARF format, not the old one. Confirm your parser can still recover Message-ID, Feedback-ID, DKIM selector, sending IP, and whatever internal campaign identifier you rely on to trace a complaint back to a specific send. Then run an end-to-end suppression test: send a seed complaint through the new report format and verify the address actually gets suppressed, not just logged. A pipeline that silently stops suppressing on bad input is worse than no pipeline, because it looks healthy in every dashboard that isn't specifically checking outcomes.

With the trap-hit backstop gone, the acquisition and hygiene discipline that trap hits used to catch after the fact has to move earlier. That means verification at time of send rather than time of acquisition, since a list that was valid when it was built can decay well before you mail it. It means the layered SPF/DKIM/DMARC, folder-placement, and engagement-throttling audit we run before any Microsoft-heavy send, because several of those checks were partially redundant with trap-hit monitoring and now carry more of the load alone. And it means treating engagement-based signals -- opens, replies, and especially unengaged-recipient sunset policies -- as your primary early-warning system going forward, since Microsoft itself points list hygiene practices at exactly this replacement.

Where this fits in your deliverability stack

This isn't the first time Microsoft has tightened the screws on bulk senders, and it won't be the last. We've written before about the three-stage throttle-quarantine-block enforcement Microsoft runs on bulk senders; this SNDS change is a different kind of tightening, one that removes a monitoring tool rather than adding an enforcement stage. The two compound: the enforcement stages didn't get gentler, and the early-warning system for staying out of them just got quieter. A B2B team running high-volume outbound to enterprise buyers, where Microsoft 365 inboxes make up a large share of the destination domains, is exactly the profile most exposed to both changes landing in the same summer.

Bake this into how you evaluate any cold email program, your own or a vendor's: ask specifically how complaint suppression is verified against the new ARF format, not just whether SPF/DKIM/DMARC pass. Authentication was never the part of the stack this change touched. List hygiene monitoring was, and that's the part worth re-auditing now, deliberately, rather than waiting to notice it in a slowly rising complaint rate with no trap-hit data to explain why.

It's also a useful test of how a vendor or an internal team actually operates versus how they describe themselves. Anyone can claim to run a clean list. Fewer teams can name, specifically, what replaced trap-hit monitoring in their process after July 22, 2026, and fewer still will have already run the seed-complaint suppression test rather than assuming the pipeline still works because nothing has visibly broken. That gap between assumed-fine and verified-fine is exactly where reputation damage accumulates quietly for months before it shows up as a sudden inbox-placement problem with no obvious trigger.

Why this matters more for cold outreach than for marketing email

Permission-based marketing lists and cold outbound lists sit on very different footing here, and it's worth being explicit about why cold email is more exposed. A marketing list is built from opt-ins, so pristine-trap risk is structurally low from the start -- nobody opts in with a planted address. Cold outbound lists are built from enrichment, scraping-adjacent tooling, and inferred or guessed patterns at some point in nearly every stack, which is precisely the acquisition behavior pristine traps exist to catch. Losing the clearest signal for that specific risk lands harder on outbound programs than on retention or newsletter sends, even though both are nominally affected by the same SNDS change.

Do this before your next send

Pull a current SNDS report from the new portal and confirm your access, your IP ownership records, and your JMRP feed linkage are all still valid under the post-migration model -- standalone JMRP feeds without a linked, current SNDS account were removed at cutover, so a broken linkage here fails silently rather than loudly. Then run the suppression test described above with a real seed complaint, not a hypothetical one. If either check turns up a gap, close it before your next send, not after your complaint rate tells you it mattered.

See where you are cited today

A free snapshot audit of your rankings and AI citations before we ever talk.