Mailbox providers have always known exactly where your mail lands and what recipients do with it once it arrives. Senders have been guessing, and paying for tools that guess slightly better.
That asymmetry is the reason seedlist testing, inbox-placement panels, and a good share of the deliverability tooling industry exist. A draft now circulating at the IETF attacks it directly.
APRF, Aggregate Performance Reporting, is an individual Internet-Draft from Alex Brotman (Comcast), Tom Corbett (Iterable), and Emil Gustafsson (Google), published on 17 March 2026 as draft-brotman-aggregate-performance-reporting-00. The mechanism is small: publish one TXT record, and participating mailbox providers email you a daily JSON report showing inbox-versus-spam placement and engagement counts for mail signed by your domain. Real recipient behaviour, at no cost, without a panel.
Comcast is already generating live beta reports. We know because our collection mailbox is full of them. Google co-authored the spec and sends nothing yet, and no other provider has announced support. So what exists today is a one-provider beta wrapped in a version-00 draft that has not been adopted by any working group and still has TODO markers where the ABNF should be. It is worth deploying anyway. The record costs nothing, the data is real while it flows, and a spec at this stage gets shaped by whoever shows up with deployment experience.
We manage DNS for a large portfolio of client domains, and we are rolling APRF out across more than 100 of them. Setting that up surfaced a set of edge cases that a single-domain writeup never hits. What follows is the field guide: how discovery actually works, where it breaks, how to run collection centrally so you never touch a client zone twice, and what the live reports contain, including a finding about the numbers that the draft only hints at.
Credit where it is due: Al Iverson's breakdown at Spam Resource is what put this on most people's radar. The primary source for everything technical below is the draft itself.
How the APRF record works: the DKIM signature, not the From address
APRF keys off the DKIM signature. The report generator takes the d= and s= values from a valid signature and queries a single name:
<selector>._aprf._domainkey.<d= domain> TXTThe record is minimal:
*._aprf._domainkey.example.com. TXT "v=APRFv1; rua=mailto:aprf@example.com;"The draft explicitly allows a wildcard to the left of the _aprf label, which covers every selector with one record, and normal DNS precedence applies if you later need an explicit selector record for a specific mail stream. The v tag must be exactly APRFv1 or the record is ignored, and a record without a rua is treated as a signal that you do not want reports at all. Multiple destinations are comma-separated, each with its own mailto:.
Reports arrive over SMTP, one UTC day per report, as a JSON attachment that the generator may gzip.
What a live Comcast APRF report actually contains
Within days of the records going live, reports started arriving: one message per signing domain, per selector, per UTC day, from aprf-noreply@alerts.xfinity.com, with the JSON attached.
The subject line follows the format the draft mandates for the attachment name, <yyyymmdd>_<DKIM domain>_<DKIM selector>_<source>, and the envelope alone tells you several useful things.
[
{
"header": {
"version": 1,
"source": "Comcast/Xfinity",
"dkim_domain": "example.com",
"dkim_selector": "mte1",
"report_start": 1785024000,
"report_end": 1785110399,
"contact_info": "aprf-noreply@alerts.xfinity.com",
"extra_info": "",
"sdi_used": " - N/A - Beta - Not in use"
},
"body": [
{
"classification": {
"inbox": 700,
"unwanted": 0
},
"engagement": {
"positive": 0,
"negative": 0
}
}
]
}
]Reporting is genuinely per-selector. A domain signing with a Google Workspace key and an ESP key produces two separate daily reports, which means you can compare placement per mail stream on the same domain, something DMARC aggregate data never gave you. That is not a theoretical benefit. One domain in our portfolio shows recurring spam placement on its Google Workspace stream while the ESP-signed streams on the same domain stay clean, a divergence that no reporting keyed to the From domain would ever have separated out.
The window is exactly one UTC day, report_end - report_start of 86,399 seconds. Delivery is consistent to the minute: every report for a given day arrives in a single burst at roughly 06:43 UTC the following morning, which is just before midnight on the US west coast and a little before nine in the morning in central Europe. The draft says nothing about when reports should be sent, so treat that as a property of Comcast's current batch job rather than something to build alerting around.
Two fields are worth reading closely before anyone builds a parser. sdi_used comes back as " - N/A - Beta - Not in use", where the draft specifies N/A or N/F, so Comcast is signalling beta status in a field with a defined value set. There is no reason to inject Signer-Defined Identifier headers yet. And while the draft leaves the classification categories open, mentioning inbox, unwanted, forwarded and promotional as possibilities, every payload we have seen carries only inbox and unwanted, with positive and negative engagement. The neutral category the draft describes is not reported as zero; the key is absent entirely, so the beta implements a subset of the format.
Otherwise the payloads are rigidly consistent, which is good news for anyone automating collection. Across all 116 files the header key set, the version, the source string, and the 86,399-second window were identical, and the date, domain, and selector encoded in each filename matched the header fields in every file. One structural caution: the payload is a JSON array, and although Comcast has only ever placed a single report object inside it, the format allows more. Iterate over it rather than indexing the first element.
The selectors visible in nine days of subject lines are the argument for the wildcard record on their own. They range from tidy values like s1, ggl and mailjet to 32-character machine-generated Amazon SES strings. Nobody is maintaining explicit records for those by hand. The reports themselves are also a small masterclass in sender hygiene: DKIM-signed by alerts.xfinity.com, with BIMI verification showing next to the sender. The report generator inboxes its own deliverability reports with a blue checkmark.
Why the numbers in an APRF report are not message counts
Comcast reaches a fraction of any portfolio, so the records on 100-plus domains produced reports for 13 of them. Across the 116 payloads those 13 domains generated, covering 28 distinct domain-and-selector streams over nine days, every classification and engagement value in every report was a multiple of 100. Observed values climb in even hundreds to 800 and then jump straight to 2000, with nothing in between:
0, 100, 200, 400, 500, 600, 700, 800, 2000
Real mail streams do not produce numbers like that. These are bucket labels, and the draft says so if you read section 6: report generators are encouraged to bucket the values and to report the upper bound of the bucket, with bucket sizes left entirely to the generator. An "inbox": 700 does not mean 700 messages reached the inbox. It means the true count fell somewhere inside the bucket that tops out at 700.
The gap in the observed values is itself evidence about how the bucketing works. Fine steps of 100 appear all the way to 800, but nothing between 800 and 2000 turned up in any of the 116 payloads, while 2000 appeared repeatedly. That points to uniform granularity at low volume giving way to at least one much wider bucket above it, and probably to further tiers that this portfolio's volumes never reached. Where that boundary sits is not something the draft will tell you, so it has to be mapped from observation.
The practical consequence is that you should never divide these numbers. A payload showing "inbox": 100, "unwanted": 100 is not 50% spam placement. Both true counts sit somewhere below their bucket ceilings, and the real ratio could be anything.
At Comcast's current granularity, APRF answers whether a meaningful share of a stream is going to spam and whether that is changing week over week. It does not tell you an inbox placement rate. Trend it, do not run arithmetic on it.
Coarse is not the same as meaningless. The highest-volume stream in the portfolio reported the top bucket on eight of nine days, and the single day it dropped to 700 was a Sunday, which is exactly where that stream's real send volume falls off. The buckets track actual traffic even though they refuse to quantify it.
The engagement block uses the same buckets, and it produced the most interesting payloads in the batch. Several reports look like this:
"classification": { "inbox": 400, "unwanted": 0 },
"engagement": { "positive": 0, "negative": 100 }
Zero spam placement, and negative engagement anyway. The pattern recurred across several streams rather than appearing once, so it is a real phenomenon rather than a stray payload. That combination is the design working as intended. The draft treats placement and engagement as separate axes, and lists complaints, deletion without opening, and unsubscribes among the actions a provider might count as negative. All of those happen to mail that reached the inbox.
A stream can win the filter and lose the reader, which is invisible in every other feedback mechanism senders have, and it is a useful corrective if your only read on recipient behaviour is your ESP's numbers. Anyone who has watched a campaign report strong opens while complaints climb already knows why open and click-through rates can mislead. APRF splits the two signals apart: the classification block describes your infrastructure, the engagement block describes your content and your audience.
Two things to keep in mind when reading engagement at this stage. At these volumes the block is effectively binary, since every engagement value in the set was either 0 or 100, so treat it as a flag that something happened rather than as a magnitude. And positive engagement is rare but not absent: exactly one payload in 116 carried positive: 100, alongside clean placement.
APRF has no subdomain fallback
DMARC spoiled everyone. No record on the subdomain, fall back to the organizational domain. APRF has nothing of the sort. There is exactly one lookup, built literally from the d= value, and if a record is not sitting at that exact name, no reports arrive and nothing tells you why.
Wildcards do not rescue this. The wildcard in *._aprf._domainkey.example.com floats the selector, which is the leftmost label. A subdomain sits to the right of the fixed _aprf._domainkey labels, where DNS wildcards under RFC 1034 and RFC 4592 simply do not operate. Something like *._aprf._domainkey.*.example.com is not a wildcard at all; it is a literal label named * that will never match anything.
So the deployment unit is not the domain. It is the distinct d= value, one record each:
*._aprf._domainkey.example.com. TXT "v=APRFv1; rua=..."
*._aprf._domainkey.mail.example.com. TXT "v=APRFv1; rua=..."One nuance worth knowing: the report format does allow a generator to roll data up to a higher-level domain and mark it with an asterisk in the dkim_domain field. That is a choice about report contents, not a discovery fallback, and it is not something Comcast is doing today.
Finding your actual d= values before you publish anything
The From header tells you nothing here. Relaxed DMARC alignment means mail from mail.example.com passes whether the signature carries d=mail.example.com or d=example.com. Identical green checkmarks in your reporting dashboard, different APRF record locations.
If you already collect DMARC aggregate data, you already have the inventory. Every aggregate report carries an auth_results block listing the DKIM domain and selector observed for each source, next to the header From domain, which is precisely the pairing APRF discovery needs. Any DMARC platform worth using exposes this in its per-source view. Filter to DKIM-passing sources over the last 30 days, read the DKIM domain column rather than the From column, and you have your list of names that need records. The same view answers the subdomain question from the previous section, because a subdomain appearing as its own d= value is a subdomain that needs its own APRF record.
Across our portfolio the same From-domain pattern splits both ways. Google Workspace and CNAME-delegated SendGrid setups typically sign on the root, while Mailjet-style configurations sign on the sending subdomain. The source above is the second case: the signature carries the sending subdomain and the ESP's selector, so a record on the root domain would never have produced a report for that stream. Guessing does not work. Pull the aligned d= values out of aggregate data, dedupe them, and publish one record per value. A list of 100 domains turns into a different, longer list of signing domains.
Dual signatures produce two reports for two different parties
ESPs commonly attach two signatures, yours and theirs. APRF runs discovery per valid signature, so your record captures reports for your signature, and the ESP's own _domainkey namespace captures reports for theirs. Only they can publish under their domain.
This looks intentional, and it explains why Iterable is on the author list. With dual signing, customer and ESP each get an independent feedback loop on the same mail stream. There is a sharp edge for agencies, though. If a client's mail carries only the ESP's signature, because the custom sending domain was never authenticated properly, there is nothing you can publish anywhere that will produce reports for them. Fix the DKIM setup first. APRF inherits whatever your authentication already looks like.
Destination validation: authorizing an off-domain reporting mailbox
If your rua points at a domain other than the d= domain, which it will for any centralized collection, the draft says generators should verify consent first, in the same spirit as DMARC's external destination verification. The generator queries:
<selector>.<dkim domain>._aprf.<destination domain> TXT → "v=APRFv1"You cannot pre-publish that per client selector, and you do not have to, because the spec allows either the selector or the DKIM domain to be a wildcard. One record on the mailbox domain authorizes everything:
*._aprf.dmarc.sh. TXT "v=APRFv1"
Skip this and a generator that follows the recommendation will quietly not deliver. The cost of the blanket wildcard is that a stranger could point their rua at your mailbox, which is harmless and occasionally informative. The draft also leaves generators free to decline destinations on alignment or reputation grounds, so nothing about this is a blank cheque. Worth noting for anyone reading the draft closely: section 4.3 describes the validation trigger in terms of alignment with the From domain while section 9 describes it in terms of the DKIM domain. Publishing the wildcard satisfies both readings.
The reason to take this seriously is that reporting addresses have a long history of pointing somewhere nobody is watching. We have documented cases where aggregate reports flowed for years to a domain the organization did not control, and APRF creates exactly the same class of exposure with a fresh set of unpublished records.
Centralizing APRF collection with CNAME delegation
If you already run DMARC for clients via CNAME delegation, the same pattern works here, and for the same reason: TXT lookups follow CNAMEs. Rather than publishing full APRF records in every client zone, each client gets one pointer, and the policy lives in a zone you control:
; in each client zone, published once
*._aprf._domainkey.<client signing domain>. CNAME apr.dmarc.cc.
; in our zone, the policy every client resolves to
apr.dmarc.cc. TXT "v=APRFv1; rua=mailto:aprf@dmarc.sh;"
; on the mailbox domain, destination authorization
*._aprf.dmarc.sh. TXT "v=APRFv1"
A wildcard record holding CNAME data is legal under RFC 4592, and resolvers synthesize the match. CNAME exclusivity still applies, so nothing else can live at that name, which is fine inside a dedicated _aprf._domainkey namespace. Three roles are in play and none of them need to share a domain: the client's signing domain, the zone holding the policy record, and the mailbox domain that receives the reports. Destination validation keys off the rua domain only.
The reason to bother, rather than pasting TXT records everywhere, is that this spec will change. It is a -00 draft with unfinished sections. If the tag format, version string, or reporting address needs to change across an entire portfolio, that is one edit in one zone instead of opening a hundred DNS consoles. We run a single shared target today. If you want per-client rua segmentation or the ability to switch one client off, use per-client target names such as <client>.apr.dmarc.cc and the pattern is otherwise identical.
Check one thing before assuming this works. Some ESP setups delegate the entire sending subdomain to the vendor via NS records instead of per-selector CNAMEs, and if the vendor runs the zone, you cannot publish _aprf names there without their cooperation. This is the same structural problem as a vendor holding DNS control over your DMARC reporting, and it is worth resolving on its own merits. Find where the zone cut actually is.
Smaller edges worth knowing before deployment
Parked domains produce nothing. Unlike DMARC, where a dormant domain generates reports the moment someone spoofs it, APRF only fires on valid DKIM-signed mail that was actually delivered, so records on domains that do not send are inert. The coverage numbers make the point concrete: records went out across more than 100 domains, and 13 of them produced Comcast reports in the first nine days. One provider with a specific consumer footprint will only ever see a slice of a portfolio, so expect most of your records to sit quiet until other generators come online.
Low volume may also report as nothing at all. The draft's security considerations suggest generators set a message or recipient threshold below which reporting is suppressed, so that individual recipients cannot be singled out. Comcast reinforces this by never sending an empty report: no payload in our set had an all-zero classification, only three of the 28 streams reported on all nine days, and more than half never reported anything above the minimum. A missing stream-day means no reportable traffic, not a broken record, so do not alert on gaps.
The engagement categories are deliberately opaque. Positive, neutral and negative are left undefined, and the draft states plainly that providers are unlikely to disclose precisely what falls into each one. Cross-provider comparisons will never be apples to apples once a second generator goes live.
Prepare the collection mailbox before the records propagate. Reports arrive as multipart/report messages carrying JSON attachments from an unfamiliar sender, which is close to a description of what aggressive filtering quarantines. Allowlist accordingly, and key your sorting rules off the APRF: subject prefix and the .json attachment rather than the sending address, which will change as other providers come online.
What to do with this now
The only provider currently generating APRF reports is Comcast, whose consumer mailboxes are being moved onto Yahoo's platform through a migration rolling out in phases across 2026. The spec is rough, the categories are fuzzy, the numbers are rounded, and much of the above could change by draft -01.
Nine days of beta data already justified the deployment. One stream in the portfolio deteriorated visibly at Comcast over the collection window, ending on a day when its unwanted value was the highest of any payload we collected while its inbox value sat at the minimum. Nobody had flagged a problem on either side yet. Rounded, single-provider, beta-quality data still got there first.
Publish the records anyway. The marginal cost is a DNS loop you can script in an afternoon, and the payoff is placement data derived from real recipient behaviour, which is the thing this industry has spent twenty years approximating, plus standing to comment while the format is still being written. DMARC was deployed at scale long before it was an RFC, and the senders who understood it early spent years ahead of the ones who waited for it to be finished. For most organizations the harder question is not whether to publish the record but whether their authentication and mail stream separation are in a state where the resulting data means anything.
What is documented above is nine days of collection. The follow-up post will cover the longer time series: whether any value ever appears between 800 and 2000 or above it, which would map the bucket boundary properly, how placement shifts track against real sending changes, and whether the engagement signal correlates with anything measurable on the sending side.
SH Consulting deploys and monitors authentication, reporting, and DNS security across large client portfolios, including early standards work like this one. If you want APRF collection set up properly alongside your existing DMARC reporting, book a call or read more about how we work at www.sh.consulting.
