APRF: The Draft Standard That Would Finally Show Senders Where Their Mail Lands

For as long as senders have chased the inbox, one question has had no standard answer: once your mail reaches a mailbox provider, where did it actually go, and what did people do with it? Authentication tells you a message was not forged. A bounce tells you it was refused. But the space in between - inbox versus spam folder, opened versus deleted - has only ever been visible through per-provider portals like Google Postmaster Tools and Microsoft SNDS, or estimated from seed-list panels. A new IETF draft wants to close that gap.

What APRF is

Aggregate Performance Reporting (APRF) is an Internet-Draft, draft-brotman-aggregate-performance-reporting-00, submitted on 17 March 2026 by Alex Brotman (Comcast), Tom Corbett (Iterable) and Emil Gustafsson (Google). Its intended status is Standards Track, but today it is an individual draft - “I-D Exists” in IETF terms - that has not yet been adopted by a working group. It proposes a report format plus methods for discovering where to send reports and how to deliver them, so a mailbox provider can hand a sender aggregated data about how its mail performed.

If that shape sounds familiar, it should. APRF deliberately borrows the pattern that DMARC (RFC 7489) made routine: publish a DNS record naming a reporting address, and receive machine-readable reports by email.

How it works

The one design choice that matters most: APRF is keyed to the DKIM signing domain, not the From address. A report generator - the mailbox provider - takes the d= domain and selector off the DKIM-Signature on your mail and looks up a TXT record at:

<selector>._aprf._domainkey.<your-domain>

A minimal record looks like this:

v=APRFv1; rua=mailto:[email protected]

The v=APRFv1 tag is mandatory - the record is ignored without it - and rua= names where reports should go, the same “aggregate reporting address” idea DMARC uses. An optional sdi= tag lets a signer segment reports by a self-defined header (by campaign, brand or region), and a wildcard can apply one record across many selectors.

Reports arrive as JSON, one file per UTC day, emailed as a multipart/report message with the data attached as application/json (gzip is allowed). Each report carries a header block - the reporting source, the DKIM domain and selector, and the UTC start and end of the window - and a body split into segments. Two families of data do the real work:

• Classification - placement counts such as inbox versus unwanted (spam), as bucketed scalar values.
• Engagement - recipient actions bucketed as positive, neutral or negative: opens or a “not spam” click at one end, complaints or deletion at the other.

The draft leans on RFC 6376 for DKIM and RFC 8259 for JSON, and it is careful to note that each provider decides what actually goes into each engagement bucket. That flexibility is both a strength and a caveat - the numbers are comparable over time from a single provider, but not guaranteed to mean exactly the same thing across providers.

Aggregated by design, and voluntary

Because this is real recipient behaviour, APRF is aggregated on purpose. The draft warns that at low volume a report could reveal something about individuals, and recommends that providers set a minimum message or recipient threshold before reporting - so you receive ranges bucketed to hide the noise, not precise per-person figures.

There is a practical consequence worth internalising early: the numbers are bucketed, not exact. In Comcast’s live beta every value is a multiple of 100, and the draft leaves the bucket sizes entirely to the provider. An inbox: 700 does not mean 700 messages reached the inbox - it means the true count fell inside a bucket that tops out around there. Read these as directional bands over time, not as counts to divide into precise inbox-placement percentages.

Providers are also free to decline: sending reports at all is voluntary, and a generator can refuse a destination it does not trust. There is even a validation record for the case where your reporting address lives on a different domain than the one being signed.

How it differs from what you have today

Plenty of signals already hint at placement, but each has a gap APRF is trying to close: the data is either about authentication rather than performance, locked to one provider’s own portal, or estimated rather than observed.

The row that matters most is the last one. Seed-list tools estimate placement from a panel of test addresses and never see what real recipients did with the mail. APRF reports real, aggregated behaviour from inside the provider, and does it in one interoperable format any provider can emit, instead of a separate login per mailbox provider.

Where it stands

Temper the excitement with the timeline. As of mid-2026, Comcast is the only mailbox provider sending beta reports - its author has working code for comcast.net recipients, without segmentation yet. Gmail, Microsoft, Yahoo and Apple have announced nothing. The draft still carries open TODOs and an incomplete grammar, and it expires on 18 September 2026 unless it is revised or adopted. The detail everyone will read twice is the Google engineer among the authors: not a commitment, but a signal worth noting.

How to try it today

Because only Comcast is live, adopting APRF now means validating your pipeline on Comcast traffic rather than measuring your whole programme. The setup is cheap, though, and it mirrors the DMARC discipline you already have.

1. Inventory your signing domains. APRF is filed under the DKIM d= domain your mail signs with, and there is no subdomain fallback - so a record has to sit on each exact signing domain. If all your mail signs with one domain, that is the single domain you publish on. But many senders sign under several d= domains (your own domain plus ESP subdomains like em1234.yourdomain.com), and each needs its own record. Your DMARC aggregate reports list every d= domain sending as you - our free DMARC Monitor surfaces them in plain English.
2. Publish one record per signing domain. Add a TXT record at <selector>._aprf._domainkey.<signing-domain> reading v=APRFv1; rua=mailto:[email protected]. A wildcard *._aprf._domainkey.<signing-domain> covers every selector in one record. Our free APRF Record Generator builds this record - and the off-domain consent record in the next step - for you.
3. Authorise an off-domain mailbox. If your reporting address lives on a different domain than the one being signed, publish a consent record at <selector>.<signing-domain>._aprf.<mailbox-domain> with the value v=APRFv1 (a wildcard is allowed), so a provider can confirm the destination agreed to receive reports.
4. Prepare a collection inbox. Accept multipart/report messages carrying .json (or .json.gz) attachments, and match the report subject line - the draft defines it with an ARPF: prefix (the letters are transposed from APRF), so filter on the literal ARPF: the spec specifies and stay lenient in case a provider sends APRF:. Then be ready to un-gzip and parse the JSON, remembering the values are buckets, not exact counts.

That is the whole setup. Once the record is published, confirm it is valid with our free APRF Record Checker. From there it is a waiting game: the more providers that join Comcast, the more of your mail these reports will actually cover.

The honest expectation

A DMARC pass never meant the inbox, and APRF will not guarantee it either. What it promises is simply the thing senders have wanted for a very long time: a standard way to see where the mail actually went. Watch the draft as it heads toward a working group, keep your DKIM signing and reporting mailboxes clean, and treat anything you collect today as a dress rehearsal.