APRF: Aggregate Performance Reporting for Email [2026]

What Is APRF?

APRF stands for Aggregate Performance Reporting. In email it is a proposed report format and a DNS record that let mailbox providers share placement and engagement data with the companies that send mail.

Mailbox providers decide where a message lands based on reputation systems that senders cannot see into. The draft’s introduction puts it plainly: senders have little insight into systems that their own actions drive, which limits their ability to correct course (draft §1). APRF is the proposed answer: a daily report of reputation-relevant counts, focused on domain-based, specifically DKIM, metrics.

Two things to hold on to:

• It is about performance, not authentication. DMARC tells you whether your mail authenticated. APRF tells you what the mailbox provider did with it afterwards.
• It is keyed to the DKIM d= domain and selector, not the From domain. The report generator looks up your record using the domain and selector of a valid DKIM signature (draft §4), and the draft says the signing domain may not align with the 5322.From domain (§5.2.1).

APRF vs ARF

Searching for “ARF” and “APRF” lands people on the wrong page, so to be explicit:

• ARF (Abuse Reporting Format, RFC 5965) carries one report per message: a spam complaint or a DMARC failure report.
• APRF carries one report per DKIM domain and selector per UTC day: bucketed counts of placement and engagement.

Status: An Internet-Draft, Not a Standard

APRF is specified in draft-ietf-mailmaint-aprf-00, an Internet-Draft of the IETF mailmaint working group. It replaces an earlier individual draft by the same authors, who come from Comcast, Iterable and Google (draft front page).

Internet-Drafts are work in progress. Section numbers cited on this page are from this revision and the record syntax, report fields and delivery rules can change in later ones. The draft itself still carries open items, such as a missing ABNF for the record (§4.1.1) and a note on how a re-sent report for the same period should be treated (§8.1). Build for it knowing that, and re-check the draft before depending on a detail.

The APRF DNS Record

You publish a TXT record that tells a reporting mailbox provider where to send reports for mail signed by your domain. It can live in one of three places (draft §4):

For a message signed with d=foo.example.org; s=sel1, the lookup is sel1._aprf._domainkey.foo.example.org, which is the pattern <s>._aprf._domainkey.<d>.

The forms can be mixed. The most specific match wins, so an explicit selector record takes precedence over the wildcard, and the wildcard over the selector-less name (draft §4 and §4.2).

Tags

Examples from the draft (§4.4):

v=APRFv1;rua=mailto:reports@example.org;
v=APRFv1;rua=mailto:reports@example.org,mailto:reports2@example2.net;
v=APRFv1;rua=mailto:reports@example.org;sdi=MsgInfo,^

A full record in zone-file form:

*._aprf._domainkey.example.com.  IN  TXT  "v=APRFv1; rua=mailto:aprf@example.com"

Wildcard or per-selector?

For most senders, publish one wildcard record. ESPs and platforms rotate and add DKIM selectors, and a wildcard covers all of them with a single record and a single mailbox. Add an explicit selector record only when you want a specific stream’s reports to go somewhere else: the draft notes that with a wildcard everything goes to one destination, while stated selectors can have distinct ones (§13.2).

Build a valid record with the APRF generator, then confirm what a receiver will find with the APRF checker.

Sending Reports to Another Domain

If a report destination is not aligned with the DKIM domain, the report generator SHOULD validate it before sending. The destination domain publishes a TXT record (draft §9):

<selector>.<DKIM domain>._aprf.<report destination domain>   TXT   "v=APRFv1"

The value must be v=APRFv1; or v=APRFv1, and either the selector or the DKIM domain may be a wildcard, which authorizes everything to its left. The draft calls this similar to the validation done for DMARC external report destinations: a third party must opt in to receive your reports, so nobody can aim them at an unsuspecting mailbox.

If you use a reporting service, ask it for the authorization record it publishes, and check the record the receiver would look for with the APRF checker.

Segmenting Reports with SDI

The optional sdi (Signer-Defined Identifier) tag lets you split a report by something you control, such as brand or campaign (draft §4.3):

• The value is an RFC 5322 header name and a single printable ASCII separator, comma separated. The separator must not be ;, = or ,.
• The header MUST be DKIM-signed by the related signature.
• It holds up to four parts, from general to granular, for example Signer-Info: SenderCommonName^BrandNameRegionalDistinction^CampaignName.
• Providers MAY ignore it. Do not rely on it.

Two cautions. Pick a header name unlikely to collide with another signer’s, since two entities using one header with different separators produce poor results (§4.3.1). And segment names can end up in reports, so do not put anything sensitive in them (§4.3.1, §10.1).

If SDI does not suit, the draft lists alternatives: a separate d= domain per stream or customer (for example mkt.example.com and txn.example.com), or a separate selector per stream (§13.2).

What an APRF Report Looks Like

A report is valid JSON covering exactly one UTC day, from 00:00:00 to 23:59:59 (draft §5, §5.1). It has a header describing the report and a body of segments.

Header fields (§5.2.1)

Body (§5.2.2, §6, §7)

The body is a list of segments. Each has a classification (placement: for example inbox, unwanted, forwarded, promotional) and an engagement (positive, neutral, negative). Either section is optional, and the provider chooses what to share. A segment may carry a segment identifier when SDI was used. Without SDI the report is flat, with one segment and no identifier (§5.3).

This is the draft’s Sample 2, a flat report (§13.3.2):

[
  {
    "header": {
      "version": 4,
      "source": "Receiver MBP, Inc.",
      "dkim_domain": "example.com",
      "dkim_selector": "sel1",
      "report_start": 1709164800,
      "report_end": 1709251199,
      "contact_info": "reports@mbp.net",
      "extra_info": "TBD",
      "sdi_used": "N/F"
    },
    "body": [
      {
        "classification": { "inbox": 10000, "unwanted": 100 },
        "engagement": { "positive": 200, "negative": 100, "neutral": 20 }
      }
    ]
  }
]

Read it as: the provider named Receiver MBP, Inc. reports on mail signed d=example.com; s=sel1 for the UTC day ending at epoch 1709251199. sdi_used is N/F, so no SDI was found and there is a single flat segment. The classification counts are messages received that day. Engagement counts are actions taken that day, regardless of when the messages arrived (§6, §7).

How Reports Arrive

APRF reports come by email (draft §8, §8.1):

• The message is multipart/report; the report is an application/json attachment.
• The provider may gzip it. It then has the type application/gzip and the extension .json.gz, and a receiver SHOULD accept this.
• The attachment name is <yyyymmdd>_<DKIM domain>_<DKIM selector>_<source>.json, with the date being the report’s end date and spaces removed from the source.
• The subject is APRF: <yyyymmdd>_<DKIM domain>_<DKIM selector>_<source>.

The mechanics mirror DMARC aggregate reports: a dedicated mailbox, daily attachments, machine-readable content.

Reading the Numbers Honestly

The format invites misreading, and the draft is open about why:

• Counts are buckets. The draft recommends bucketed scalar values and suggests reporting the bucket’s upper bound. The bucket size, such as 10 or 10k, is the provider’s choice (§6). Never add them up or derive an inbox rate: you would be dividing bounds, not messages.
• A missing category is not zero. Classification and engagement are each optional, and the provider decides what to include (§5.2.2).
• Definitions differ by provider. There is no formal definition of positive, neutral or negative. A provider may count an open or a “not spam” report as positive, a forward or a folder move as neutral, and a spam report, deletion or unsubscribe as negative. Providers may treat their definitions as proprietary, though extra_info may carry some (§13.1).
• Treat version as a boundary. When it changes, the meaning of a category may have changed with it (§5.2.1).

The APRF report analyzer reads a pasted or uploaded report in your browser, uploads nothing, and shows counts exactly as reported, with no sums and no rates.

Privacy and Data Leakage

At low volume, a small count can expose information about individuals that would otherwise be lost in the noise. The draft suggests providers set a threshold on messages or distinct recipients before reporting (§10.1.1). The same section says a provider is not required to send reports to every destination that asks, and may decide on From alignment, domain reputation or other considerations (§10.1.2). A missing report is therefore not proof of a broken record. Segment names are also visible to the provider and can leak (§4.3.1).

APRF vs Other Signals

APRF’s angle is provider-reported placement for your real mail, pushed to you the same way DMARC aggregate reports are. It does not replace the others: DMARC still tells you who is sending as you, and provider dashboards remain the place for what each one publishes today. A seed test measures test inboxes, not your recipients.

How to Get Started with APRF

1. Find your DKIM signing domains and selectors. Look at the d= and s= of a message you sent, or run the DKIM checker. Remember that if an ESP signs with its own domain, the ESP’s record applies, not yours.
2. Pick a mailbox that can take daily attachments, ideally dedicated to APRF reports.
3. Publish the record. Build it with the APRF generator. Use the wildcard form unless you have a reason to split streams.
4. Check it with the APRF checker, which reads the record the way a receiver does.
5. Read the first report with the APRF report analyzer.

Expect reports only from providers that support APRF. Per Spam Resource, that is Comcast (Xfinity) in beta.

APRF Reports in DMARCguard

DMARCguard collects APRF reports. It receives and stores them alongside your DMARC reports. Its report addresses on reports.dmarcguard.io already publish the authorization record from draft §9, so adding your DMARCguard report address to an APRF record needs no extra DNS on the destination side.

Frequently Asked Questions

What is APRF?

APRF (Aggregate Performance Reporting) is an email reporting format proposed in an IETF Internet-Draft. A mailbox provider sends the owner of a DKIM signing domain a daily JSON report with bucketed counts of where its mail was placed (inbox, unwanted) and how recipients engaged with it (positive, neutral, negative). It reports performance, not authentication.

Is APRF an RFC or a standard?

No. APRF is an Internet-Draft of the IETF mailmaint working group. Drafts are work in progress and can change or be replaced between revisions, so treat the record and report format as a moving target and do not call it an RFC.

How do I publish an APRF record?

Publish a TXT record at *._aprf._domainkey.yourdomain.com (wildcard, every selector), selector._aprf._domainkey.yourdomain.com (one selector) or _aprf._domainkey.yourdomain.com (selector-less, checked last). The value is v=APRFv1; rua=mailto:aprf@yourdomain.com. Both v and rua are required, and a record without them must be ignored.

Is APRF the same as ARF?

No. ARF (RFC 5965) is the format for per-message abuse and feedback-loop reports, such as a spam complaint about one message. APRF is a daily aggregate of placement and engagement counts for a DKIM domain and selector. They share a name root and nothing else.

Why is APRF keyed to the DKIM domain and not the From domain?

The report generator looks up the record using the d= domain and the selector of a valid DKIM signature, and reports on that signing domain. The draft states the DKIM domain may not align with the 5322.From domain. If an ESP signs your mail with its own domain, the ESP’s record is the one that is consulted.

Can I add up the numbers in an APRF report?

No. Counts are meant to be bucketed, and a provider that buckets reports the upper bound of the bucket. Summing them or computing an inbox rate gives a precise-looking figure that is not real. A category missing from a report is not zero, and each provider defines positive, neutral and negative differently.

Which mailbox providers send APRF reports?

Spam Resource reports that Comcast is the only mailbox provider actively sending beta APRF reports. Expect no reports from other providers until they adopt the draft, and expect none at all if your DKIM domain has no APRF record.

How is APRF different from Gmail Postmaster Tools or Microsoft SNDS?

Those are dashboards you log into, one per provider. APRF is a single format that providers push to a mailbox you name in DNS, the same way DMARC aggregate reports arrive. It only helps once providers send it.

Related Protocols

• DKIM — The signature APRF reports are keyed to
• DMARC — Authentication reporting, and the model for external report authorization
• ARF — Per-message abuse and failure reports, not the same as APRF
• TLS-RPT — Reporting on transport encryption failures