Email deliverability monitoring just lost its early warning

If your outbound program has felt quieter than usual since late July, nothing improved. Microsoft stopped telling you when you hit a spam trap, and it stopped telling you who complained. The alarms did not go off because the alarms were removed.

This is the kind of change that does no damage on the day it happens and a lot of damage two months later. Email deliverability monitoring is early-warning work: the entire value is catching a bad list, a compromised sender, or a drifting reputation before it costs you a domain. Take away the leading indicators and you find out about problems the same way everyone else does, which is when replies stop.

What Microsoft removed, and when

Four changes landed between early June and late July, documented by Postmastery in a July 27 write-up of the first significant SNDS update in years. They are worth separating, because two are administrative and two are substantive.

Postmastery's assessment of the trap change is blunt: it is the most significant loss of visibility for deliverability teams using SNDS for list hygiene monitoring. That is not an overstatement. Nothing else in the free tooling tells you the same thing.

Why trap hits mattered more than they looked

A spam trap hit is the cheapest possible proof that a list is dirty. Traps are addresses that cannot have opted in, because they were never real people or have been dead for years. Hitting one is unambiguous. There is no interpretation step, no benchmark to argue about, no vendor spin.

For outbound teams the trap counter did a specific job: it caught bad data before the reputation damage compounded. A scraped list, a stale enrichment export, a purchased file someone bought against policy, a waterfall provider that started guessing more aggressively. All of those show up as trap hits before they show up as complaint rates, and well before they show up in reply rates.

The uncomfortable part is that nothing free replaces it. You can pay for list validation before sending, which is a different control at a different point in the process, and you should. But pre-send validation catches syntax, domain validity, and known-bad addresses. It does not reliably catch a recycled trap, which is exactly the kind that punishes you for using old data. Our five-play deliverability playbook leaned on trap visibility as a check inside play one; that check now has to be rebuilt around vendor tooling or dropped.

The complaint feed problem is worse

The JMRP change is the one that will break automation quietly. Microsoft dropped its proprietary recipient header and replaced the To line with a placeholder, so complaint reports arrive without saying who complained. Reports began appearing in the new format around June 11 and scaled through the following week.

Every suppression pipeline built on parsing the recipient out of a complaint report is now silently failing. Silently is the operative word. The reports still arrive, the parser still runs, and it extracts a placeholder instead of an address. Depending on how the code was written, you are either suppressing nothing or suppressing a literal placeholder string, and either way the person who complained is still on your list and will complain again.

1. Check the last 60 days of suppressions sourced from Microsoft complaints.
   A sharp drop to near zero from mid-June is the signature.
 
2. Switch correlation from recipient address to one of:
   - Message-ID logged at send time
   - a custom X-header carrying an opaque send token
   - VERP return-path encoding the recipient
 
3. Backfill: any complaint received since June 11 that you could not
   resolve is an unsuppressed complainer. Treat as unknown risk.
 
4. Add a monitor that alerts when complaint-derived suppressions
   fall below a floor. The failure mode is silence, so alert on silence.

Point four is the general lesson and it is worth more than the specific fix. Most deliverability alerting is built to fire when a bad number goes up: complaint rate climbing, bounce rate climbing, spam verdict flipping. Almost none of it fires when a feed stops producing data at all, which is how a two-month outage goes unnoticed inside a team that believes it is monitoring carefully. Every input to your reporting should have a heartbeat check, and the check should be loud. If you take one thing from this, alert on the absence of signal, not just on the presence of a bad one.

Point three deserves a note as well, because it creates a compliance exposure rather than just a data gap. Anyone who complained to Microsoft since mid-June and could not be resolved back to an address is still receiving your mail. In an outbound context that is a person who took the strongest available action to tell you to stop and got no effect. Whatever your legal position, a repeat send to a confirmed complainer is the fastest route to a provider-level reputation problem, and it is the exact pattern regulators have been penalising.

There is a live disagreement about how to characterise the JMRP change. Some observers framed it as a routine migration to the ARF standard. The more careful reading, argued by emailexpert in June, is that ARF migration and redaction are two separate things and the redaction is the part that matters. That distinction is not academic: if you believe it was a format migration, you update a parser and move on, and your suppression stays broken.

Email deliverability monitoring after the blackout

What survives is thinner and more expensive, but it is not nothing. Rank the remaining signals by how much they actually tell you, not by how easy they are to collect.

Note the shift in where the burden sits. Two of the four are things you pay for and two are things you instrument yourself. The era of running outbound deliverability on free provider dashboards is closing, and the teams that will notice last are the ones who never built first-party monitoring because the free tools were adequate. If you want the audit version of this, we walked through the checks in the deliverability audit that finds the real gap.

The replacement standard is not coming soon

There is a genuinely promising answer in flight, and it is worth knowing about precisely so you do not wait for it. Aggregate Performance Reporting is an IETF draft co-authored by Alex Brotman at Comcast, Tom Corbett at Iterable, and Emil Gustafsson at Google. It works like DMARC: publish a DNS record, receive daily aggregated JSON reports covering inbox versus spam placement plus engagement events including complaints, unsubscribes, deletions, and rescues from the spam folder.

That would be a real upgrade. It would give senders actual placement data instead of inference from seed tests, and it would do it in aggregate, which is how a provider can share placement without exposing individual mailboxes. Google being a co-author is the encouraging part, because Google is the only participant whose adoption would change the arithmetic for most senders overnight.

The problem is adoption. As of Al Iverson's July write-up, the only mailbox provider in beta is Comcast. To size that: Iverson's August breakdown of one anonymised consumer list put Gmail at 60.00% of addresses, Yahoo properties at roughly 20%, Microsoft consumer domains at roughly 4.7%, and Comcast at 1.8%. That is a business-to-consumer list rather than an outbound one, so do not map the percentages onto your own file, but the ranking holds: the sole participating provider is a rounding error on almost everybody's list.

“A standard with one participant is a proposal. Plan for the tooling you have, and treat the standard as upside if it ships.”

The stack to run this quarter

Concrete, in order, and none of it takes longer than a week. First, audit your complaint-derived suppressions for a June collapse and rewire correlation to Message-ID or VERP. Second, add an alert that fires when any feed stops producing records. Third, revalidate your SNDS delegations and export your historical CSVs before the 30-day windows close them off. Fourth, put pre-send validation in front of every imported list, and record which vendor supplied each one so you can still attribute a bad file without trap data.

Fifth, and this is the one that survives every tooling change: send less to better lists. Every threshold Microsoft and Google enforce is a rate, and rates are forgiving of small, clean, well-targeted volume in a way they are not forgiving of scale. We made the case with the numbers in the real cost of skipping email warmup, and it applies double now that the early-warning layer is thinner. Teams running cold email programs at volume should treat this summer as the moment the monitoring cost moved onto their own books.

Sources: Postmastery on the SNDS update, July 27, 2026 (Postmastery); emailexpert on JMRP redaction, June 18, 2026; Al Iverson at Spam Resource on the APRF draft, July 19, 2026, and the list composition breakdown, August 10, 2026.

See where you are cited today

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