ARC is on its way to Historic. The CNIL's pixel deadline is six weeks out and ESPs aren't shipping the features to comply. Microsoft just rebuilt the postmaster tooling half the deliverability industry runs scripts against. DKIM2 has two adoption calls closing this Friday. And GMX, WEB.DE, and mail.com just started rejecting at the door across 42 million European mailboxes. Heavy week. Let's get into it.

This is the big one. The IETF DMARC working group was rechartered on April 16 with one job: move Authenticated Received Chain from Experimental to Historic by November 2026. The first concrete document — draft-ietf-dmarc-arc-to-historic-00 — was submitted April 22 and is in WG review now. The successor in flight is DKIM2 (the working group is calling it per-hop chained signatures), which signs the SMTP envelope and absorbs what ARC was bolted on to do.

ARC isn't going dark tomorrow. It's still a hard bulk-sender requirement at iCloud and a forwarder requirement at Gmail, and that posture won't flip on a draft's say-so. But if you've built your forwarder strategy, your mailing-list architecture, or your iCloud-compliance argument around "we have ARC sealing in place," the standards story underneath that assumption just moved. The migration window is multi-year. The direction is settled.

The through-line worth tracking: ARC out, DKIM2 in. They're not parallel tracks — they're a handoff.

Sources: draft-ietf-dmarc-arc-to-historic-00 (IETF Datatracker), Suped: ARC is being retired — what the IETF draft means for DMARC teams

The CNIL adopted its tracking-pixel recommendation March 12, published it April 14, and gave controllers a three-month transition period for addresses collected before publication. That window closes around July 14, 2026. After that date, any pixel firing in mail to a French recipient on a pre-April-14 address needs notification plus a lawful basis — typically consent, with a narrow deliverability-purpose carveout. Addresses collected since April 14 have no grace period at all. Italy's Garante issued parallel guidance.

Here's the operational gap Spam Resource flagged on May 29: ESPs aren't shipping the product features required to comply. There's daylight between the legal posture and what platforms can actually deliver. Per-recipient pixel toggles, jurisdiction-aware pixel suppression, consent capture tied to the pixel use case — most ESPs don't expose any of that yet.

If you send to French recipients, this is the vendor conversation you need to be having right now, not in early July. And if you're an ESP, the next six weeks are when your customers are going to start asking pointed questions about what you'll have shipped before the deadline.

Sources: Inside Privacy (Covington): CNIL Publishes Recommendation on Email Tracking Pixels, Spam Resource: CNIL open tracking restrictions are coming and complex

If you run a deliverability program at any scale, you have scripts pointed at SNDS. Microsoft just changed the rules. The portal is migrating to a new URL. JMRP reports are now standardized on ARF format with sender addresses redacted and message bodies stripped. Complaint sample downloads are gone from the SNDS portal entirely. Automated report links expire after 30 days — existing links must be refreshed. JMRP feeds not linked to an SNDS account get purged. A new REST API replaces some of what the portal used to deliver.

The operational consequence: complaint attribution can no longer rely on body-content parsing. If you aren't already injecting Campaign-ID, Message-ID, Customer-ID, and List-ID headers at send time, you're about to lose the ability to attribute Microsoft complaints back to specific campaigns at all.

Action items this week if you maintain a sending platform: audit which JMRP feeds are still attached to active SNDS accounts, refresh any automated report links older than 30 days, add the four identifying headers to your outbound MIME injection layer, and stand up the new REST API path before your existing portal scrapers go dark.

This one quietly becomes a Monday morning crisis call if you don't act before then.

Source: emailexpert: Microsoft Overhauls SNDS & JMRP Postmaster Tools, What to Fix

Editor’s Note: Relay is a new feature starting this week in TWIE. Each week, I’ll feature an interview with an email professional - maybe well known, maybe not. I want to bring a diversity of perspectives to the party! (Also, in interest of full disclosure, Paxton and I work together at Klaviyo, but neither of us are speaking on behalf of the company, and our opinions are our own.)

When the inbox no longer reports what it used to report — when Apple MPP fires roughly half of all opens before they happen, Gemini auto-opens for summarization, and bot traffic eats CTR — what data actually tells you a Gmail program is healthy? I sat down with Paxton Nicholas to walk through the measurement stack he leans on now, and what he expects to break first as DMARCbis and DKIM2 land in production.

Q: Between Apple MPP firing roughly half of reported opens and Gemini-powered AI Inbox auto-opening for summaries, opens are essentially dead and clicks are getting noisier. When a brand asks you today, "is our Gmail program healthy?", what data are you actually looking at — and what should ESPs be exposing that they aren't?

A: First and foremost you have to make sure the brand has checked all the boxes. I always start by auditing Domain Authentication status to ensure everything is technically in good standing. From there, I check for reputation bounces across major providers. If you don't rule out these fundamental blocks first, you risk misdiagnosing a technical setup failure as a sender-reputation or engagement issue.

Then I like to look at Human Clicks, and Human Click Rate... "Human", meaning we could not identify it as a bot click. At Klaviyo, we have a pretty good bot click designation by where the click came from (ASN), or alternatively, Time-to-Click to identify bots (if all 10 URLs in the email were clicked within 3 seconds of the email delivery then that's not human). If you don't have some sort of bot-filtering you should look into it, as it is very useful in eliminating the noise of this signal. In today's era this metric "Human Click Rate" is the best we've got as senders to get a read on the actual human eyes hitting our emails.

Next, look for the negative signals like unsubscribes (not just Gmail — look at all the providers). I actually use unsubscribe rate as the last truly human engagement metric. As long as it is not too high, then unsubscribe rate can actually show you how many human eyes are hitting emails, because bots won't unsubscribe. In order to unsubscribe it's probably ending up in your inbox in the first place. In this way it actually serves as a pretty good indicator that you are inboxing, devoid of all the noise caused by bots in the other metrics like opens, and clicks.

But then you need to look for real Negative reactions from recipients. For this I use a metric I call TSR, which is short for True Spam Rate. Spam Rate on its own is often far lower than it should be because of all the inbox providers with no FBL that flood the denominator of the equation. TSR is basically just Spam Rate with Gmail removed from the equation (along with other inbox providers that will never provide us with user spam reports). Gmail's lack of an FBL means that you'll never be able to count those spam reports in the numerator so in order to get an accurate spam rate across the board you have to remove them from the denominator too. Once you do that, only then does Gmail's Bulk Sender Guidelines of 0.1%, and 0.3% apply. From there you just have to follow the guidance — if True Spam Rate is greater than 0.1% then you have a problem, if it's greater than 0.3% then you have a catastrophic problem.

So you may be saying at this point, "Gmail doesn't give spam reports... So far, all you've given is a bunch of signals from other providers, this is supposed to be about Gmail..." and you would be kind of right, but recipients tend to behave relatively the same across inbox providers. Whether their inbox lives in Gmail, Outlook, Yahoo, Apple mail, whatever, recipient behavior is based on Expectation, and Consent. Meaning the folks you are emailing expect to be getting an email from you, because they themselves gave you their email address. If you don't have THAT then eventually you will have problems with Gmail (as well as the other inbox providers).

I can't leave out Google Postmaster Tools. Gmail does give us a signal when things are veering into the danger zone. Use Google Postmaster Tools, specifically the User Reported Spam Rate, and IP Reputation if you are on your own Dedicated IPs to identify the dates when things went haywire. If you haven't already, hook up the Google Postmaster Tools X-Feedback-ID header on outgoing mail with the identifying information that you can use to identify the original campaign so you can find the culprit campaign in GPT when digging into that specific date. As always, trust the User Reported Spam Rate that Google is telling you — this is straight from the horse's mouth. But if you can use TSR in tandem (incorporating all FBLs from all other providers, and removing the dead weight inbox providers that do not contribute any FBLs from the denominator dragging the rate down arbitrarily), this gives you a metric that you have control over aggregating by whatever other data points you may want to slice and dice by, and using this instead of depending on the rigid GPT number may give you more flexibility to pinpoint exactly what you need to work on.

Q: What should a sender with a complicated subdomain tree be doing in Q3 2026 to be ready for these technical shifts, and where do you expect the first wave of breakage to hit?

A: DMARCbis and the DNS Tree Walk. Senders with complex subdomain trees historically had a massive vulnerability: if you secured marketing.brand.com and transactional.brand.com, a phisher could still spin up spoof.iam.brand.com. The new "np" tag shuts the door on this. Under DMARCbis, the np=reject tag allows you to explicitly tell mailbox providers: "If you get a mail from a subdomain of mine that does not explicitly exist in DNS, reject it immediately." This completely shuts down wildcard/non-existent subdomain spoofing. DMARCbis also replaces the Public Suffix List (PSL) lookup with a standard DNS "Tree Walk" to determine organizational domain alignment. Senders in 2026 need to officially map their DNS, and prepare to deploy np=reject at the root organizational level to freeze out unauthorized subdomains.

DKIM2 will protect us against DKIM Replay attacks. Because DKIM2 handles transit modifications natively, Authenticated Received Chain (ARC) is being deprecated and moved to historic status. These are the technical things to implement that will be coming soon if they have not hit the scene already.

If experience tells me anything, the first wave of breakage likely won't hit the massive sender domains who have dedicated IT teams responsible for managing/administering their DNS. It will hit the smaller players, with legacy third-party tools still kicking around or complex B2B forwarding setups. Sub-domain trees with uncharted sending platforms because they haven't been properly mapped out by network administrators will be the first failures we see.

Changing subdomains does not and will not ever offer a "clean slate" for deliverability. Major mailbox providers utilize sophisticated, layered domain reputation models where individual subdomain reputations roll up into, and are heavily influenced by, the root organizational domain's footprint. Subdomains should never be used as temporary camouflage to escape poor performance; rather, they should be treated as legitimate structural dividers designed to signal distinct organizational segments, such as separating transactional and marketing mailflows.

If you are trying to bypass filtering by changing sub-domains, please stop. It's a fool's errand. Not only that, doing too much of this — like rapidly rotating sub-domains — is a classic malicious signal. Mailbox providers, and Gmail in particular, are incredibly adept at footprinting senders by analyzing recipient list overlap. Because sender reputation is fundamentally anchored to the historical engagement of the underlying list, migrating a fatigued or unengaged audience to a pristine subdomain or secondary domain will result in the exact same reputation of the originating sub-domain after only a couple of sends. Senders must focus on establishing long-term domain health across their existing tree rather than trying to out-maneuver the inbox networks. Use sub-domains for organization, not to try to bypass anti-spam systems.

Q: Where is the next big deliverability challenge going to come from?

A: AI is going to completely change how businesses communicate with their subscribers. I think the inbox UI will be vastly different in the next 5 years. Instead of a list of emails I wouldn't be surprised to see a chat prompt and typical chatbot UI taking over the majority of the real estate in the inbox. Instead of opening your email and reading the emails you received, the UX will depend on your recipient persona:

All of it will be fueled by prompts. AI will make the connections necessary to come up with these personas based on users explaining what their goals are when they go through their inbox. The result of all of this for senders will be far less engagement through traditional methods (within the inbox) like opens and click tracking. Which means that now it's far more important for ESPs to get better at associating engagement patterns much further down the line than the email itself. Being able to associate the purchase back to the email that caused it will be even more imperative in the future because there won't be any signals in between. Or perhaps associating site views that originated from emails sent — things of that nature will be far more important because they will be the only windows for us to validate our campaigns off of.

Q: What does the deliverability governance model look like for autonomous agents, and what guardrails should senders demand before turning that autonomy on?

A: When you hand the keys of execution over to autonomous agents, deliverability governance can no longer be a reactive, post-send cleanup exercise. It has to be built directly into the agent's context as a hard-coded thing. "Check with me before sending out any campaigns ever." Having a human in the loop before firing off campaigns is essential to initial success.

Regarding autonomous agents, specifically when sending emails, I firmly believe that if you are about to send a marketing campaign to 100+ people, you should ensure a human reviews it before sending. Truly "autonomous" agents would mean sending without that human in the loop. There's very little downside in having a human review something before it goes out. As content becomes easier and easier to create, it's imperative that we "humans" shift our efforts towards quality control over the agents' work. Otherwise, the readers end up with a whole bunch of AI-generated slop that we are all becoming so adverse to these days.

Deliverability governance might also be improved by gating the segments you are allowed to send to. Subscription management — honoring unsubscribes, and prior spam reports — is only half of it. AI could help marketers carve out the segments of their subscribers that align with the specific content that's been written. Agents will be able to consume and organize contacts into segments based on the actions those people have taken in the past. Any metadata associated with those contacts to indicate what those folks are interested in can be scaled by an AI agent. At the end of the day, engagement is the product of content that aligns with the audience's interest. Any way we can agentically align the Content piece with the Audience will be a win.

Following up on the DKIM2 coverage in W21, two DKIM2-related drafts have IETF working-group adoption calls closing the day before this issue ships. draft-herr-dkim2-bcp-01 (recommended usage of DKIM2 for senders, intermediaries, and receivers, authored by Todd Herr of GreenArrow) and draft-chuang-dkim2-dns-04 (DNS record format and discovery) were issued May 22 with a two-week call period ending June 5. Adoption moves both into the WG's official document set alongside draft-ietf-dkim-dkim2-spec-01.

The replay-prevention case keeps gathering working-group support: DKIM2 signs the SMTP envelope — MAIL FROM and RCPT TO — which kills the current DKIM-replay attack class outright. Major mailbox providers are reportedly planning experimental verification in Q4 2026. Read alongside this week's lead story on ARC retirement, the working group's direction is unambiguous.

Sources: Call for adoption: draft-herr-dkim2-bcp-01, Call for adoption: draft-chuang-dkim2-dns-04

1&1 Mail & Media — operator of GMX, WEB.DE, and mail.com under the German consumer-email umbrella — announced on the Mailop list that it has begun honoring published DMARC p=reject policies during the SMTP transaction. Failed messages now get rejected with 554 Transaction failed Reject due to domain's DMARC policy. The rollout is phased over the coming weeks, which means it's actively reaching senders right now. Aggregate reports have been flowing for an extended period; SMTP-time enforcement is the new piece.

The blast radius isn't the well-run program with a clean DMARC story. It's forwarders, mailing lists, and CRM platforms whose customers set their root domain to p=reject without auditing every third-party sender that touches their traffic. If you maintain a CRM, ESP, or mailing-list platform with European recipients, expect 554 rejections that didn't exist a few weeks ago. They aren't bugs — they're alignment failures your customer never audited for.

Check the alignment before your recipients' postmasters check it for you.

Sources: emailexpert: GMX, WEB.DE and mail.com to Enforce DMARC p=reject Policies, Spam Resource: GMX/WEB.DE/mail.com moving to inbound DMARC enforcement

On May 19, Judge David Estudillo (W.D. Wash.) denied Skechers' motion to dismiss in Liss v. Skechers USA. The complaint alleges Skechers used subject lines like "Today Only!", "Ends Tonight," and "The Clock Is Ticking" to manufacture false urgency around discounts that were then quietly extended. The court held plaintiffs plausibly alleged Washington CEMA violations and rejected Skechers' CAN-SPAM-preemption argument.

This is the first major national-retailer denial of 2026 on the post-Brown v. Old Navy theory, and it's the right one to circulate to your retention and growth teams. The exposure model in Washington is statutory damages with no actual-harm requirement. Any subject line claiming a deadline that's later extended is now a litigation surface. Audit your evergreen "Last Chance" / "Final Hours" / "Today Only" templates before someone else does it for you.

Sources: emailexpert: Skechers Must Face "False Urgency" Email Class Action, National Law Review: No Easy Walkaway — Skechers Must Face Email Marketing Claims

That's the week. If something's wrong, reply and tell me — I read every response. Better yet, hit forward and send this to the practitioner on your team who's about to find out about the SNDS changes the hard way.

Also, I’ll be in Montreal at the M3AAWG conference next week. If you like this newsletter (or even if you don’t), please come up and say hello! (If you don’t know me, I’m the bald guy co-emceeing the open roundtable sessions.) I have some cool DKIM2 laptop stickers for the asking!

— John

This Week In Email — thisweekin.email