This Week in Email: July 8, 2026

Apple's flagship privacy feature has a hole it's known about for a year. DKIM2 and DMARCbis just got their first running code. The operators behind the biggest phishing platform ever taken down are back with a technique email authentication can't see. And a California courtroom may be about to decide whether inbox AI is a wiretap. It's a packed one. Let's get into it.

Here's the number that should get your attention: 100%. That's the success rate volunteers hit when testing a vulnerability that resolves a Hide My Email alias back to the user's real address. 404 Media reported it July 1; EasyOptOuts' Tyler Murphy found it in June 2025. Apple claimed a fix in March 2026 — it wasn't fixed — asked for disclosure delays, then missed its own "coming weeks" deadline. Details are being withheld because the flaw is still exploitable today.

Same week, and not coincidentally, Apple announced it's consolidating masked-address generation: new Hide My Email addresses (previously icloud.com) and Sign in with Apple addresses (previously privaterelay.appleid.com) will come from private.icloud.com "later this summer." Existing addresses stay where they are. Al Iverson's guidance holds: these are long-lived aliases, not disposables — treat them like real inbox addresses, and resist the temptation the shared domain creates to block masked signups.

For senders, the line is bright: if anyone pitches you "alias resolution" for address enrichment, that's a compliance and reputational problem, full stop. For the industry, it's worse — roughly half of opens already sit behind Apple's privacy layer, and the promise underneath that layer just failed adversarial testing. A privacy feature that's been unmaskable for a year isn't a privacy feature. It's a brand.

Sources: 404 Media, emailexpert, TechCrunch, Spam Resource

Following up on our recent DKIM2 draft-03 and DMARCbis coverage: the paper standards just became software. Stalwart v0.16.12, released July 6, is the first mail server to implement both — DKIM2's chain-of-custody signing (survives forwarding, stops replay, produces provable bounces) and DMARCbis's DNS tree walk replacing the Public Suffix List. There's a public mail-auth playground for testing against it.

The timing matters as much as the code. This lands 12 days before the DKIM session at IETF 126, and running code has a way of steering spec conversations — spec-04 will now be argued against a live implementation, not a whiteboard. It also gives everyone else an interop target ahead of the Q4 2026 mailbox-provider experimental rollout. Standards don't get real when the RFC publishes. They get real when something ships.

Source: Stalwart blog

When Microsoft and Europol seized Tycoon 2FA's infrastructure on March 4, the platform accounted for roughly 90% of phishing-as-a-service activity. By late April, its operators were back — and their new technique is nastier than the old one. Device-code phishing abuses OAuth 2.0's Device Authorization Grant (RFC 8628): the victim enters an attacker-generated code on Microsoft's genuine login page, completes MFA themselves, and hands the attacker a token.

Here's the part you need to sit with: the lure emails arrive cleanly SPF/DKIM-authenticated from unrelated third-party domains, then get laundered through Cisco, Trend Micro, and Mimecast URL-rewriters. Nothing spoofed. Nothing for DMARC to catch. And the technique is now propagating across competing kits — EvilTokens, ODx/FlowerStorm.

If you defend a Microsoft tenant: block the device-code flow via Conditional Access, restrict app consent, and deploy Continuous Access Evaluation. Authentication was table stakes. It was never a moat — and this is what the other side of the moat looks like.

Source: emailexpert

Three California class actions are testing whether AI reading your email is legally interception, and the one to watch is Thele v. Google (N.D. Cal., filed November 2025). The claim: Google flipped Gemini "smart features" to default-on in Gmail on October 10, 2025 without consent — a potential class of roughly 130 million US Gmail users, with claims under CIPA §§631/632, the federal Wiretap Act, and the SCA. A motion-to-dismiss ruling was pending as of late June.

The stakes go well past Google. If courts accept that default-on AI processing of message content is unlawful interception, the reasoning reaches every inbox-AI feature — summarization, smart reply, and any vendor tooling that reads message bodies. Companion cases Noel v. Perplexity and In re Otter.AI (procedurally furthest along; MTD argued May 20) will show which way the wind is blowing first. If your product touches message content with AI and your consent story is a buried settings toggle, this is the litigation that decides whether that was ever enough.

Source: emailexpert

Google almost never publishes operational recovery mechanics. This week it did: a "Top 10 Gmail sender issues" guide that includes an actual deferral-recovery protocol — pause sending for 15 minutes, send a test, resume below the deferral threshold, then ramp 25–100% daily. It also warns new domains off "bursty" sending patterns.

The guide names names on deceptive tactics, too: fake "Re:"/"Fwd:" subject prefixes and verification-implying emoji — the exact patterns feeding the subject-line litigation wave. This is the closest thing to a first-party Gmail runbook senders have ever gotten. Put the deferral protocol in your incident docs now, before you need it at 2 AM.

Sources: Spam Resource, Google

Following up on our DMARCbis RFC coverage: Halon shipped it in a commercial MTA three weeks after publication. Engage 26.2 and Protect 26.2, released June 29, add native RFC 9989 evaluation, post-quantum hybrid key exchange on STARTTLS — a first in the outbound MTA space — plus Arm64 builds (cheaper Arm servers, native dev on Apple Silicon), Ubuntu 26.04/RHEL 10 support, and a migration-oriented config structure aimed at teams leaving legacy MTAs.

Put this next to Stalwart and the through-line is clear: the receiver and MTA side is adopting DMARCbis faster than most senders realize. The tree-walk behavior change isn't a 2027 problem — it's arriving in production software now. Check how your org relationships resolve under a tree walk before someone else's MTA checks for you.

Sources: Halon, emailexpert

Following up on last week's preview: IETF 126 runs July 18–24 in Vienna, and the DKIM working group session lands Tuesday, July 21, 14:00–16:00 CEST (Park Suite 6), with Brotman, Gondwana, Clayton, Herr, and Chuang expected. With spec-03 and BCP-00 fresh — and Stalwart's implementation now live — this session sets spec-04 direction and tests whether the Q4 2026 experimental-rollout target holds. If you care where email authentication goes next, this is the room where it happens.

Sources: IETF 126, Agenda

Also on the calendar:

That's the week. If something is wrong, reply and tell me — I read every response. Better yet, hit "forward" and send it to someone who'd rather read one email than forty tabs.

— John

This Week In Email — thisweekin.email