This Week in Email: July 1, 2026

Meanwhile France's CNIL tracking-pixel deadline is two weeks out, the IETF DKIM working group dropped its second material document in six days, and an agentic-AI acquisition is starting to reshape what a customer engagement platform looks like underneath. Heavy week. Let's get into it.

Category: Security & Anti-Abuse

On June 26, customers of Blesta — the billing platform widely deployed by hosting providers — received a "Blesta Compromised" ransom email from [email protected]. The message threatened to leak the customer database the next day. The attackers had compromised a temp support account originally created for a third-party virtualization vendor, then used it to drive Blesta's own customer portal. The ransom mail went out through Blesta's real outbound infrastructure on Mailgun.

SPF passed. DKIM passed. DMARC passed against Blesta's own p=reject policy. Every authentication signal a receiver could check confirmed the message was routed through the legitimate sender's infrastructure — because it was. DMARC confirms the route the mail took. It was never designed to confirm the intent of the message moving along that route.

This is the cleanest example of "authenticated abuse" we've seen in months, and it pairs with the Xero, Atlassian Jira, and AWS SES patterns we covered earlier this year. The through-line is consistent: in 2026, with spoofing largely closed off by DMARC enforcement at the major receivers, the dominant residual phishing pattern is attackers operating mail from inside a legitimate sender's authenticated infrastructure. If your detection stack still treats SPF/DKIM/DMARC pass as a strong safety signal, this is the case study to take to your security team this week. The signal it carries is "the route is real." Nothing more.

Sources: Suped, DMARC Report, LowEndBox

Category: Regulatory & Compliance

France's CNIL published its email tracking-pixel recommendation on April 14, with a 90-day transitional window. That window closes July 14 — two weeks from today. The clock is real.

The compliance shape: any pixel collecting marketing-measurement data (open, time-on-message, render context) is now treated like a tracker under the ePrivacy Directive. For contacts collected before April 14, senders have until July 14 to send a notification email explaining pixel use and offering an opt-out. Miss the window and the transitional regime evaporates — re-collecting explicit pixel consent across the entire pre-April-14 contact base becomes the only legal path forward. Italy's Garante is on the same arc, with the six-month Italian window ending October 28. Lewis Silkin's comparative analysis published June 23 lays the two regimes side by side.

The carve-out worth knowing: pixels used purely for deliverability hygiene — suppressing chronic inactives, throttling cadence to disengaged segments — are not treated as marketing-measurement and don't require consent. Anything used to feed engagement scoring, journey orchestration, or campaign analytics does. Most ESP integrations don't separate the two cleanly at the pixel level. That engineering work is the part senders keep underestimating.

CNIL enforcement — formal notices, investigations, sanctions — is expected to begin immediately after July 14. If your EU contact base predates April 14 and you haven't sent the notification email yet, this is what you should be doing this week. Not next week.

Sources: Spam Resource, Lewis Silkin, Inside Privacy (Covington), iubenda — Garante guidance

Category: Security & Anti-Abuse

Kaspersky's Securelist research, picked up by emailexpert this week, documents a sharp rise in phishing campaigns sent through Amazon SES — not by exploiting any flaw in SES itself, but by harvesting AWS IAM access keys leaked in GitHub repos, .env files, Docker image layers, public S3 buckets, and similar developer mistakes.

The mechanics are mundane and that's the problem. Attackers scan with TruffleHog and equivalent tools, check each leaked key for SES sending permissions, and inherit the legitimate AWS customer's full reputation the moment they find one. No domain registration. No warmup. No infrastructure to build. SPF, DKIM, and DMARC all pass because the mail is genuinely originating from the victim's authenticated sending domain. The dominant campaigns are fake DocuSign-style document-signing notifications and BEC plays — fabricated email threads and forged invoices aimed at finance teams.

The architecture lesson generalizes well beyond SES. Sender reputation in 2026 is inherited by whoever holds the credentials, not by whoever earned them. That applies to every shared ESP — API key in a leaked repo, OAuth refresh token in a stale backup, service-account credential baked into a Docker image — and to every SaaS-mail integration that ships a long-lived secret. Rotate, scope, and monitor. If your SES setup still uses long-lived IAM users instead of role-assumption with short tokens, that is the week-one fix.

Sources: Kaspersky Securelist, emailexpert, TechRadar

The IETF DKIM working group landed two material documents in six days. On June 18 the WG published the first DKIM2 Best Current Practices draft (draft-ietf-dkim-dkim2-bcp-00). On June 24 the main spec advanced to draft-ietf-dkim-dkim2-spec-03. Two thirds of a year before the Q4 2026 mailbox-provider experimental-rollout target, the working group's tempo is picking up — not slipping.

The headline changes in spec-03. A new nd= tag has been introduced as an alternative mechanism to the existing mf= and rt= tags for handling imaginary hops between domains — the construct that always made forwarding scenarios under DKIM2 their own engineering problem. A new feedhere flag has been added to support privacy-conscious forwarding scenarios. The list of header fields ignored during signing has been promoted into its own dedicated section, with the experimental Delivered-To: header added to it. The rules for DSN propagation have been tightened so a DSN always carries the message headers up to the point where the DSN creator saw the message on its outward journey. Null recipes for header field modifications have been eliminated.

None of that is procedural cleanup. The forwarding-edge cases that always blow up real DKIM deployments — your delegated-domain replays, your Listserv hops, your security-vendor inline rewrites — are exactly the surface area this revision touches.

IETF 126 in Vienna kicks off July 18. The DKIM session Tuesday July 21 is where spec-04 direction gets set and the Q4 experimental-rollout target either holds or starts slipping. Watch that session.

Sources: IETF Datatracker — DKIM2 spec, Suped — DKIM2 BCP background

That’s it for this week! If you have feedback to make this newsletter more useful, just hit reply!

This Week In Email — thisweekin.email