What APRF inbox placement reports tell you, and what they don't
Adopted as an IETF working group draft on October 8, 2026. One provider sends reports today, and the figures are approximate.
A DMARC pass has never told you whether a message reached the inbox. You publish SPF, DKIM, and DMARC, the mailbox provider checks them, and DMARC reports tell you whether your mail authenticated. Postmaster tools count complaints. Seed tests measure addresses nobody reads. None of it says where your real mail landed. On October 8, the IETF's Mail Maintenance working group adopted a proposal to change that.
What APRF is
APRF, Aggregate Performance Reporting, is a proposed standard written by engineers at Comcast, Iterable, and Google, with Alex Brotman of Comcast as lead author. The first version appeared in March 2026 and a revision on September 8.
A mailbox provider that supports it sends a daily report on the mail you signed: roughly how much went to the inbox, how much it treated as unwanted, and how recipients reacted. Reports arrive by email as small data files, the way DMARC reports do, and each covers one day.
The reports are tied to DKIM, not to the From address. DKIM is the signature your mail server or sending platform adds to each message, and it names the domain that signed. That choice is deliberate. The From address says who a message claims to be from. The DKIM signature says who took responsibility for sending it, and that is what a provider's reputation system tracks.
What a report tells you
A report has two parts, and the provider decides whether to include either. The first is placement: how many messages went to the inbox, to spam, or to some other folder the provider names. The second is engagement: how many actions recipients took that the provider counts as positive, neutral, or negative. The draft leaves those definitions to each provider. A provider may explain its categories in the report, but it doesn't have to.
The numbers are rough on purpose. The draft recommends that providers report each count as the top of a range, a bucket, rather than an exact figure, and lets each provider pick the bucket sizes. For a small sender, a report may say little more than that some mail arrived.
A report looks like this. It is the flat sample from the draft, with the header trimmed to the fields that carry meaning.
[
{
"header": {
"version": 4,
"source": "Receiver MBP, Inc.",
"dkim_domain": "example.com",
"dkim_selector": "sel1",
"report_start": 1709164800,
"report_end": 1709251199,
"sdi_used": "N/F"
},
"body": [
{
"classification": { "inbox": 10000, "unwanted": 100 },
"engagement": { "positive": 200, "negative": 100, "neutral": 20 }
}
]
}
]The header says who reported, which signing domain and selector the report covers, and the day as Unix timestamps. The version is the provider's own format number. It changes when the provider adds or drops something it counts, so numbers on either side of a change don't compare. sdi_used reads N/F when your record has no sdi tag and N/A when it has one the provider ignored. In the body, inbox and unwanted count messages received that day, and the three engagement figures count actions taken that day on mail from any day. Each figure is the top of its bucket. With sdi in use, the body holds one block like this per segment.
There are two more reasons not to turn these numbers into an inbox rate. A bucket is a ceiling, so dividing one by another gives a ratio nobody measured. And the two halves of a report count different mail. Placement counts messages received that day. Engagement counts actions taken that day, on mail from any day.
Comcast's beta reports carry inbox and unwanted for placement, positive and negative for engagement, and no neutral count.
Where it stands
APRF is still a draft. On September 24, Murray Kucherawy, one of the working group's two chairs, opened a call for adoption, and it closed October 8. His closing note said the responses clearly supported the draft and that the group would consider it adopted absent an objection in the final hours. The IETF's records show it adopted that day. Adoption means the working group now owns the document and will revise it. It does not make APRF an RFC, the IETF's published standard. The formal grammar for the record is still marked TODO, and Brotman has agreed to try, inside the APRF draft, a report header that other email report types could share. Record details and report fields could change.
Two smaller things are unsettled too. The draft describes the outside destination check two ways: one section measures the report address against the signing domain, another against the From address. And now that the working group owns the document, its next revision will carry a working group name in place of the author's, so the draft-brotman name will stop updating and links to it will go stale.
Sending reports is voluntary. Comcast is running a beta for comcast.net mail and is the only provider known to send them. Google is represented among the authors but hasn't said it will send reports. No other provider has announced support.
Should you publish a record?
The record takes a few minutes and does no harm if no report ever arrives. Before you add it, check who signs your mail. The sure way is to read a message you sent. In Gmail, open it and choose Show original; other mail clients call this view source or view message details. Find the DKIM-Signature line. The d= value is the signing domain and the s= value is the selector. If d= is the platform's domain, the next paragraph is about you. If it's your domain, the one after is.
If your email platform signs with its own domain, the provider looks for the record on the platform's domain, not yours. A record on your domain will never be read, and any reports go wherever the platform asks for them, if it asks at all.
If your mail is signed with your own domain, you can publish the record. That includes the common setup where a platform gives you DNS records that point your DKIM key at the platform. The platform holds the key, but the signature names your domain, so the APRF record is yours to publish.
Google Workspace and Microsoft 365 both sign with your domain. Google Workspace uses the selector google unless you chose another when you turned DKIM on. Microsoft 365 uses selector1 and selector2 and switches between them when it rotates keys, so publish the bare record at _aprf._domainkey.<your domain> rather than one per selector, and it covers whichever selector is active. The bare record is also the right choice for any platform that gives you CNAME records at your domain. The APRF record sits at a different name from the DKIM CNAME, so the two don't collide.
If you send real volume to Comcast addresses, you may see placement data now, and when the next provider turns reporting on, you're already set up. A day with no report can mean too little Comcast traffic to report. The draft lets a provider hold back reports below a volume threshold, or decline to send to any address it chooses. Treat the data as what it is: rough, voluntary, and from one provider.
dns-audit.com checks each domain you audit for an APRF record, shows where reports would go, and checks whether an outside destination has agreed to receive them. The check is for information and doesn't change your results.
Technical details
The record is a DNS TXT record at
<selector>._aprf._domainkey.<signing domain>where the selector and signing domain are the s= and d= values in your DKIM signature. A minimal record reads
v=APRFv1; rua=mailto:[email protected]The v tag must be exactly APRFv1 and rua must be present, or the provider ignores the record. rua takes one or more mailto: addresses separated by commas. A record at _aprf._domainkey.<signing domain>, or a DNS wildcard at *._aprf._domainkey.<signing domain>, covers every selector. A record for a specific selector takes precedence over either.
If the rua address isn't on the signing domain, the draft says the provider should confirm that the destination domain wants the reports, as DMARC does for outside report addresses. The destination publishes a TXT record at
<selector>.<signing domain>._aprf.<destination domain>with the value v=APRFv1. A wildcard in the selector position accepts reports for every selector on that signing domain, and a wildcard in the signing domain position accepts them from every signing domain. Without the record, a provider that follows the draft may not send. The draft states this check against the signing domain in one place and the From domain in another. The lookup name is built from the signing domain, so that is the reading dns-audit.com follows. If your report address is on any domain other than the one that signs, publish the destination record.
The optional sdi tag names a header you sign with DKIM, plus a one character separator, for example sdi=Signer-Info,^. That header can carry up to four values from broad to narrow, such as brand, stream, and campaign, and a provider may split the report by them. Those values appear in the reports, so choose names you don't mind a report recipient seeing. Comcast's beta doesn't use sdi yet.
Reports are JSON, each covering one UTC day for one signing domain and selector, though the draft lets a provider roll all selectors into one report. They arrive as an email attachment named <yyyymmdd>_<domain>_<selector>_<source>.json, sometimes gzipped.