Aggregate Performance Reporting (APRF) is a proposed IETF email specification that could give senders a clearer view of real email performance: aggregate inbox placement, unwanted or spam placement, and selected engagement signals reported by participating mailbox providers. For SMB leaders, CRM teams, IT teams and deliverability consultants, it could make diagnosis less dependent on estimates alone.
Direct Answer
APRF does not replace DMARC. It complements it. DMARC answers, “Who is sending with my visible domain, and is that mail authenticated and aligned?” APRF could help answer another question: “Where is mail signed with this DKIM identity being classified, and what aggregate feedback does a mailbox provider see?”
That distinction matters. APRF is a proposal, not a universally deployed standard. Comcast is reported as active with beta feedback. Google’s presence among the draft’s co-authors may point to broader interest, but it is not evidence that Gmail—or Outlook or every major provider—already supports APRF.
In Short
- APRF means Aggregate Performance Reporting.
- It is intended to provide aggregate email-performance feedback.
- Its DNS publication pattern is comparable in spirit to DMARC.
- It uses the DKIM signing domain and DKIM selector, rather than the visible From domain.
- Reports are delivered in JSON.
- Potential data includes inbox, unwanted, positive engagement and negative engagement.
- Comcast is cited as beta-active; adoption is still one to watch.
- It could become a valuable additional signal in Dharmail monitoring.
Why APRF Matters for Deliverability
Seedlist testing remains valuable. It provides a fast, repeatable way to estimate placement across test mailboxes. Yet a seedlist is not the full audience: it cannot always reproduce each recipient’s history, volumes, preferences or engagement patterns.
SMTP logs provide a different truth: accepted mail, rejections, deferrals and 4xx/5xx errors. An acceptance does not always state whether a message later reached the inbox or the unwanted folder. DMARC is essential for sender inventory, authentication and alignment, but it does not report inbox placement. Start with SPF, DKIM and DMARC configuration and DMARC XML report analysis.
If mailbox providers adopt it, APRF could add aggregate feedback derived from real provider-side classification. It would be a diagnostic signal—not an inbox-placement guarantee.
APRF vs. DMARC: Different Jobs
| Topic | DMARC | APRF | Sender impact |
|---|---|---|---|
| Main purpose | Identity and authentication governance | Aggregate performance observation | Keep security and placement diagnosis distinct |
| Identifier | Visible From domain plus SPF/DKIM alignment | DKIM d= domain and s= selector | Reliable DKIM becomes even more operationally useful |
| DNS record | _dmarc.example.com | [selector]._aprf._domainkey.example.com | Document domains and selectors |
| Feedback | Authentication, alignment, sending sources | Potential placement and engagement totals | Correlate both sources |
| Format | XML aggregate reports | JSON | Plan for the right collector/parser |
| Data | SPF, DKIM, DMARC, IPs and volumes | inbox, unwanted, positive/negative signals | Better correction prioritization |
| Primary use | Anti-spoofing and sender inventory | Deliverability monitoring | Neither replaces the other |
For the latest DMARC standards context, see what changed with DMARCbis.
How APRF Works in DNS
APRF is DKIM-based. A mailbox provider reads the signing domain d= and selector s= from the message signature, then looks for a TXT record at:
selector._aprf._domainkey.example.com. TXT "v=APRFv1; rua=mailto:aprf-reports@example.com;"The proposal also supports a wildcard pattern for multiple DKIM selectors:
*._aprf._domainkey.example.com. TXT "v=APRFv1; rua=mailto:aprf-reports@example.com;"The rua value tells a participating provider where aggregate reports should be delivered. Validate every production configuration against the final specification and each provider’s implementation requirements; this example is not a copy-and-paste deployment instruction.
The draft also describes an optional SDI tag, for Signer-Defined Identifiers. It can support a breakdown by a sender-controlled internal header such as a Campaign ID or Brand ID. That is useful for segmentation, but it also requires careful control of ESP behavior, internal headers and data governance.
What Is in an APRF Report?
APRF reports use JSON, which can be processed by a monitoring platform without first translating XML. This simplified example shows the intended shape:
[
{
"header": {
"version": 1,
"source": "Mailbox Provider",
"dkim_domain": "example.com",
"dkim_selector": "selector",
"report_start": 1783900800,
"report_end": 1783987199
},
"body": [{
"classification": { "inbox": 7800, "unwanted": 1400 },
"engagement": { "positive": 620, "negative": 85 }
}]
}
]sourceidentifies the reporting mailbox provider.dkim_domainis the DKIM signing domain.dkim_selectoris the selector used to sign.classificationcontains aggregate classification counters.inboxcounts inbox-classified messages.unwantedcounts unwanted / spam-folder classifications.engagementcontains aggregate engagement signals when provided.positiveandnegativeare aggregate signal counts, not named user events.
Read these numbers in context: send volume, message type, cadence, audience and prior reputation all matter. A password-reset email and a marketing campaign should not be measured as one homogeneous stream.
How APRF Could Complement Google Postmaster Tools
Google Postmaster Tools already offers useful Gmail signals for domains with enough volume, including reputation, complaints, authentication and delivery data. APRF could offer a more standardized and interoperable reporting model across any mailbox provider that adopts it.
For Dharmail, the goal would not be a dashboard metric in isolation. APRF could be correlated with DMARC XML, Google Postmaster Tools, SMTP errors, IP and domain reputation, seedlist testing, complaint rates and sending subdomains. A decline in inbox could then be investigated next to a DKIM-selector change, bounce increase or campaign expansion.
What This Could Change in a Dharmail Audit
Where APRF feedback is available, it could help Dharmail:
- find a technically accepted flow that is over-classified as unwanted;
- compare outcomes between signing domains, selectors or sending subdomains;
- observe the effect of an authentication, routing or DMARC-policy change;
- measure signals after list hygiene work;
- isolate the impact of a marketing campaign;
- prioritize DNS, reputation, content, targeting or list-quality corrections.
This integrated view prevents simplistic conclusions. Authentication may contribute to a placement issue, but so can reputation, list quality, content, volume patterns and complaints. Keep SMTP error diagnosis and spam or Gmail Promotions analysis in the investigation.
Limits and Cautions
APRF depends on mailbox-provider adoption. Its data is deliberately aggregate: it does not expose personal data or a recipient’s individual behavior. Placement feedback also does not replace technical or business-context analysis.
Organizations will need to define retention, access controls, privacy and GDPR-compatible handling. If SDI is used, sender-defined headers and the way ESPs or relays handle them need governance too. APRF can improve visibility; it cannot guarantee inbox placement.
Readiness Checklist
- Enable and verify DKIM on every sending flow.
- Document DKIM selectors, including ESP-managed selectors.
- Separate marketing, transactional and human email with sending subdomains where appropriate.
- Control DMARC alignment and analyze XML reports.
- Use dedicated, monitored reporting addresses.
- Prepare a tool that can ingest APRF JSON.
- Plan correlation with DMARC XML and Google Postmaster Tools.
- Monitor by message type, campaign and sending subdomain.
- Define GDPR-aware data governance and retention.
FAQ
What is APRF?
APRF is Aggregate Performance Reporting, a proposed specification for aggregate placement and selected engagement feedback from participating mailbox providers.
Does APRF replace DMARC?
No. DMARC handles authentication and alignment; APRF aims at aggregate mail performance feedback.
Is APRF already available everywhere?
No. It is a proposal under adoption. Comcast is cited as beta-active, but support should never be assumed across providers.
How is APRF different from DMARC reporting?
DMARC’s aggregate XML reports focus on authentication and alignment. APRF’s JSON reports could add aggregate inbox/unwanted classification and engagement signals.
Why does APRF use DKIM?
The DKIM d= domain and s= selector provide a specific technical identity for discovering the APRF record and separating signed flows.
What does inbox/unwanted classification mean?
It represents aggregate counts for inbox and unwanted-folder classification. Volume and message context determine how meaningful a shift is.
Can APRF tell me exactly who clicked or marked an email as spam?
No. APRF is aggregate reporting; it does not disclose individual recipient actions or named personal data.
How can an organization prepare?
Make DKIM dependable, document selectors and subdomains, analyze DMARC and centralize reporting with proper data governance.
Conclusion
APRF could become a major deliverability-monitoring building block because it may bring senders closer to a previously difficult signal: real aggregate placement and engagement at the mailbox provider. The practical preparation is already clear—reliable DKIM, controlled sending subdomains, analyzed DMARC and centralized reporting.
To prepare your domain for emerging reporting standards, audit SPF/DKIM/DMARC flows or build complete deliverability monitoring, contact Dharmail for a concrete audit and an operational action plan.