Will major mailbox providers adopt APRF?
Updated on 2 Oct 2026: We updated the APRF adoption outlook and explained how to read bucketed provider reports.
Some major mailbox providers are likely to test APRF, but broad adoption is not assured. Comcast has produced reports using the proposed format, showing that the idea can operate in a provider environment. Google is represented among the draft authors, but authorship is not a public commitment to deploy it. There is no confirmed APRF rollout from Yahoo, Microsoft, Apple, or Mail.ru.
A likely staged path is limited pilots first, support in sending platforms next, then wider mailbox-provider participation if the reports lead to measurable improvements. The September 2026 revision is still an individual Internet-Draft. The Mail Maintenance working group has issued a call for adoption, but has not adopted it or published it as an IETF standard. Record syntax and report fields can still change.
The proposal matters because it gives senders aggregated information about where DKIM-signed mail lands. Existing coverage of the APRF proposal describes a DKIM-based discovery record and machine-readable reporting. That is more specific than a reputation label, but each provider controls eligibility and data detail.
Where APRF stands today
APRF means Aggregate Performance Reporting. The September 2026 draft defines a report format, a DNS method for discovering the report destination, and delivery by email. The data is tied to a valid DKIM signing domain and selector. A report can describe classification buckets such as inbox, unwanted, forwarded, or promotional, along with aggregated engagement data when a provider chooses to supply it.
It is still work in progress
The current -01 draft remains an individual Internet-Draft even though a working group adoption call has been issued. Treat every current APRF setup as a pilot. Keep the owner, TXT value, selectors, and receiving mailbox documented so a later revision is easy to apply.
That distinction matters when planning resources. A provider can experiment with the format before the IETF adopts it, while a sender can publish a discovery record before many providers generate reports. Early use gives the proposal operational feedback, but it does not guarantee stable interoperability.
How APRF works
A mailbox provider reads the selector and domain from a valid DKIM signature. It then looks for a TXT record at the selector-specific APRF name. A wildcard or a selector-free record can cover multiple selectors, while an explicit selector record takes precedence. The record declares APRF version 1 and at least one email destination for reports.
Draft APRF DNS exampleDNS
Host: sel1._aprf._domainkey.example.org Type: TXT Value: "v=APRFv1;rua=mailto:reports@example.org;"
The draft requires a valid JSON report covering one UTC day. Reports travel by SMTP, with optional gzip compression. A signer-defined identifier (SDI) can divide data by a DKIM-signed header, but providers can ignore that identifier. The segmentation is useful for separating brands or campaigns without exposing recipient-level events.
APRF flow using DKIM, DNS discovery, provider eligibility, and daily reports
If the report address is on a different domain, the draft describes a destination validation record to confirm that address can receive the reports. A provider can also require minimum volume, domain age, acceptable reputation, or another trust signal before reporting. This flexibility is central to both adoption and abuse control.
How to read APRF reports
APRF numbers need context before they become a performance metric. The draft recommends reporting classification counts in buckets and using each bucket's upper bound. A value of 500 can mean the underlying count falls somewhere within a provider-defined range, not that exactly 500 messages reached that category. Providers choose the bucket sizes and can omit classification or engagement data.
- Compare the same provider, DKIM domain, selector, and sending stream over time. Different providers can define categories and buckets differently.
- Treat classification as mail received during the report day. Engagement counts actions during that day, including actions on mail received earlier.
- Do not divide a bucketed inbox count by a bucketed total to publish a precise placement rate. Check volume, complaints, and sending changes before interpreting a shift.
The optional extra_info field can explain a provider's categories or changes to its measurements. Store the report version and provider with each daily report so a definition change is not mistaken for a sender performance change.
Provider adoption outlook
The strongest evidence comes from implementation, not public enthusiasm. Comcast has an experimental feed and uses DNS publication as the sender opt-in. Yahoo and Mail.ru already expose related placement or performance data through their own programs, so they have the underlying data, but that is not evidence that either has adopted APRF.
|
|
|
|---|---|---|
Experimental report feed | Active pilot | |
Draft co-author; no rollout | No commitment | |
Related performance data | No commitment | |
Related performance data | No commitment | |
No public APRF signal | Unknown | |
No public APRF signal | Unknown |
Public signals and practical adoption assessment
Microsoft's high-volume sender rules show that major providers are willing to standardize authentication expectations. APRF asks for a different commitment because a provider must export internal classification data. Authentication enforcement is not evidence of an APRF plan.
Google's involvement in drafting gives the proposal input from a large mailbox operator. Deployment remains a separate product and policy decision.
What will determine adoption
Mailbox providers will adopt APRF only if the benefit exceeds the cost of generating reports, supporting senders, and protecting sensitive filtering information. The format has a starting point because it uses familiar parts of DMARC: DNS discovery, aggregate reporting, destination validation, and email delivery.
- Standards path. The working group adoption call needs a decision, followed by interoperable revisions.
- Operational proof. Pilots must show that senders act on the data and improve recipient outcomes.
- Privacy controls. Aggregation and thresholds must limit recipient or filtering-rule disclosure.
- Consistent meaning. Providers need enough shared classification semantics for cross-provider analysis.
- Easy setup. DNS publication and report processing must be manageable for ordinary teams.
A small number of early providers can still make APRF useful. Large senders often have enough volume at one provider to diagnose changes without universal coverage. Broader value arrives when multiple providers report comparable classifications for the same DKIM domain.
The most likely adoption sequence
Expect controlled provider pilots, ingestion by sending platforms, published implementation experience, and then wider provider decisions. A universal switch-on across major mailbox providers is unlikely.
Will APRF help spammers?
APRF does not have to give spammers useful intelligence. Providers can restrict reports to established senders with sufficient volume and acceptable reputation. They can use coarse buckets, omit engagement fields, and suppress low-count segments. Those controls limit the value of the feed for repeated filter testing, although providers still need to assess abuse risk.
Reasons to publish
- Correction. Legitimate senders can find damaging changes sooner.
- Accountability. Aggregates connect sending choices with recipient outcomes.
- Automation. JSON reports can feed existing analysis pipelines.
- Scale. One format reduces provider-specific integrations.
Reasons to restrict
- Gaming. Fine-grained feedback can support repeated filter testing.
- Privacy. Small segments can expose recipient behavior.
- Support. Senders will ask providers to explain every movement.
- Cost. Daily generation and delivery require infrastructure.
The real security question is granularity. A daily count in broad placement buckets is different from immediate message-level feedback. Cautious providers can begin with the former, apply eligibility thresholds, and expand fields only after measuring abuse risk.
A practical APRF eligibility model
Providers can vary access and detail according to established trust signals.
Established sender
Full aggregate
Stable identity, useful volume, and acceptable reputation
New or low-volume sender
Limited
Too little data for privacy-safe or reliable classification
Abusive sender
No report
Poor reputation or suspicious behavior
Unknown sender
Deferred
Insufficient history for a trust decision
These are policy examples, not fixed APRF requirements. Each provider can set its own thresholds, which is useful for safety but can make coverage inconsistent.
Should APRF appear in postmaster tools?
Postmaster portals should display APRF-derived summaries, but the standardized machine feed should remain the primary transport. A portal helps a person investigate a sudden change. The feed lets a sender or service provider collect daily reports across domains and providers without manual exports.
Google Postmaster Tools dashboard with sender reputation and delivery metrics
The best implementation pattern has both layers. APRF supplies the portable data, while portals explain provider-specific classifications, eligibility rules, and report delays. Sending platforms can then translate the raw counts into changes a customer can act on.
A portal alone would limit APRF
If every provider keeps the data inside a separate interface, teams still face different access controls, retention periods, and exports. A shared report format makes cross-provider automation possible.
Providers should avoid promising identical labels. One provider's promotional category and another provider's inbox category can use different decision systems. The common format should carry enough metadata to prevent false comparisons.
APRF does not replace DMARC
APRF and DMARC answer different questions. DMARC aggregate data shows which systems sent mail using a domain and whether SPF or DKIM aligned. APRF aims to show aggregate performance after a mailbox provider accepts DKIM-signed mail. A message can pass DMARC and still land outside the inbox.
DMARC reporting
Use it to identify sending sources, measure alignment, find spoofing, and move policy safely toward enforcement.
APRF reporting
Use it to compare aggregate placement or engagement classifications for eligible DKIM-signed traffic.
Provider participation also differs. The list of organizations sending authentication reports is already broad, although coverage and detail vary. The practical background on DMARC report coverage helps set expectations for a future APRF rollout: a standard can be valuable well before every provider supports it.
Keep authentication monitoring in place regardless of APRF progress. Incorrect DKIM signing or selector management can prevent both DMARC alignment and APRF discovery, so the foundation matters twice.
What senders should do now
There is no need to wait for universal adoption. Start by making the sending identity clean enough that an APRF pilot will produce attributable data. Stable DKIM domains and selectors are more important than publishing a speculative record for every stream.
Use this preparation sequence:
- Inventory. Map every DKIM signing domain and selector to its sending stream.
- Validate. Confirm SPF, DKIM, and DMARC pass with correct domain alignment.
- Assign. Choose a monitored report mailbox with an accountable owner.
- Pilot. Publish APRF only for a stable selector accepted by a participating provider.
- Compare. Review trends after controlled changes, not isolated daily movements.
Run a domain health check before any APRF pilot. It catches missing or malformed authentication records that would make performance data harder to interpret.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
For focused validation, the DMARC checker confirms the published policy and reporting destinations. These checks do not predict inbox placement, but they remove authentication ambiguity before APRF data arrives.
Suped's DMARC monitoring helps teams check sending sources, SPF and DKIM alignment, and policy changes before an APRF pilot. Keep an owner on authentication alerts and review APRF classifications separately when a provider sends them.
Keep APRF data logically separate from DMARC data even if both appear in one reporting workflow. Authentication results explain identity and alignment. APRF classifications explain provider outcomes. Combining the analysis is useful; merging the meanings is not.
Views from the trenches
Best practices
Publish APRF records only after confirming DKIM selectors and report mailbox ownership.
Keep provider data separated by DKIM domain so placement changes remain attributable.
Store daily reports long enough to compare changes after each controlled sending adjustment.
Common pitfalls
Treating a beta feed as universal truth hides provider-specific classification differences.
Using one shared DKIM selector removes the segmentation needed for useful diagnosis.
Assuming APRF replaces DMARC leaves authentication failures and spoofing exposure unseen.
Expert tips
Start with one trusted sending stream, then validate report volume before adding selectors.
Document every DNS change because draft syntax and provider behavior can change quickly.
Compare APRF placement with complaints and campaigns, but avoid inferring individual actions.
Marketer view
Marketer from Email Geeks says APRF remains an individual draft, so adoption discussions should not treat it as an approved standard.
2026-07-20 - Email Geeks
Marketer view
Marketer from Email Geeks says providers can restrict APRF by sender age, reputation, volume, or other eligibility thresholds.
2026-07-20 - Email Geeks
What to watch next
The Mail Maintenance working group adoption call is the next standards milestone. A decision to adopt the draft would still leave technical review and implementation work ahead. Comcast's experimental feed remains the clearest provider signal, while Google's participation in the draft is not a rollout promise.
Prepare the parts you control: stable DKIM identity, clean DMARC alignment, documented DNS ownership, and a report-processing plan. If more providers join, those foundations allow a quick pilot. If adoption stays limited, the same work still improves authentication diagnosis and operational control.
