Email senders have access to plenty of information about what happens while email is being delivered. Authentication results tell us whether SPF, DKIM, and DMARC worked. Bounce messages explain why some messages were rejected, while complaint feedback loops provide another important reputation signal. What happens after a mailbox provider accepts a message, however, can be much harder to understand. A proposal called APRF, or Aggregate Performance Reporting, aims to provide another piece of that puzzle. APRF proposes a standardized way for participating mailbox providers to share aggregate information about how authenticated email was classified and how recipients interacted with it.
The important word here is aggregate. APRF isn’t intended to tell a sender what an individual subscriber did with a particular email. Instead, it provides summarized performance information across groups of messages, giving senders another way to identify trends and potential deliverability problems.
What Would APRF Tell Senders?
The APRF proposal divides performance information into two main areas: classification and engagement.
Classification describes what happened to messages after they were accepted. Examples in the current draft include inbox and unwanted placement, with other classifications potentially including promotional and forwarded. A mailbox provider could therefore report that a certain number of messages reached the inbox, while another group was classified as unwanted.
Engagement looks at recipient activity differently. Rather than defining specific actions universally, APRF groups engagement into positive, neutral, and negative categories. A mailbox provider decides how its own signals map into those categories.
For example, opening or clicking a message could represent positive engagement, while marking a message as spam could be negative. Filing or forwarding a message could be considered neutral. These definitions aren’t intended to be identical across every provider.
That flexibility is deliberate. Mailbox providers can provide useful performance information without revealing exactly how their filtering or reputation systems work. It also means APRF shouldn’t be interpreted as a universal deliverability or reputation score.
APRF and DKIM
APRF uses DKIM as the foundation for identifying the sender and discovering where reports should be delivered. Specifically, reporting is associated with the DKIM signing domain and selector used to authenticate the message.
For example, consider a message signed with:
d=example.com
s=selector1A participating mailbox provider could look for an APRF TXT record at:
selector1._aprf._domainkey.example.comA basic APRF DNS record could look like this:
selector1._aprf._domainkey.example.com. IN TXT "v=APRFv1;rua=mailto:reports@example.com;"The v=APRFv1 value identifies the APRF version, while rua provides the email address where aggregate reports should be delivered.
The draft also supports a wildcard, allowing one reporting policy to cover multiple DKIM selectors:
*._aprf._domainkey.example.com. IN TXT "v=APRFv1;rua=mailto:reports@example.com;"A sender can still publish a selector-specific record when different reporting instructions are required. This approach could make APRF considerably easier to manage for organizations regularly rotating DKIM selectors or using multiple sending platforms.
The current draft also includes destination validation when reports are sent to a domain that doesn’t align with the sender. This is similar in principle to the external reporting authorization used with DMARC and helps prevent domains from directing unwanted report traffic toward third parties.
What Does a Report Look Like?
APRF reports use JSON, a common structured data format that systems can process automatically. Each report covers one UTC day and identifies information such as the reporting provider, DKIM signing domain, DKIM selector, and reporting period.
A report could contain classification data such as:
"classification": {
"inbox": 10000,
"unwanted": 500
}It could also contain aggregate engagement information:
"engagement": {
"positive": 300,
"negative": 200,
"neutral": 50
}Mailbox providers aren’t required to provide every data point. Classification and engagement information are optional, and providers may also use ranges or other techniques rather than exposing precise activity.
The proposal also introduces an optional feature called a Signer-Defined Identifier, or SDI. This allows sophisticated senders to help separate reporting for different mail streams using the same DKIM infrastructure.
For example, an organization could distinguish marketing from transactional email, different brands, or individual programs. APRF supports up to four levels of segmentation. Mailbox providers can choose whether they support SDI, so senders shouldn’t assume this level of reporting will always be available.
Should Senders Implement APRF Now?
There is a bit of a chicken and egg problem with a proposal like APRF. Mailbox providers need to see enough sender interest to justify building reporting systems, while senders may hesitate to publish APRF records until more mailbox providers support them.
That may actually be a reason for interested senders to experiment early. Publishing an APRF record signals that a domain is ready to receive reports if a mailbox provider chooses to send them. Greater adoption among sending domains could also help demonstrate demand for this type of reporting.
APRF has also progressed since the original proposal appeared in March 2026. Version -01 was published in September, and the IETF Mail Maintenance Working Group has issued a Call for Adoption. This means the working group is considering formally taking on the work. APRF remains an Internet-Draft, however, and isn’t yet an RFC or finalized Internet standard.
For senders comfortable experimenting with an emerging specification, publishing a simple wildcard APRF record could be worth considering:
*._aprf._domainkey.example.com. IN TXT "v=APRFv1;rua=mailto:reports@example.com;"This may be particularly interesting if you have a significant audience at Comcast-supported domains. Comcast has been involved in APRF’s development, so senders with meaningful Comcast traffic have a practical reason to watch and experiment with the reporting format.
There are some important caveats. The specification can still change, mailbox provider support remains limited, and publishing an APRF record doesn’t guarantee that reports will arrive. Senders should also use a reporting address and process capable of handling machine-readable JSON reports rather than dropping them into someone’s everyday inbox.
I wouldn’t suggest that every sender rush to deploy APRF tomorrow. However, ESPs, deliverability teams, technically mature senders, and organizations with significant Comcast audiences may have good reasons to participate early.
Standards like this face a familiar problem. Senders want mailbox-provider support before implementing them, while mailbox providers want evidence that senders will actually use the data before investing in them. Someone eventually has to go first.
If APRF continues through the standards process and gains broader mailbox-provider support, it could fill an important gap in email reporting. It won’t replace DMARC, feedback loops, seed testing, or provider-specific tools. Instead, it could add a standardized source of information senders have historically struggled to obtain: what happened after the receiving server said 250 OK.
For anyone working in deliverability, that’s a pretty interesting place to get a little more visibility.
