APRF Adopted by the IETF MAILMAINT Working Group: What Changed in the New Draft

APRF has cleared its first real standards hurdle. The IETF’s MAILMAINT working group issued its call for adoption on 24 September 2026, recorded the adoption decision on 8 October, and republished the document as draft-ietf-mailmaint-aprf-00 on 9 October. The individual submission it grew from, draft-brotman-aggregate-performance-reporting, is now marked “replaced” on the datatracker. For a proposal whose whole promise is a standard way for mailbox providers to tell senders where their mail landed, moving from one company’s draft to a document under formal working-group review is the strongest signal yet that APRF is on a path toward RFC rather than quiet expiry.

The practical headline for anyone who already published a record: nothing breaks. The tags, the JSON report format and the delivery mechanics are unchanged. Here is what did move.

From individual draft to working-group draft

A September 2026 revision of the individual draft had already added a fourth author, Julient Duplant of Google, and the working-group document carries all four forward. Adoption means the MAILMAINT group - the IETF’s maintenance home for email protocols - now owns the text, and revisions go through group review rather than one vendor’s judgement.

The technical deltas

A selector-less record. APRF records live under your DKIM selector tree, normally at <selector>._aprf._domainkey.<domain>. The working-group draft adds a third valid form: publish at plain _aprf._domainkey.<domain>, no selector label, and it covers every selector - an alternative to the wildcard record that existed from the start.

An explicit order of discovery. With three possible record locations, the draft now spells out which one a reporting provider should apply: the most specific match wins. An exact-selector record beats the wildcard, and the wildcard beats the new selector-less form. One editorial wrinkle worth knowing if you are implementing: the third item in the draft’s printed lookup list reads selector1._domainkey.<domain>, missing the _aprf label - taken literally that is the DKIM public key itself. It is an obvious editorial slip to be fixed in a future revision, not something to implement.

The subject-line typo is fixed. The original draft defined the report email subject prefix with transposed letters, ARPF:. The current text says APRF:. Collection pipelines should filter on APRF: and stay lenient by also accepting ARPF: from older implementations.

More guidance, same protocol. A new FAQ openly lists unresolved questions (can sdi= segmentation separate promotional from transactional mail, and how should ESPs handle reporting addresses), and a new deployment appendix describes three ways a signer can split its report data: the sdi= segmentation tag, a different d= signing domain per stream, or a different selector per stream.

Everything else is untouched: the v=APRFv1, rua= and sdi= tags, the off-domain consent record, the JSON schema with its classification and engagement buckets, filenames and content types, gzip, the one-UTC-day reporting window, and the recommendation that providers bucket values rather than send exact counts. The DNS record grammar is still marked TODO, so this remains a draft in active revision, not a finished spec.

What to do

If you already publish an APRF record - selector-specific or wildcard - it stays valid and reports keep flowing; there is nothing to change. If you are setting up now, the wildcard remains the safe way to cover all selectors until providers demonstrably support the selector-less lookup. Comcast is still the only mailbox provider emitting reports, so treat everything you collect as a dress rehearsal for wider adoption - which a working-group home makes meaningfully more likely.

Our deep-dive on how APRF works, revised for the working-group draft, covers the record syntax, the report format and the setup steps end to end.