APRF Explained: The IETF's New Aggregate Performance Reporting Standard for Email

Henry Timmes Email Deliverability Consultant · Named contributor to RFC 7489 & RFC 9989 (DMARC)

APRF, short for Aggregate Performance Reporting, is a proposed IETF format that would let mailbox providers tell senders how their mail is actually performing: how much of it reached the inbox, how much was treated as unwanted, and how recipients reacted. Reports are daily, aggregated, and keyed to your DKIM signing identity, much like DMARC aggregate reports are keyed to your From domain.

It is still a draft, not a finished standard, and so far only one large mailbox provider is known to be sending reports. This guide explains what is in the draft, how the DNS record works, and what is worth doing now versus waiting for.

What Is APRF?

APRF defines three things: a report format (JSON), a way for a mailbox provider to discover where to send the report (a DNS TXT record), and a delivery method (email, as an attachment). The reports summarize what happened to the mail a sender signed with DKIM over one UTC day, in two groups of numbers:

• Classification: where the provider put the mail, such as the inbox versus an unwanted (spam) location. The draft also mentions optional categories like forwarded and promotional.
• Engagement: how recipients reacted, counted as positive, neutral and negative actions. Each provider decides which actions count as which.

Until now, senders could only guess at the first group with seed-list tests and could see the second only through partial tools such as complaint feedback loops or Gmail Postmaster Tools. APRF is an attempt to standardize that feedback across providers.

Current Status: An Internet-Draft, Not an RFC

Treat everything below as a description of the draft, not of a settled standard. Field names, record syntax and delivery details can still move before publication. No mailbox provider has committed to implement it or announced a rollout date.

Why APRF Exists

Deliverability has always been measured indirectly. The usual tools each cover only part of the picture:

• Seed-list inbox placement tests send mail to test mailboxes and report where it landed. They are useful, but the mailboxes are artificial and have no real engagement history, so they only estimate what real recipients see.
• Complaint feedback loops using the Abuse Reporting Format (ARF, RFC 5965) report individual spam complaints, but they only cover complaints, only from providers that offer them, and Gmail does not offer per-message complaint reports at all.
• DMARC aggregate reports show who is sending as your domain and whether it passes authentication, but say nothing about inbox versus spam placement.

APRF fills the gap by letting a provider report what it actually observed for real recipients, in aggregate and without exposing individuals.

How APRF Works

1. You send mail signed with DKIM. The signature carries a signing domain (d=) and a selector (s=).
2. You publish an APRF TXT record in DNS for that domain and selector, naming the address that should receive reports.
3. A participating mailbox provider that sees enough of your mail looks up the record, using the d= and s= values from valid signatures.
4. Once a day, the provider sends a JSON report for the previous UTC day to the address in your record.

The key difference from DMARC is the identity. DMARC reporting is tied to the visible From domain. APRF is tied to the DKIM signing identity, which may be a different domain, such as your ESP's or a dedicated sending subdomain. That makes it useful for judging the reputation of a specific signing stream.

The APRF DNS Record

The record is a TXT record at a name built from the DKIM selector and signing domain:

selector._aprf._domainkey.example.org  TXT  "v=APRFv1;rua=mailto:reports@example.org"

Selectors, wildcards and specificity

A wildcard (*) can stand in for the selector so one record covers every selector on a domain, and the draft also allows a domain-level record. When more than one record matches, the most specific one wins: an exact selector, then the wildcard, then the domain-level record. The draft's own ordering list currently contains an inconsistency in this section, so expect that wording to be fixed.

External report destinations

If the rua address is on a different domain than the DKIM domain, for example reports going to a vendor, the provider should check for an authorization TXT record on the destination domain at <selector>.<DKIM domain>._aprf.<report destination domain> whose value is v=APRFv1. This is modeled on DMARC's external destination verification and stops third parties from pointing reports at someone who never asked for them. The formal syntax for this record is still marked as a to-do in version 00.

Segmenting reports with SDI

Signer-Defined Identifiers let you slice the data by brand, region, campaign or whatever fits your sending. You add a header to your messages, include it in the DKIM signature, and tell APRF its name and separator:

Signer-Info: BrandName^Region^CampaignID

selector._aprf._domainkey.example.org  TXT  "v=APRFv1;rua=mailto:reports@example.org;sdi=Signer-Info,^"

Public write-ups of the draft describe up to four levels, from least to most granular. The separator cannot be ;, = or ,. Receivers may ignore segmentation entirely, and the draft warns signers not to put sensitive information in segment names.

What an APRF Report Contains

A report is a JSON document with a header and a body. The header identifies who is reporting and what it covers; the body is a list of segments, each with optional classification and engagement counts.

Here is an illustrative report body. The structure follows the draft's field names, but the values are invented, the exact JSON nesting may change before publication, and real providers will define their own buckets:

{
  "header": {
    "version": "1",
    "source": "ExampleMailbox",
    "dkim_domain": "example.org",
    "dkim_selector": "sel1",
    "report_start": 1791417600,
    "report_end": 1791504000,
    "sdi_used": "N/A"
  },
  "body": [
    {
      "classification": { "inbox": 50000, "unwanted": 1000 },
      "engagement": { "positive": 500, "neutral": 5000, "negative": 100 }
    }
  ]
}

What APRF deliberately leaves out: per-message placement data, a standardized cross-provider reputation score, and DMARC pass/fail or policy results. Because each provider defines its own engagement categories, a negative count from one provider is not directly comparable to another's.

How Reports Are Delivered

Reports arrive by SMTP at the rua address as a multipart/report message with the JSON as an application/json attachment, plus an optional plain-text part. The attachment and subject follow the pattern <yyyymmdd>_<DKIM domain>_<DKIM selector>_<source> (the date is the report's end date), with the subject prefixed APRF: . Gzip compression (.json.gz) is optional and receivers should accept it. As with DMARC aggregate reports, use a dedicated mailbox or a processing service rather than a person's inbox, because these reports are meant to be parsed by machines. The draft has not yet settled whether a later report for the same period replaces an earlier one.

Privacy and Bucketing

Because counts can expose individual recipients at low volume, the draft expects counts to be bucketed, for example by reporting each bucket's upper bound, so the real figure is somewhere below it. It also suggests a minimum volume or recipient threshold before a report is generated, and says providers are under no obligation to send reports to every requester. The result is intentionally approximate: good for trends and alerts, not for exact accounting.

APRF vs DMARC Reports, ARF and Seed Tests

These are complements, not replacements. You still need SPF, DKIM and DMARC for authentication, and you still want complaint feedback loops where they exist. APRF would add the missing piece: what the provider actually did with your mail. You can check your own authentication records with the DMARC lookup and DKIM lookup tools, and test placement in test mailboxes with the inbox placement tester.

Who Supports APRF Today?

Based on public reporting from mid-2026, Comcast is running beta code that generates APRF reports for its own recipients, and at that time it was the only mailbox provider known to be sending them. Segmentation (SDI) was not yet live in the beta. Google is a co-author of the draft, but co-authoring is not a deployment commitment: Gmail was not sending APRF reports when those articles were written, and no provider has promised a date. Participation is voluntary, and providers may decline to send reports to a destination based on From alignment, reputation or other factors. Check the provider's current documentation before assuming coverage.

Open Issues in the Draft

• The formal ABNF for the DNS records is not written yet.
• Some discovery wording, such as lookup order and wildcard behavior, and some examples still need to be reconciled.
• Privacy safeguards for small counts and for segment names need more work.
• Engagement categories are provider-defined, so cross-provider comparison is unreliable.
• Whether a re-sent report for the same period overwrites the earlier one is undecided.
• The IANA considerations section is empty.

What Senders Should Do Now

1. Sign your mail with DKIM using a domain you control. APRF identifies you by the DKIM d= domain, so mail signed only by a shared ESP domain gives you little to report on.
2. Use meaningful, consistent selectors. Separate streams, such as marketing and transactional, are easier to read when they sign with different selectors.
3. Optionally publish an APRF record pointing at a dedicated mailbox. It is low-risk because providers that do not support APRF simply ignore it, but it only pays off once a provider that you send to starts reporting.
4. Be ready to parse JSON. Plan a small ingestion job or ask your ESP or monitoring vendor whether they will process APRF for you.
5. Consider an SDI header if you want per-brand or per-campaign data, and keep sensitive names out of it.
6. Keep the fundamentals in place: SPF, DKIM, DMARC, list hygiene and engagement-based sending. APRF reports what providers see; it does not change it. See the email deliverability guide for the full checklist.
7. Watch the draft. Revisit your record and parser when the specification changes or when your major mailbox providers announce support.

APRF FAQs

What does APRF stand for?

APRF stands for Aggregate Performance Reporting (Format). It is the name used for the IETF draft that defines aggregate email performance reports.

Is APRF an official standard yet?

No. It is an Internet-Draft adopted by the IETF MAILMAINT working group, intended for the Standards Track. It has not been published as an RFC and may change.

How is APRF different from DMARC aggregate reports?

DMARC aggregate reports are keyed to your visible From domain and cover authentication and policy results. APRF is keyed to your DKIM signing domain and selector and covers placement (inbox versus unwanted) and recipient engagement. They answer different questions.

Is APRF the same as ARF?

No. ARF (Abuse Reporting Format, RFC 5965) carries individual reports about a single message, typically a spam complaint. APRF carries daily aggregate counts and does not identify individual messages or recipients.

Do I need to publish an APRF record today?

You do not have to. Publishing one is harmless if you send DKIM-signed mail, and it positions you to receive reports from any provider that starts sending them, but at the time of writing only one provider is known to be doing so.

Will APRF replace inbox placement tests?

Not soon, and probably not entirely. APRF reflects real recipients at participating providers, but it is aggregated, approximate and limited to providers that send it. Seed tests still let you check placement across providers on demand, before a campaign goes out.

Sources

• IETF Datatracker: draft-ietf-mailmaint-aprf (Aggregate Performance Reporting)
• Spam Resource: APRF, A New Standard for Deliverability Feedback
• emailexpert: Industry veterans propose a standard to tell you where your mail lands
• Resend: How APRF helps you understand your email reputation
• Twilio: What is Aggregate Performance Reporting Format (APRF)?
• RFC 5965: An Extensible Format for Email Feedback Reports (ARF)
• RFC 9991: DMARC Failure Reporting