IETF draft revises DKIM-based email performance reporting
News
The IETF MAILMAINT working group has published draft-ietf-mailmaint-aprf-01, a material revision to its Aggregate Performance Reporting proposal. Published October 31, 2026 at 16:20:05 UTC, or November 1 at 03:20:05 AEDT in Sydney, the draft updates how experimental implementations discover reporting destinations and process reports. The official Datatracker entry identifies it as an active working-group Internet-Draft.
APRF remains a work in progress, not a final RFC, production guidance or a current requirement. It creates no enforcement deadline and promises no provider implementation. I read this revision as implementation clarification for an adopted proposal, rather than a sender compliance change. Its main news is what changed since working-group version 00 on October 9.
What changed since version 00
The October 9 adoption brought APRF into MAILMAINT's working-group document stream. This publication advances that existing work. It is not a first adoption or an unadopted individual submission.
Against the version 00 text, version 01 changes several details that affect prototype interoperability. Discovery and report delivery remain separate decisions, an important limit when one message carries signatures belonging to different organizations.
|
|
|
|---|---|---|
Discovery | No explicit per-signature advice | Each valid signature |
Destination check | From reference in example | DKIM domain reference |
Selector example | Missing APRF label | APRF label restored |
Segment value | String example | List of strings |
Sample version | Number | String |
Duplicate report | Open question | Replace prior data |
Implementation changes in working-group version 01.
These changes concern proposed APRF behavior. They do not change SPF evaluation, ordinary DKIM signature validation or DMARC alignment. A valid DKIM signature remains the authentication input to APRF discovery, rather than a new result produced by reporting.
The audience is implementers: authors of experimental report generators, report collectors and email providers. Sender platforms evaluating aggregate performance feedback also have concrete changes to review before comparing prototype results.
Discovery now covers each valid DKIM signature
Version 01 says report generators SHOULD perform destination discovery for each valid DKIM signature. For example, an email service provider can sign a message with its own domain while also adding a customer-domain signature. A prototype that considers only one signature would miss another signing identity's reporting request.
The recommendation applies to discovery. Finding two reporting records does not oblige a provider to send reports to both destinations. The generator retains a separate decision about disclosure, including which destinations receive data.
Selector lookup correction, not a deployment recipetext
Version 00 discovery example: selector1._domainkey.email.example.org Version 01 discovery example: selector1._aprf._domainkey.email.example.org
The corrected per-selector example restores the _aprf label. Without it, the name points into the ordinary DKIM public-key namespace. This is an example correction for proposed APRF discovery, not an instruction to move existing DKIM keys.
For experimental testing, I would include a message with two independently valid signatures and check discovery for both. A failed signature should not become a reporting identity simply because its header contains a domain and selector.
Destination checks follow the DKIM signing domain
The DNS-sample section now compares the reporting destination against the DKIM d= domain. Version 00 referred to RFC5322.From in that passage, even though the destination-validation section already described the DKIM domain. Version 01 makes those explanations consistent.
The distinction matters when the visible From address and signing domain differ. APRF is anchored to the verified signer. Its proposed external-destination authorization checks whether an outside destination accepts reports associated with that signing identity.
Proposed APRF destination check
Uses the DKIM signing domain when deciding whether external report-destination validation applies. The check concerns where reporting data is sent.
Existing DMARC alignment
Relates an authenticated SPF or DKIM domain to the visible From domain. It contributes to DMARC evaluation, not APRF destination discovery.
External authorization protects report destinations and reporting privacy. A published reporting request does not itself authorize unrestricted disclosure to another organization. Authorization also does not compel a provider to generate or disclose data.
This revision does not establish that an active vulnerability has been fixed. It clarifies a proposed reporting mechanism and does not change inbox filtering. The version 01 text is the implementation reference for evaluating these draft changes.
JSON types and duplicate handling become clearer
Report segment values are now explicitly JSON lists of strings. The sample reports also change version fields from numbers to strings, consistent with the field's existing description. Those details matter to collectors with strict type validation and generators built directly from earlier examples.
The following abbreviated fragment illustrates the corrected types. It is not a complete report or a stable schema contract. In particular, the report's version string is a generator-provided value, not the Internet-Draft revision number.
Illustrative field types in an experimental APRF parserjson
{ "header": { "version": "42" }, "body": [ { "segment": ["ExampleCustomerID"] } ] }
New duplicate-report guidance says a later report matching the same report name and time period should overwrite the previous data. A collector should therefore test replacement rather than adding both reports into its totals.
I would test replacement imports separately from first imports. Reprocessing a corrected daily report should update the stored result without doubling counts. This is prototype handling advice derived from the revision, not a production migration requirement.
These corrections also change useful negative tests. A prototype receiver should distinguish a segment list from a scalar string, and exercise a later replacement with different counts. That catches type mismatches and accidental accumulation before comparing experimental reports. Keep those fixtures labeled with the draft revision they test.
Missing APRF reports do not establish a DNS fault
New signer troubleshooting text explains that publishing an APRF record requests reports but does not guarantee their arrival. A mailbox provider can lack APRF generation or withhold data for privacy or security reasons. Competitive considerations also influence disclosure.
That makes silence ambiguous. A missing report does not establish a DNS error, and repeatedly changing a record cannot force participation. Experimental operators need evidence about the generator's behavior before attributing missing data to discovery.
No rollout is established
The available evidence does not establish Gmail, Yahoo, Microsoft or Suped APRF rollout. Working-group publication and author affiliations are not implementation commitments. Ordinary senders should not publish speculative APRF DNS records.
APRF proposes aggregate classification or engagement information linked to a verified DKIM domain and selector, if a provider elects to share it. Such data is distinct from DMARC aggregate authentication reports and does not guarantee message-by-message inbox placement.
Keep this missing-report guidance separate from current production DMARC diagnostics. For existing DMARC reporting, investigate the reporting configuration and external authorization where applicable, along with traffic and report delivery. An APRF participation caveat is not a diagnosis of missing DMARC reports.
What experimental implementers should review
The useful next step is a focused review of prototypes against version 01. That work belongs in controlled experiments, where assumptions about reporting and data disclosure can be inspected before they become operational dependencies.
I would prioritize these checks because they exercise the boundaries changed or emphasized in this revision, rather than treating a successful JSON parse as proof that a complete reporting exchange works.
- Signature coverage. Compare discovery across separate valid provider and customer signatures. Keep the disclosure decision independent.
- Destination checks. Use the DKIM d= domain when testing external authorization, including a case where the visible From domain differs.
- Collector behavior. Test string versions, segment lists and replacement imports for matching report names and periods.
- Privacy review. Examine low-volume leakage and segment labels. Test suppression thresholds before sharing experimental data.
Aggregate reporting still exposes sensitive information when a group contains very few messages or recipients. Segmentation increases that risk by narrowing the population. Successful destination authorization does not settle whether a particular data set is appropriate to disclose.
For collectors, incomplete optional data should remain visibly incomplete. Missing classification information does not mean every message reached an inbox, and missing engagement information does not mean no recipient interacted with the messages.
Keep current sender operations separate
Ordinary domain owners should continue maintaining SPF and DKIM, reviewing DMARC reports and following documented provider complaint and reputation guidance. Current DKIM DNS checks help inspect published signing keys. A real-message email test helps inspect the authentication of a message that was actually sent. Neither establishes APRF participation.
The operational trigger to watch is explicit provider documentation describing support and reporting behavior. Until then, monitor MAILMAINT's revisions and keep experimental APRF configuration separate from production DNS. Version 01 gives implementers more precise material to evaluate; it gives senders no new deployment deadline.
Frequently asked questions
No. It is an active MAILMAINT working-group Internet-Draft and remains a work in progress. Adoption gives it working-group status, but does not make it a final RFC or a current production requirement.
No. Version 01 recommends discovery for each valid DKIM signature. Deciding whether to send reports, and which destinations receive them, remains separate.
No. APRF proposes optional performance information associated with DKIM signing identities. DMARC aggregate reports concern authentication and policy evaluation associated with the visible From domain.
Ordinary senders should wait for documented provider support. The draft is not deployment guidance, and publishing a reporting request does not guarantee reports. Continue existing authentication and provider reputation checks.
