A new standard could finally show you where your cold email actually lands

Every sender who has ever stared at a healthy Google Postmaster Tools dashboard while their reply rate quietly collapses knows the actual problem with cold email deliverability: authentication tells you almost nothing about placement. You can pass SPF, DKIM and DMARC on every single message and still not know whether that message landed in the inbox, the spam folder, or got silently dropped after acceptance. A new Internet-Draft submitted to the IETF in March 2026, and picked up by deliverability trade coverage in July, proposes to close exactly that gap — and one major mailbox provider is reportedly already running it.

What APRF actually is

The draft is called Aggregate Performance Reporting, or APRF, and it comes from three named authors with real mailbox-provider and sender-platform affiliations: Alex Brotman of Comcast, Tom Corbett of Iterable, and Emil Gustafsson of Google. The mechanism is deliberately modeled on something senders already understand — DMARC aggregate reporting:

• A sending domain publishes a DNS TXT record opting in and naming a reporting address, the same shape as a DMARC rua tag.
• A mailbox provider that supports APRF and has feedback to share sends back a periodic — proposed as daily — aggregated report.
• Report delivery uses DKIM as the discovery and authenticity mechanism, so a receiving domain can trust the report actually came from the mailbox provider it claims to.

What’s inside the report is the part that matters. Two buckets of data get reported back: classification (how many of your messages the mailbox provider routed to the inbox versus the spam folder) and engagement (aggregated counts of positive signals, like a recipient pulling a message out of spam or marking a sender as safe, and negative signals, like spam complaints, unsubscribes, and delete-without-open). None of that is currently visible to senders in any standardized, machine-readable form. Every mailbox provider that offers any visibility today — Google Postmaster Tools, Microsoft’s SNDS, Yahoo’s Sender Hub — does it through its own proprietary dashboard, in its own format, on its own schedule. APRF is an attempt to make that a pull-based, DMARC-shaped feed instead: one format, one discovery mechanism, queryable the same way regardless of which provider is sending the report.

Why this gap has lasted so long

It’s worth asking why nothing like this already existed, given how badly senders have wanted it. The honest answer is that mailbox providers generally see spam-filtering and reputation-scoring logic as competitive, adversarial information — the more precisely a sender can see how a filter scores them, the more precisely a spammer can see how to route around it. DMARC succeeded as a shared standard because authentication is not adversarial in the same way: a mailbox provider loses nothing by telling you clearly whether your SPF and DKIM aligned. Telling you exactly why a specific message got folder-routed is a different kind of disclosure, and it’s the reason Postmaster Tools gives you a coarse “low / medium / high” verdict on spam rate rather than a per-message reason code.

APRF doesn’t try to solve that — it stays deliberately aggregate and delayed (daily reports, not real-time, not per-message), which is likely a design choice specifically to avoid handing spammers a live feedback loop for A/B testing filter evasion. That’s also why Comcast, a residential ISP with a comparatively contained mailbox base, is a plausible first mover in a way that a filtering giant processing hundreds of billions of messages a day might not be for years, if ever.

How it compares to what already exists

None of this is happening in a vacuum — mailbox providers have offered some form of sender-facing feedback for years, just never in a shared, standardized shape. Laying APRF’s proposed design next to what’s already out there makes clear what gap it’s specifically trying to close:

	Google Postmaster Tools	Yahoo Complaint Feedback Loop	APRF (proposed)
Format	Proprietary web dashboard	Per-complaint forwarded reports	Standardized aggregate report, DMARC-shaped
Discovery mechanism	Manual domain verification	Manual enrollment	DNS TXT record, self-describing
Placement data (inbox vs. spam)	Coarse verdict only	Not included	Included directly
Engagement data	Limited, aggregate	Individual complaint events only	Aggregated positive and negative signals
Works the same across providers	No — Google-specific	No — Yahoo-specific	Yes, if adopted — one format for any supporting provider

The pattern across every existing option is the same: useful, but locked to one provider’s format, one provider’s login, and one provider’s decision about what to show you. A sender monitoring Gmail, Outlook and Yahoo today is stitching together three fundamentally different data shapes by hand, or paying a platform to do that stitching for them. APRF’s actual pitch isn’t “more data than Postmaster Tools” — Google’s own tooling already tells you plenty about Gmail specifically. The pitch is one format that would, in principle, work the same way regardless of which mailbox provider is on the other end, the same value proposition that made DMARC worth adopting industry-wide instead of every provider inventing its own authentication feedback mechanism.

The DMARC precedent, and why it’s a reasonable but imperfect comparison

It’s tempting to assume APRF will follow DMARC’s adoption curve, since the mechanism is deliberately borrowed from it — but the comparison has a real limit worth naming. DMARC succeeded partly because it solved a problem every party in the ecosystem wanted solved: senders wanted their domains protected from spoofing, mailbox providers wanted less phishing traffic, and neither side had to give up anything competitively sensitive to make it work. Publishing a DMARC policy doesn’t tell a spammer anything useful about how to get past your filter; it just tells legitimate senders whether their own authentication is configured correctly.

APRF sits in a genuinely different position, because placement and engagement data — even aggregated and delayed — is closer to the thing mailbox providers have historically guarded most carefully. A mailbox provider adopting APRF is making a real trade: better sender relationships and cleaner mailboxes, against a small but nonzero risk that even coarse aggregate signal helps a sophisticated bad actor calibrate their sending behavior. That’s a genuinely harder calculation than “should we tell senders if their SPF record is broken,” and it’s the reason nobody should assume APRF’s path to broad adoption will be as fast or as uncontested as DMARC’s was.

What to actually do about it right now

Nothing, operationally — and that’s the correct answer, not a dodge. There’s no APRF DNS record to publish yet in any way that would do something useful, because outside of Comcast’s beta there’s no receiving side to talk to. What’s worth doing instead is treating this the way experienced senders treated early DMARC: understand the shape of it now, so that when a second and third mailbox provider start supporting it, you’re not starting from zero on what the report format even means.

The deeper lesson APRF surfaces, regardless of whether the spec itself ships, is that authentication compliance and inbox placement are genuinely two different problems, and most tooling in this space still conflates them. A domain can be perfectly authenticated — SPF aligned, DKIM signing cleanly, DMARC at p=reject — and still get folder-routed because of engagement signals no aggregate report currently surfaces to the sender in any standard way. That’s precisely the blind spot Norbelys’ DMARC and domain-health monitoring is built to reduce with the signals that are available today — aggregate DMARC reports, bounce and complaint patterns, and reputation trends across the mailboxes you’re actually sending from — instead of waiting for a future standard to arrive.

Frequently asked questions

Is APRF something I need to configure right now?+

No. It's a draft specification with exactly one confirmed receiving implementation (Comcast, in beta). There's nothing to publish or configure yet that would produce a useful signal — treat this as something to watch, not something to deploy.

How is APRF different from DMARC aggregate reports?+

DMARC reports tell you whether your SPF/DKIM authentication passed and aligned — an identity and authentication signal. APRF is designed to report on what happens after authentication succeeds: whether the message was placed in the inbox or spam folder, and how recipients engaged with it. They're complementary, not competing.

Will Gmail or Outlook support APRF?+

Not announced as of this writing. One of the draft's three co-authors is a Google engineer, which suggests genuine internal interest, but Google, Microsoft and Yahoo have not made any public commitment to implement it.

The gap Norbelys is built to close today, not someday

Waiting on a future IETF standard to tell you where your mail lands is not a deliverability strategy — it’s a bet on a timeline nobody controls. What actually moves the needle right now is a domain-health system watching your authentication posture, your bounce and complaint trends, and your sending reputation continuously, on every mailbox you connect, instead of leaving you to reverse-engineer placement from reply-rate anxiety. Norbelys pairs DMARC monitoring with a real warmup ramp for every new sender and automatic suppression handling, so the signals you can see today — the ones APRF is trying to standardize for tomorrow — are already working for you. See your own domain’s health on Norbelys instead of waiting for the industry to agree on a spec.