DMARC Told You Who Sent It. This Draft Wants to Tell You What Happened.

On 9 October 2026, the IETF's Mail Maintenance working group adopted an internet-draft describing an aggregate performance report for email: a document format, a means of discovering where reports should be sent, and a specified delivery method. The title is dry and the consequence is not. DMARC gave senders a picture of who was sending as their domain. This is an attempt to give them a picture of what happened to the mail afterwards.

The problem it addresses is stated plainly in the draft's own introduction. Mailbox providers use reputation systems to govern placement, permitted volume and other delivery characteristics; the entities whose behaviour feeds those systems have little insight into them; and that lack of usable information is what limits their ability to take corrective action.

Which is the whole content of most deliverability arguments. A decision is made about your mail and you are not told what it was based on. The draft is an argument that the party making the decision should be the party sending you the aggregate.

What the draft actually proposes

• A report format — a header, a body, a reporting time period, and sections covering classification and engagement.
• Destination discovery through DNS. The sender publishes where reports should go — the same shape of solution as the rua destination senders already publish for DMARC aggregate reports — and the mailbox provider does the sending, unasked.
• Domain-based, DKIM-keyed metrics. The unit is the signing domain, which the draft calls a signer-defined identifier, not the campaign and not the recipient.
• A defined delivery method, with compression, destination validation, and a security section that separates personal data from report data.

The scope discipline is the most encouraging part. Nobody is being handed another real-time dashboard. The report is aggregate and domain-scoped, which is the only shape of data a mailbox provider can share without exposing subscriber-level information — and, not coincidentally, the only shape a sender can act on without arguing about whose model is right.

Why this is the missing half of the authentication story

Authentication reporting worked because it was automatic and because the information was binary. You publish a destination, receivers send aggregates whether or not they like you, and a sender sees a stream they did not know existed — a forgotten subdomain, a marketing tool mailing on a cousin's behalf, a domain nobody has owned since the last migration. DMARC's policy mattered less than its reporting. The reports are what made the policy debuggable.

Performance reporting has the same logic and a harder problem underneath it. Authentication has a right answer per message: it passed or it did not. Performance does not. Which metrics, whose definition of delivered, what counts as engaged, how a complaint from a subscriber who clicked "spam" is distinguished from one who clicked "unsubscribe" — all of that has to be agreed before a table of numbers is worth reading.

That is why the draft is worth an hour of attention rather than a headline. Get the format right and the weekly argument about a drop gets an answer from the party making the placement decision. Get it wrong and the industry receives a scoreboard nobody can act on — which is precisely the failure Google described when it retired its reputation dashboards.

The honest caveats

• It is a draft. Internet-Drafts expire after six months; this one is dated October 2026 and carries an April 2027 expiry. It can change, be replaced, or quietly disappear.
• Adoption is a receiver's decision. A format only helps once the mailbox providers that compute reputation emit it, and no one is obliged to.
• It cannot replace first-party measurement. An aggregate report is a second opinion from the party that decides placement. Useful precisely because it is not your own data — and useless if you have nothing to compare it with.

What to do in the meantime

Nothing here is implemented anywhere yet, and the work it implies is worth doing anyway, because every metric the draft names is one you can approximate today from your own sending data: complaint rate and bounce classes by stream, engagement by cohort age, authentication alignment per sending domain.

Two habits make a program ready rather than merely interested. Keep an inventory of every DKIM signing domain that sends as you — including the third-party tools that sign on behalf of a domain they do not own, because that inventory is exactly the unit this report would be keyed to. And keep your DMARC aggregate reports working. A team that cannot read the authentication reports it already receives will not read the performance ones either.