APR: aggregate reports on delivery performance

APR (Aggregate Performance Reporting) is a proposal submitted to the IETF as an individual draft, draft-brotman-aggregate-performance-reporting, written by Alex Brotman (Comcast). The idea is to do for delivery performance what DMARC did for authentication: a sending domain publishes a reporting address in DNS, and willing mailbox providers periodically send it an aggregate report describing what became of its messages. The document is an individual draft, not adopted by any working group: it may be changed, abandoned or taken up in another form, and no mailbox provider has publicly committed to producing such reports. This page presents the proposal as it is written, without presuming its outcome.

The problem it targets#

Thanks to DMARC reports, a sender knows today whether its messages are authenticated. It does not know, in any structured way, whether they were accepted, deferred, rejected or filed as spam. That information exists at the providers but is only reachable in fragments:

• through SMTP response codes, which the sender has to collect and interpret on its own servers;
• through feedback loops, limited to complaints;
• through the postmaster tools of a few large providers, each with its own interface, metrics and access conditions.

APR proposes a single, standardised, automatable channel, initiated by the sending domain, on the model of DMARC's rua.

The principle#

Three elements, as described in the draft:

1. A DNS record published by the sending domain, giving the address reports should be sent to. The domain in question is the one the provider authenticated, typically through aligned DKIM or SPF, so that a third party cannot claim reports for a domain it does not control.
2. An aggregate report produced by the provider at regular intervals, grouping counters by domain, sending IP address or period: messages accepted, temporarily deferred, rejected, and where applicable the split between inbox and spam folder, with categories of reasons.
3. Transport by email to the published address, as with DMARC, the precise format and chunking of reports being defined by the draft.

What the record would look like#

The exact format belongs to the draft and may change from one version to the next. For illustration, the proposal follows the convention of TXT records under an underscore-prefixed label, with a version tag and a reporting address:

_apr.example.com.  IN TXT  "v=APR1; rua=mailto:apr-reports@example.com"

As with DMARC, sending reports to a third-party domain would require some form of authorisation on the receiving side, so that a domain cannot flood an address that never asked for its reports.

What it would change for senders#

If the proposal succeeded and providers adopted it, a sender could:

• measure its acceptance rate per provider without depending on its own logs;
• quickly detect spam-folder placement or a wave of reputation-related rejections;
• compare the performance of several streams or subdomains with a common metric;
• feed this data into the same tools as DMARC reports.

The stated limits are the same as for DMARC: reports are aggregated, so there is no per-message detail; they depend on each provider's goodwill; and the granularity of reasons remains at the discretion of whoever produces the report.

What to do today#

There is nothing to publish. An _apr record set up now would trigger no report, since nobody sends any, and would need revisiting if the format changes. The current sources of information remain your servers' SMTP codes, feedback loops and postmaster tools. Following the draft on the Datatracker and, if it happens, its adoption by a working group, is enough.

What SenderRadar shows#

SenderRadar displays no APR indicator, since the mechanism is neither adopted nor deployed. The domain page presents the reporting mechanisms actually in place, in particular the destinations declared in the DMARC policy and in TLS-RPT. SenderRadar relies on its own analysis base to track the appearance of new record types as proposals like APR progress.

References#

• draft-brotman-aggregate-performance-reporting (IETF Datatracker)
• RFC 7489 – DMARC, the aggregate reporting model the proposal draws on
• RFC 5965 – An Extensible Format for Email Feedback Reports (ARF)