APRF: Aggregate Performance Reporting, Explained

APRF (Aggregate Performance Reporting) is a proposed standard that has a mailbox provider tell you where your mail actually landed. Not whether it was accepted. Where it went after acceptance and what the recipient did with it. You publish a DNS record and a participating provider sends you a daily JSON report splitting your mail into inbox versus unwanted, alongside whether engagement ran positive or negative.

That is a genuinely new thing. Senders have spent twenty years inferring placement from proxies. This replaces the inference with the provider's own answer.

It is also, for anyone running B2B cold email today, almost entirely useless. Both of those things are true at once and the gap between them is worth understanding properly before you spend an afternoon on it.

What APRF actually is

The specification is draft-brotman-aggregate-performance-reporting-00, submitted on 17 March 2026. The authors are Alex Brotman of Comcast, Tom Corbett of Iterable and Emil Gustafsson of Google. It is on the standards track and the draft carries an expiry of 18 September 2026, which is normal for an IETF draft at this stage and tells you how early this is.

The mechanism will look familiar if you have ever set up DMARC reporting. A sender publishes a TXT record declaring where reports should go. A mailbox provider that supports the standard aggregates a day of your mail and sends a JSON report to that address. Nothing is per-recipient. Nothing arrives in real time.

What differs is the subject. DMARC aggregate reports answer a question about identity: did this mail authenticate and who else is sending as you. APRF answers the question every sender has actually wanted answered, which is whether the mail got seen.

What a report contains

Two buckets. The second is the more interesting.

Worth being precise about the classification list, because most write-ups are not. The draft does not mandate a fixed set of values. It describes them as scalar values that are "recommended to be created as buckets" and leaves the precise definitions to whoever generates the report. So a provider could reasonably emit categories nobody has seen yet and two providers could define promotional slightly differently. That looseness is a real limitation for anyone planning to build on it.

Engagement is defined more concretely. Positive covers opens, clicks and explicit "not spam" votes. Neutral covers filing into a folder or forwarding. Negative covers spam marking, deletion and unsubscribes.

Read that list again, because it contains something the industry has been asking for since Apple broke open tracking. A provider-reported positive engagement signal is not defeated by a privacy proxy prefetching your tracking pixel. It comes from the provider, who knows what the human did.

The DNS record and the unusual place it lives

This is the detail most coverage skips and it matters if you are actually setting it up.

The record does not sit at the domain apex the way DMARC does. It sits inside the DKIM tree:

<selector>._aprf._domainkey.<domain>

So for a selector named sel1 on example.org, the record is at sel1._aprf._domainkey.example.org. A wildcard at *._aprf._domainkey applies to every selector unless a more specific record overrides it.

The value looks like this:

v=APRFv1;rua=mailto:reports@example.org;sdi=MsgInfo,^

v=APRFv1 is mandatory. Omit it and the record is invalid. rua holds one or more mailto addresses separated by commas. sdi is optional and covered below.

The reason for the location is that APRF is keyed on DKIM identity. Reports carry a dkim_domain field holding your d= value and a dkim_selector field holding your s=. SPF does not appear in the draft at all. Practically, that means your DKIM setup has to be correct and stable before APRF can return anything meaningful. Rotating selectors carelessly will fragment your reporting.

Each report covers exactly one UTC day, midnight to 23:59:59.

Signer-Defined Identifiers are the actually clever part

SDI is the feature that would make APRF genuinely powerful rather than merely interesting.

You nominate a custom email header and a separator character. The provider reads that header off your messages and splits your report by its values, up to a maximum of four fields. In the report they arrive as a segment array.

The mental model is UTM parameters, applied to deliverability instead of web analytics. Instead of one number describing everything your domain sent, you could break placement down by client, campaign, sequence step and list source at the same time. A report that says 71% inbox tells you nothing you can act on. A report that says one client's second-touch emails to a particular list source are landing at 40% while everything else sits at 85% tells you exactly what to go and fix.

The report also carries an sdi_used field echoing the exact DNS string. It reads N/A if you did not configure one and N/F if the header was declared but never found. That last value is a nice touch, because it distinguishes "not configured" from "configured and broken", which is a distinction most DNS-based standards fail to make.

Why none of this helps cold email yet

Here is the part the enthusiastic coverage keeps soft.

Comcast is the only provider sending reports. Comcast is a consumer ISP. B2B cold email goes to work addresses, which means Google Workspace and Microsoft 365 with a long tail of self-hosted and regional providers. The share of a typical B2B prospect list sitting on a Comcast or Xfinity address rounds to nothing.

You can publish the record today. It costs one DNS entry and about five minutes. What comes back will be either empty or so thin it cannot support a conclusion.

There is a second constraint stacked on top. The draft has no mandatory minimum volume. It does explicitly suggest providers "set a threshold for a number of messages or distinct recipients in order to better obfuscate that information." That is a privacy floor and it is the same shape as the floor that already makes Google Postmaster Tools useless for most cold email domains. Cold email deliberately spreads modest volume across many domains and mailboxes. That is exactly the sending pattern aggregate reporting is worst at describing. If APRF ships at Gmail with a per-domain threshold anything like Postmaster's, a large share of cold email domains will sit below it and receive nothing.

So the honest summary for a B2B sender in August 2026: this is a B2C story that might become your story later.

The one condition that changes the answer

Gmail or Outlook emitting APRF reports. That is the whole trigger.

And the odds are better than the "one ISP supports it" framing suggests, because Google did not merely comment on this draft. A Google engineer co-authored it. That is a considerably stronger signal than a vendor announcement and it is the single fact most of the commentary has left out.

It is still not a commitment. Plenty of co-authored drafts expire quietly. But if you are deciding whether to keep half an eye on this or ignore it entirely, keep the eye on it and set your trigger on a Gmail or Microsoft announcement rather than on general industry noise.

If that day comes, two things follow for anyone running cold email at scale. Placement stops being a guess. And SDI segmentation suddenly makes per-client, per-campaign placement reporting possible from provider data rather than from seed lists, which is a materially better foundation than anything available now.

What it says that we needed this at all

Step back from the spec for a second, because the reason APRF exists is the more useful observation.

Every signal senders historically used to judge deliverability has degraded. Open rates stopped meaning anything usable when Apple's Mail Privacy Protection began prefetching images, which is why turning open tracking off is now a defensible choice rather than heresy. Google retired domain reputation from Postmaster Tools and said plainly that reputation data was not easily actionable. Seed lists tell you where a seed landed, not where your actual recipients' mail landed.

What senders have been left with is inference. Bounce rates, reply rates, sudden silence from a mailbox that was performing, a domain appearing on a blocklist. Each is a proxy and every proxy has been getting noisier.

A standards-track proposal to have providers just tell you the answer is the industry conceding that the proxies stopped working. That concession is worth more than the spec itself right now, because it validates how you should be operating in the meantime: watch the leading indicators across every domain and mailbox continuously, rather than reading a single number after the fact. Continuous monitoring across a whole fleet is the job ColdOps does for agencies running many client workspaces and it stays the job whether or not APRF ever reaches Gmail.

What to do now

Ranked by whether it is worth your time this week.

1. If you send B2C volume to US consumer inboxes, set it up. Publish the record, point rua at a mailbox you actually read and configure an sdi header before you have any data rather than after. A historical baseline is worth more than a perfect schema and Comcast reports are real today.
2. If you run B2B cold email, do not build anything. Publishing the record is harmless and will return roughly nothing. Skip it if you like tidy DNS.
3. Set a trigger, not a project. The event to watch is a Gmail or Microsoft announcement. Nothing before that changes what you should do.
4. Fix your DKIM either way. APRF is keyed entirely on the d= domain and s= selector. Inconsistent or rotating selectors will fragment your reporting whenever it does arrive. Inconsistent DKIM is already costing you deliverability today for unrelated reasons.
5. Design your SDI header now if you run multi-client sending. Four fields is the ceiling. Client, campaign, step and list source is a sensible allocation and deciding it early costs nothing.

The realistic read is that APRF is the most promising deliverability development in years and it will do nothing for B2B cold email for a while. Both halves matter. Anyone selling you APRF-based cold email insight in 2026 is selling you Comcast data about a list that is not on Comcast.