DMARCbis, a Major MTA Migration, and Gmail's New Visibility Problem
This Week in Email — May 19, 2026
Four things worth your attention this week. The long-running work to replace the DMARC spec has produced something concrete enough to read now. Postmark did something relatively unusual: swapped out their entire MTA stack and published what it cost them and what it bought them. A Spam Resource post on DKIM2 flagged a specific infrastructure consequence for sending platforms that's been underexplored. And Folderly published analysis of what Gmail's Gemini integration is actually doing to email visibility — not at the filter, but inside the inbox.
The DMARC spec is getting a rewrite — here's what changes in DMARCbis
The DMARC standard (RFC 7489) has been the foundation of email authentication enforcement for over a decade, and it's being replaced. DMARCbis is the successor spec, and it's close enough that Spam Resource published an explainer worth reading now.
The biggest structural change: DMARCbis replaces the Public Suffix List (PSL) with a DNS Tree Walk for Organizational Domain determination. This matters because the PSL is a manually maintained, browser-originating list that requires ongoing curation and has documented gaps. DNS Tree Walk derives organizational domain boundaries directly from DNS — protocol-native, no third-party registry dependency. For senders with complex subdomain structures, this changes how receiving providers evaluate alignment.
The deprecated tags are pct, rf, and ri. Of these, pct has the most practical consequence — it's the throttle most senders used during p=quarantine or p=reject rollouts to phase in enforcement gradually. It's going away. If you have pct=<100 in production DMARC records, that's cleanup work.
New in DMARCbis: np controls policy for non-existent subdomains, psd handles public suffix domain scenarios, and t provides a testing mode that replaces the intent of pct more cleanly.
Backward compatibility is real: existing v=DMARC1 records continue to work. This isn't an immediate breaking change. But if you own authentication infrastructure for a large sending domain, the organizational domain logic change is worth modeling before enforcement shifts, not after.
Postmark replaced its entire MTA stack with KumoMTA and published the numbers
Postmark migrated all their email traffic from PowerMTA to KumoMTA and wrote it up. The full post is worth reading if you have any investment in MTA architecture decisions.
The headline results: Gmail average queue times dropped from roughly 2 seconds to 1.2 seconds. Yahoo improved from 4.6 seconds to 3.2 seconds. These are across Postmark's full production traffic — not a synthetic benchmark or a pilot segment.
The migration case is straightforward on its face: PowerMTA is a 20-year-old proprietary system, proven and deeply understood, but not designed for how engineering teams want to configure and operate infrastructure today. KumoMTA is open-source, written in Rust, Lua-scriptable, and built specifically for modern high-volume sending workloads. Postmark ran them in parallel before cutting over completely.
The more interesting signal is what this says about the broader market. KumoMTA has attracted serious evaluation from multiple sending platforms over the past couple of years. Postmark's move is the kind of public, results-bearing case study that changes the conversation. When a sender with that reputation and traffic volume publishes positive post-migration data, platforms still weighing the switch have something concrete to point to.
For anyone building or operating ESP infrastructure: this post is a reference document now.
DKIM2 is changing the sync/async bounce ratio — sending platforms should model this now
Spam Resource published a post on an underexplored DKIM2 consequence: the effect on bounce infrastructure at sending platforms.
The mechanism: DKIM2 shifts receiving providers toward deferred rejections over immediate ones. In the current architecture, many authentication failures surface synchronously — the SMTP transaction fails, the sending MTA gets an error code immediately, and the bounce is handled in the delivery session. Clean.
With DKIM2's deferred model, more failures happen after the SMTP session closes. Those async bounces land on VERP addresses — the per-message tracking addresses that sending platforms generate to attribute bounces back to specific sends. The ratio of synchronous to asynchronous failures shifts significantly.
The practical consequence: systems sized and designed around today's sync/async ratio will face higher async bounce volumes under DKIM2. If your bounce processing pipeline has implicit assumptions about how many failures hit VERP asynchronously, DKIM2 is the forcing function that surfaces those assumptions.
This is not a production problem today — DKIM2 is still a draft. But infrastructure decisions being made now will need to handle it eventually. If you own the bounce processing layer for any sending platform, the post is worth reading before those assumptions get baked in any deeper.
Gmail's Gemini AI is reducing visibility for low-value mail inside the inbox, not at the filter
Folderly published analysis of what Gmail's Gemini features are doing to email visibility in 2026. The framing matters: this is not a spam filter problem. These are messages that reach the inbox. The visibility reduction happens after delivery.
The mechanism: Gmail's summarization, prioritization, and digest features use Gemini to classify message value. Messages classified as low-value get deprioritized — they arrive in the inbox but are less likely to appear in summary views, be surfaced by AI-generated digests, or get visual prominence. Folderly estimates up to 40% of Gmail inbox emails face some level of reduced visibility through this layer.
The metric consequence is significant: this doesn't show up in bounce rates, spam rates, or inbox placement tests. The message delivered. The subscriber just didn't see it. If you're tracking engagement metrics and something isn't adding up at the Gmail segment level, this is worth investigating.
The operational signal Folderly identified: the first 100–200 characters of the message body — subject line plus opening sentence — are the primary signal for Gemini's initial classification. Generic openers get the same treatment as low-value transactional mail.
One caveat worth noting: Folderly is a deliverability tool vendor, and the 40% figure is their modeling estimate, not Google's published data. The mechanism is real and documented; the magnitude is an estimate. Weight it accordingly.
Links worth your time
DKIM2 and email evidence in court — Spamtacular made the case that DKIM2's signature-chain model changes how email functions in litigation. Signatures validate against DNS-published public keys; the result is that a signed message shifts from "consistent with the record" to "definitively verified." Forgery or denial of origin becomes untenable. Useful framing if you're having conversations with legal or compliance teams about why authentication infrastructure matters beyond deliverability. (spamtacular.com)
That's the week. If something is wrong, reply and tell me — I read every response.