APRF: The New IETF Deliverability Feedback Standard

Specification · Deliverability

Comcast, Iterable and Google are proposing a standardized format through which mailbox providers would send senders aggregated placement and engagement reports directly. A technical breakdown and its potential impact.

What is APRF?

APRF is an aggregated report format that tells a sender how their mail actually performs at a given mailbox provider (MBP). The discovery mechanism mirrors DMARC: the sender publishes a DNS record declaring a destination address, and any MBP that supports APRF sends them a daily aggregated report describing where their messages landed and how users interacted with them.

The key difference from DMARC: APRF does not rely on the From domain, but on the domain and selector of the DKIM signature present in the sent message.

The problem APRF sets out to solve

The email industry revolves around the notion of reputation. Mailbox providers use it to decide placement, permitted volume and how a stream is handled. The blind spot is that the sender has almost no visibility into these reputation systems, even though it is their own actions that feed them. The result: when something degrades, they are flying blind and struggle to take targeted corrective action.

APRF aims to close part of that gap by returning concrete metrics that influence reputation to the sender, straight from the source.

How APRF works, concretely

1. Publish a DKIM-based DNS record

The report generator reads the domain (d=) and selector (s=) from the DKIM signature of the received message, then queries a TXT record at:

._aprf._domainkey.

A minimal record looks like this:

v=APRFv1; rua=mailto:aprf-reports@example.com;

• v must always equal APRFv1; otherwise the record is ignored.
• rua specifies the destination address(es) for the reports (prefixed with mailto:, comma-separated if there is more than one).
• A wildcard (*._aprf._domainkey.domain) covers all selectors, with an explicit selector definition taking precedence.

2. Segment with SDI (Signer-Defined Identifiers)

The optional sdi attribute lets the sender request a breakdown of the data by an internal header they inject themselves (a campaign, brand or customer ID, etc.), up to four levels of granularity. The header in question must be DKIM-signed, and a separator character is defined in the record. The report generator remains free to ignore this attribute.

A caveat already flagged in the draft: overly fine-grained segment names can cause a data leak by appearing verbatim in the reports.

3. Receive the reports

Reports are delivered by email, as a JSON attachment (multipart/report, application/json attachment, optional gzip compression), and cover one full UTC day. The naming convention follows the form <yyyymmdd>_<DKIM domain>_<selector>_<source>.

What an APRF report looks like

The format is readable JSON, made up of a header (metadata: version, source/MBP, DKIM domain and selector, period, contact) and a body containing one or more segments. A representative structure:

[
  {
    "header": {
      "version": 1,
      "source": "MBP Provider",
      "dkim_domain": "example.com",
      "dkim_selector": "sel1",
      "report_start": 1709164800,
      "report_end": 1709251199,
      "contact_info": "reports@mbp.net",
      "sdi_used": "N/A"
    },
    "body": [
      {
        "classification": { "inbox": 10000, "unwanted": 500 },
        "engagement": { "positive": 300, "neutral": 50, "negative": 200 }
      }
    ]
  }
]

Two families of metrics structure the body:

Values are recommended as "buckets" rather than raw figures. An important detail for interpretation: the draft does not fix the exact definition of positive / neutral / negative. Each provider decides what goes into each category — its "secret sauce" — and may, if it chooses, spell it out via an extra_info field.

How APRF differs from seedlist tools

Inbox placement tracking is nothing new: platforms like Inbox Monster, Validity Everest or GlockApps have done it for a long time. But these tools traditionally rely on seedlists: you send the message to a panel of test mailboxes and estimate placement from that sample. APRF is different in nature: it delivers real aggregated data, driven by the actual behaviour of real recipients at the provider itself.

Reflection: what impact for SaaS inbox placement solutions?

Here is the question worth asking. If APRF were adopted by the major players — Gmail, Microsoft, Yahoo, Apple — part of the value proposition of SaaS inbox placement tracking solutions could erode. Once providers hand over the information at source, live and from real traffic, the role of an intermediary that estimates placement via seedlists becomes far less obvious.

That said, some nuance is in order, because these platforms are not limited to measuring placement. Pre-send testing (a seedlist tests a campaign that hasn't gone out yet; APRF only reports on mail already sent), multi-client rendering tests, competitive intelligence, historization and coverage of providers that will not implement APRF will remain relevant. The most likely outcome is therefore not disappearance but a shift: less value on raw measurement, more on analysis, pre-send testing and multi-source aggregation.

Between the submission of a draft and its implementation by the major providers, a lot of water will flow under the bridge.

We are talking here about an individual Internet-Draft at version -00, not adopted by a working group, with no formal standing in the IETF process, and for now implemented by a single provider in beta. The good news: Google's presence at the table makes broad adoption less theoretical than usual.

Where does standardization stand?

In other words: a signal worth watching closely, not yet a standard to build your production on.

FAQ

What does APRF stand for?

Aggregate Performance Reporting. It is an aggregated report format through which a mailbox provider communicates placement and engagement data about a sender's mail.

What is the difference between APRF and DMARC?

Both use DNS-record discovery and a rua address. But DMARC is about authentication and alignment (and relies on the From domain), whereas APRF is about performance and reputation and relies on the DKIM domain and selector.

Does APRF replace Google Postmaster Tools?

No. Postmaster Tools is a dashboard proprietary to Gmail. APRF is a standardized, interoperable format that any provider can implement and deliver by email — the whole point is to move away from the one-portal-per-provider model.

How can I receive APRF reports right now?

By publishing a TXT record v=APRFv1; rua=mailto:… at selector._aprf._domainkey.domain, signing your mail with DKIM on that domain, then collecting the JSON attachments you receive. In practice, today you will only receive reports from providers that have implemented it (Comcast in beta).

Will APRF kill inbox placement tools?

Not in the short term. It could reduce the value of seedlist-based placement measurement if the major providers adopt it, but pre-send testing, rendering, analysis and coverage of non-compatible providers keep their value. And large-scale adoption will take time.

Sources

1. Al Iverson, "APRF: A New Standard for Deliverability Feedback", Spam Resource, 19 July 2026 — spamresource.com
2. A. Brotman, T. Corbett, E. Gustafsson, "Aggregate Performance Reporting", draft-brotman-aggregate-performance-reporting-00, IETF, 17 March 2026 — datatracker.ietf.org

— End of article · APRFv1 · Updated July 2026