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.
New to APRF? Start with our plain-English explainer - What is APRF? Aggregate Performance Reporting, explained simply - then come back here for the draft’s technical detail and current status.
Update, October 2026. The IETF MAILMAINT working group adopted APRF on 8 October 2026 and republished it as draft-ietf-mailmaint-aprf-00 on 9 October, replacing the individual draft this page originally covered. The protocol barely changed, and this page has been revised to match the working-group draft - the adoption itself, and the small technical deltas, are covered in our adoption note.
What APRF is
Aggregate Performance Reporting (APRF) is an IETF Internet-Draft, now draft-ietf-mailmaint-aprf-00. It began life on 17 March 2026 as the individual draft draft-brotman-aggregate-performance-reporting, written by Alex Brotman (Comcast), Tom Corbett (Iterable) and Emil Gustafsson; a September 2026 revision added a fourth author, Julient Duplant (Google). The MAILMAINT working group adopted it on 8 October 2026 and republished it under the new name on 9 October - so it is no longer one company’s individual submission but a Standards Track proposal under formal working-group review, with the old draft marked “replaced” on the datatracker. 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 (now RFC 9989) 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).
To cover every selector with one record you now have two options. A wildcard record at *._aprf._domainkey.<your-domain> has been there from the start; the working-group draft adds a selector-less form published at plain _aprf._domainkey.<your-domain>. And it defines an explicit order of discovery for when more than one exists: the most specific match wins - an exact-selector record beats the wildcard, and the wildcard beats the selector-less record.
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
inboxversusunwanted(spam), as bucketed scalar values. - Engagement - recipient actions bucketed as
positive,neutralornegative: 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. The draft leaves the bucket sizes entirely to the provider - the one public Comcast sample shows round-hundred values. 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.
| Signal | What it tells you | Keyed on | Format | Delivery |
|---|---|---|---|---|
| APRF (draft) | Placement + engagement | DKIM d= domain |
JSON | Emailed daily |
| DMARC aggregate | Authentication + alignment | From domain | XML | Emailed |
| Google Postmaster | Spam rate, reputation, auth (Gmail only) | Domain | Dashboard | Portal |
| Microsoft SNDS | Spam rate, complaints (Outlook only) | Sending IP | Dashboard | Portal |
| Seed-list tools | Estimated inbox placement | Seed accounts | Dashboard / API | Portal |
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, but note that the timeline is moving. On 8 October 2026 the MAILMAINT working group adopted the draft (republishing it the next day) - the strongest signal yet that APRF is headed for proper Standards Track review rather than quiet expiry - and the working-group document now runs to 12 April 2027. It is still a draft, not an RFC: the DNS record grammar is marked TODO, and the draft’s own FAQ lists open questions, such as whether sdi= segmentation can split promotional from transactional mail, and how ESPs should handle reporting addresses. As of October 2026, Comcast remains 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 detail everyone will read twice is still 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.
- 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 severald=domains (your own domain plus ESP subdomains likeem1234.yourdomain.com), and each needs its own record. Your DMARC aggregate reports list everyd=domain sending as you - our free DMARC Monitor surfaces them in plain English. - Publish one record per signing domain. Add a TXT record at
<selector>._aprf._domainkey.<signing-domain>readingv=APRFv1; rua=mailto:[email protected]. A wildcard*._aprf._domainkey.<signing-domain>covers every selector in one record; the working-group draft also allows a selector-less record at plain_aprf._domainkey.<signing-domain>, but until provider support for that newer form is proven, the wildcard remains the safe all-selectors choice. Our free APRF Record Generator builds this record - and the off-domain consent record in the next step - for you. - 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 valuev=APRFv1(a wildcard is allowed), so a provider can confirm the destination agreed to receive reports. - Prepare a collection inbox. Accept
multipart/reportmessages carrying.json(or.json.gz) attachments, and match the report subject line - the working-group draft defines it with anAPRF:prefix. The original draft carried the letters transposed asARPF:(since corrected), so filter onAPRF:and stay lenient by also acceptingARPF:from older implementations. 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. The draft has now found its working-group home at MAILMAINT - watch it mature there, keep your DKIM signing and reporting mailboxes clean, and treat anything you collect today as a dress rehearsal.