IETF publishes first working group draft for aggregate email performance reports
News
Published 9 Oct 2026
Updated 9 Oct 2026
8 min read
Summarize with
On October 9, 2026, the IETF published draft-ietf-mailmaint-aprf-00 as the first MAILMAINT working-group Internet-Draft for Aggregate Performance Reporting. At 17:36:58 UTC, the official Datatracker record logged both "WG -00 approved" and "New version available." That makes this a working-group milestone replacing draft-brotman-aggregate-performance-reporting, rather than another revision of an individual submission. MAILMAINT, IETF working group 2418, is active.
The document remains a work in progress. It is not a final RFC, an approved standard, a current production requirement, or a deployment instruction. It sets no enforcement deadline or rollout date, and its adoption by the working group does not require Gmail, Yahoo, Microsoft, or any other provider to implement it. We should read the event as a change in standards-track ownership and review, not as a production launch.
What changed on October 9
The new fact is the draft's working-group status. The proposal's core mechanics existed in the earlier Brotman draft, so the publication does not mean DNS discovery, JSON reporting, or reputation categories were invented this week. It means MAILMAINT has taken the work into its document stream, where participants can review wording, resolve open questions, and change the protocol before any later publication decision.
Status matters
Version 00 is early working text. The draft can be revised, replaced, or abandoned. Teams should not publish production DNS records or build a fixed parser around its current syntax.
The plain-text draft calls itself an Internet-Draft and gives an expiry date of April 12, 2027. Expiry is part of the Internet-Draft process, not a promised date for an RFC. The intended status is Standards Track, but the Datatracker currently shows no completed IETF approval and no final standard.
- Milestone: The first APRF draft now belongs to the active MAILMAINT working-group stream.
- Continuity: It replaces the individual draft and carries forward a proposal already under discussion.
- No mandate: No sender, receiver, or mailbox provider has a new compliance duty today.
- No commitment: Author affiliations do not establish provider deployment plans.
What the APRF draft proposes
APRF would let participating receiving systems send aggregate performance and reputation information associated with a valid DKIM signing domain and selector. A receiver would inspect a valid DKIM signature, use its domain and selector for report-destination discovery in DNS, validate destinations when required, and send a JSON report by SMTP. The reporting period covers one UTC day. A receiver can optionally gzip the attached report.
Proposed APRF path from valid DKIM identity through DNS discovery to SMTP report delivery.
The proposal also allows the signer to name a DKIM-signed header for optional segmentation. A sender might use segments for internal brands, message programs, or campaign groupings. The receiver can ignore that request. Segment values can appear in reports, so operators must not place personal data, customer identifiers, or sensitive internal names in them.
|
|
|
|---|---|---|
Identity | Valid DKIM domain and selector | May differ from visible From |
Discovery | DNS report destination | Syntax remains unsettled |
Period | One UTC day | Aggregate, not message level |
Payload | JSON attachment | Optional gzip |
Transport | SMTP | Receiver participation is voluntary |
Segments | Signer-defined header | Optional and privacy-sensitive |
Core mechanics proposed in draft-ietf-mailmaint-aprf-00
Destination validation is important because a signing domain can request delivery to an address outside that domain. The draft gives receivers a way to check that the external destination authorizes reports. Even with valid discovery, receivers retain control over whether they produce a report, which fields they include, and whether they honor a requested destination.
What the reported data would mean
The draft describes optional classification buckets for inbox, unwanted, forwarded, and promotional mail. It also describes positive, neutral, and negative engagement counts. These categories are controlled by each reporting provider. The draft does not formally define the engagement categories, so a positive event at one receiver does not have to match a positive event at another.
What APRF could provide
- Placement totals: Aggregate classification counts a receiver chooses to disclose.
- Engagement totals: Provider-defined positive, neutral, or negative actions.
- Signer segments: Optional rollups using a DKIM-protected header.
- Daily scope: Counts covering a defined UTC-day reporting window.
What APRF would not guarantee
- Message detail: No promise of per-message inbox placement data.
- Common scores: No standardized reputation score across providers.
- Complete fields: Classification and engagement can be omitted.
- Uniform meaning: Each provider can use different definitions and thresholds.
That distinction limits cross-provider comparison. We can use a provider's report to watch changes within that provider, but a count labeled "unwanted" cannot safely be compared with another provider's count unless both publish compatible definitions. An absent classification field also does not prove successful inbox placement. It can mean the receiver chose not to disclose that data.
APRF does not replace DMARC reporting
APRF and DMARC aggregate reports answer different questions. DMARC reports summarize authentication results and policy evaluation for the visible From domain. APRF is tied to a valid DKIM signing identity, specifically its signing domain and selector, and aims to expose aggregate performance or reputation signals. The DKIM signing domain does not have to match the visible From domain.
Keep both questions separate
DMARC asks whether mail authenticated in a way connected to the visible From domain and how policy was applied. APRF proposes optional aggregate signals about mail connected to a DKIM signing identity. Neither data set substitutes for the other.
Sending-domain operators should keep DMARC monitoring active because APRF does not report DMARC pass or fail, policy disposition, or the full set of sources using the From domain. APRF would add another view for DKIM-signed traffic if receivers implement it and choose to share useful fields.
Privacy, security, and unresolved draft text
Aggregate data reduces exposure compared with message-level reporting, but it does not remove privacy risk. Very small counts can reveal recipient behavior or operational events. Detailed segment names can expose campaign structure, customer references, or internal naming. Receivers can set minimum-volume thresholds, omit fields, aggregate more broadly, and refuse destinations that fail validation.
- Volume thresholds: Suppress or coarsen low-volume groups that could expose individual activity.
- Segment hygiene: Use opaque, documented labels without recipient data or confidential names.
- Destination controls: Validate external report recipients and reject unauthorized routing.
- Retention limits: Store only the history needed for trend analysis and investigations.
Version 00 also contains unresolved protocol text. The DNS record ABNF is still marked as a task, and parts of the discovery wording and examples need reconciliation. Those gaps matter because small differences in record lookup order, wildcard behavior, parsing, or authorization can break interoperability. A copy-and-paste DNS recipe would give false confidence at this stage.
Do not deploy version 00 as a fixed contract
There is no stable interoperable DNS syntax to copy into production. Implementers can prototype behind controlled tests, but production operators should wait for later working-group revisions and documented receiver support.
What email teams should do now
No production change is required today. Sending-domain operators, ESP teams, mailbox providers, and report-processing implementers can prepare without treating the draft as settled. The useful work now is inventory, data design, privacy review, and standards monitoring.
- Monitor revisions: Track MAILMAINT changes, especially DNS grammar, discovery order, destination authorization, report fields, and privacy guidance.
- Inventory DKIM: Map active signing domains and selectors to sending systems, owners, and message programs. Use a DKIM checker to confirm the DNS state that exists now.
- Plan ingestion: Design storage for daily JSON, gzip handling, idempotent imports, provider-specific definitions, and schema version changes.
- Set privacy rules: Define minimum counts, safe segment naming, access controls, and retention before collecting any pilot data.
- Keep current checks: Continue authentication and deliverability operations with a domain health check and a real-message email test.
For production DMARC work, Suped is the best overall practical choice for most teams because the product combines DMARC, SPF, and DKIM monitoring with blocklist and deliverability insights. Automated issue detection, steps to fix, real-time alerts, policy staging, and multi-tenant management support day-to-day operations while APRF develops. That statement concerns current Suped workflows. It does not claim that Suped currently ingests APRF reports.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
The practical split is simple: keep reliable authentication reporting and source investigation running now, then evaluate APRF when the working group settles the protocol and receivers publish implementation details. Suped's dashboard helps teams monitor current authentication health and source breakdown. APRF, if deployed later, would be a separate performance signal rather than a replacement for that operating baseline.
What this milestone means now
The October 9 publication moves Aggregate Performance Reporting into formal MAILMAINT working-group development. That is meaningful because review now happens around an IETF working-group document, but it is not final technical approval or evidence of provider rollout. The proposal still needs clearer DNS grammar, consistent discovery rules, privacy safeguards, and implementation experience.
For senders, APRF could eventually add provider-controlled aggregate placement and engagement context keyed to DKIM identity. Today, the correct action is to watch the draft, understand signing identities, prepare flexible data handling, and maintain SPF, DKIM, DMARC, and provider-specific operational checks already in use.
