Published 5 November 2026 · By Bram Van Daele, Teneo
Complaint feedback loops started as a courtesy between mail operators, were hosted for years by one company, and for most providers became a paid service in September 2023. Since then several proposals have tried to give senders back a direct line to the people who mark their mail as spam. The newest, APRF, became an IETF working group document in October 2026. We follow the line from ARF to APRF, look at what each step gives a sender, and explain how a relay reads these signals for many customers at once.
Anyone who ran outbound mail around 2010 will remember the routine. For every mailbox provider that offered a feedback loop you filled in a form, listed your IP ranges, proved you controlled them, and waited. When it worked, a copy of every message a recipient had marked as spam came back to you, and you removed that address from the list. It was tedious, and it was one of the most useful things a sender had.
The newest proposal in this field, APRF, is one letter longer than the format those reports used. The letter it adds is a P, for performance, and that letter says a lot about how the conversation has changed. To see why, it helps to walk the road from the beginning.
The early loops and ARF
A feedback loop is a channel through which a mailbox provider tells a sender that a recipient pressed the report-spam button. RFC 6449, the operational recommendations for complaint feedback loops published in November 2011, names AOL's "scomp" system as the first deployed loop. It sent the sender a full copy of the message the user complained about. The RFC does not give a year, only that loops had been running for more than a decade by the time it was written.
For most of that decade every provider used its own report format. That ended in August 2010, when RFC 5965 defined the Abuse Reporting Format, ARF, as a Proposed Standard. RFC 6449 followed the year after with the practical side. It asked providers to redact private data, verify who applied and automate enrolment, and it asked senders to treat a complaint like an unsubscribe and to put a recipient identifier in each message, for instance in the Message-ID, so that a redacted report could still be matched to a list entry.
What stayed manual was registration: per provider, per IP range, and at Yahoo per domain. Most of what followed tried to remove that step.
When one company held most of the keys
On 7 July 2011 Return Path announced feedback loop services for Synacor and FastMail, and said it now hosted and managed 10 of the 13 public complaint loops. For senders this was convenient. One relationship replaced a dozen forms. In July 2018 Al Iverson reported on Spam Resource that Return Path had gone a step further with a Universal FBL: one signup and one configuration for 18 loops.
Convenience had a side effect that was easy to overlook at the time. The loops of many smaller providers now ran through one commercial intermediary. Validity announced its acquisition of Return Path on 1 May 2019 and completed it on 31 May. In a blog post of 30 August 2023 Validity announced changes to the feedback loop service that took effect on 21 September 2023. Since then the loops Validity hosts are a paid service, and customers of Validity's paid products keep their access. Validity itself wrote that the announcement had raised discussion in the market, which was a polite way of putting it.
The M3AAWG resources page on feedback loops, which carries no date, still describes the Universal FBL as the way to reach most of the loops it lists. We could not confirm that each of those loops still delivers today.
What a sender still gets, per message and for free
Two large providers were never part of that arrangement. Yahoo runs its complaint feedback loop from Sender Hub, keyed to a domain enrolled with DKIM, and it covers AOL and Verizon addresses as well. Microsoft runs its Junk Mail Reporting Program, JMRP, directly and alongside SNDS. In his September 2023 overview Iverson described both as separate from Validity and free of charge. We have not re-read Microsoft's current JMRP terms for this article, so check the SNDS pages before you rely on them.
Gmail never offered a per-message loop. What Google offers is aggregate: you add a Feedback-ID header, sign it with DKIM using a domain verified in Postmaster Tools, and the dashboard shows spam rates per identifier. It covers gmail.com recipients only, and an identifier appears only once it has enough volume and enough distinct users reporting it, as Google's help page on the header explains.
Put together, a sender in 2026 gets individual complaints from Microsoft and Yahoo, a statistical view from Google, and for many smaller providers a feed that now comes with an invoice.
CFBL: let the message say where complaints should go
In September 2023, the same month Validity's change took effect, the RFC Editor's Independent Submission stream published RFC 9477, "Complaint Feedback Loop Address Header", written by Jan-Philipp Benecke of CleverReach. The idea is simple enough to explain in one breath. The sender adds a CFBL-Address header to the message, and optionally a CFBL-Feedback-ID, covers both with its DKIM signature, and a provider that supports the RFC mails its ARF or XARF reports to that address. There is no registration with anyone.
The timing invites a story that the record does not support. The draft goes back at least to draft-benecke-cfbl-address-header-07 of 15 June 2022, more than a year before Validity's announcement, and its stated motivation is that manual registration is slow, impractical for small providers and has to be redone whenever an address changes. The two events landed in the same month, but one did not cause the other.
RFC 9477 is Experimental and defines its own success as independent implementations by several parties. We have not found a mailbox provider that acts on the header.
We asked Jan-Philipp Benecke how he sees it now. He started on CFBL because he "felt there was a gap in how mailbox providers and senders exchanged feedback", and the aim was "never to reinvent the wheel, but rather to see if we could improve on existing mechanisms". On adoption he is frank: "There's also a bit of a chicken-and-egg problem: senders need providers to adopt it to make it useful, while providers need to see sufficient demand from senders." He points to use outside the mailbox providers, though. Abusix uses CFBL headers in its service, and the Certified Senders Alliance has included CFBL in its recommendations for senders.
A second route, draft-brotman-dkim-fbl, would let a provider find the report destination through the DKIM signature itself. The MAILMAINT working group marked it a candidate for adoption on 8 August 2024. Its latest version, -06, is dated 6 January 2026 and has since expired, and the datatracker still lists it as a candidate. In July 2026 John Levine noted on the ietf-dkim list that the DKIM2 draft carries feedback flags but does not yet define what the feedback would contain.
APRF: the letter P
The first APRF document, draft-brotman-aggregate-performance-reporting-00, is dated 17 March 2026. Its authors work at Comcast, Iterable and Google, with a fourth author listed independently. The adoption call on the MAILMAINT list ran from 24 September to 8 October 2026, the working group version was announced on 9 October, and draft-ietf-mailmaint-aprf-01 is dated 31 October. It is on the Standards Track and still a draft.
If you know DMARC aggregate reports, the mechanism will look familiar. The sender publishes a TXT record at <selector>._aprf._domainkey.<domain> with v=APRFv1 and a rua=mailto: address, for a selector it signs with. A provider that takes part sends one JSON report per UTC day, by email, for each signing domain and selector. The report counts where the mail landed, inbox or unwanted, and how recipients engaged with it, positively, neutrally or negatively. The draft recommends rounding the values into buckets and suggests a minimum volume before anything is reported, both for privacy. An optional sdi tag names a DKIM-signed header whose value splits the report into segments.
As far as we can verify, one provider sends today: Comcast, as a beta for comcast.net. Iverson published a sample report in July 2026, and an open-source reader is available on GitHub. In that beta the counts come in steps of 100 and there is no segmentation. Google has an author on the draft, but we found no statement that Gmail will send reports, and no commitment from Microsoft, Yahoo or Apple.
Iverson has since wired the Comcast reports into the statistics page of his own mail, at wombatmail.com/stats. When we asked him about it, he regretted that his own Comcast segment is too small to give much data, and put the larger point plainly: "It's fun to see, but in the long term, of course, we need to see more MBP support beyond just Comcast."
What the P gives, and what it leaves out
ARF was about one message and one person who did not want it. APRF is about a day of mail from one selector and how it performed. That is a real gain. A sender gets, in a standard format and without registering anywhere, a view of inbox placement at a provider that until now only that provider could see.
What APRF does not carry is the complaint itself. It has no complaint metric and no per-message data. Marking as spam appears in the draft only as one example of negative engagement, and providers may keep their exact category definitions to themselves. The draft does not mention ARF or feedback loops at all. From an APRF report a sender learns that something is wrong with a stream at a provider. It does not learn which address to stop mailing.
In that sense APRF sits next to Gmail's Feedback-ID rather than next to the old loops. Both report in aggregate, and neither tells you who complained. Benecke draws the same line between his own work and the new draft: CFBL "was primarily about providing a standardized way for mailbox providers to share feedback with senders", while APRF "takes a somewhat different approach, looking at feedback and reputation from a broader perspective".
How a relay reads these signals
For a relay every signal starts with one question: which customer does this belong to? Yahoo's loop is keyed to the DKIM domain. Gmail's Feedback-ID carries an identifier we can set per customer. JMRP is keyed to IP addresses, so the mapping goes through the address the message left from, which is one more reason we give every customer dedicated IPs.
APRF is keyed to the DKIM selector, and that fits a per-customer setup without extra work. The catch is where the reports go. When a relay signs with the customer's own domain, which is how it should be, the record lives in the customer's DNS and the reports go to the customer. The relay, which is the party watching the IP addresses, the queues and the trend across all providers, sees nothing unless the customer adds the relay's mailbox to the record.
The draft allows exactly that. The rua tag takes more than one address, so a customer can send the reports to its own mailbox and to the relay's at the same time. Because the relay's address sits in a different domain from the DKIM signature, the draft says the provider SHOULD first check that the relay agrees to receive them, through a record of the form <selector>.<DKIM domain>._aprf.<report domain> with the value v=APRFv1, in the same spirit as the external destination check DMARC uses for aggregate reports. The selector and domain parts may be a wildcard, so a relay can publish one record that accepts reports for all of its customers. That section of the draft still carries a "TODO" for its formal grammar, so the exact form may change. The sdi tag could split a selector further, but providers may ignore it, and Comcast's beta does.
For a relay, complaint feedback is more than list hygiene. A sudden run of complaints for one customer is usually the first sign that something changed on their side, a bought list, an abused signup form, a campaign sent to an old export, and it often shows before any blocklist reacts. At Teneo the individual complaints we act on still come mainly from Microsoft and Yahoo, and when they point at a problem, a person contacts the customer before anything else happens. An aggregate report cannot play that role on its own. It tells us where to look and how fast things are moving. The complaint tells us what to do. Reading the APRF draft's privacy section, we also expect low-volume senders to receive thin reports or none at all, although we have not seen that in practice yet.
What you can actually do
Register for the loops that exist. Yahoo's complaint feedback loop in Sender Hub and Microsoft's JMRP with SNDS still deliver individual complaints directly from the provider.
Sign with a domain you control and a selector you can name. Yahoo's loop, Gmail's Feedback-ID and APRF all depend on a stable d= and s=. One selector per mail stream or per customer keeps later reports readable.
Add a Feedback-ID and verify the domain in Postmaster Tools. Google's help page lists the volume conditions under which data appears.
Treat a complaint as an unsubscribe. RFC 6449 said so in 2011 and nothing since has changed that. Put a recipient identifier in each message so that a redacted report from any source can still be matched to a list entry.
Weigh the paid loops against your own mix. Look at how much of your mail goes to providers that sit behind Validity's service. For some senders that share is small, for others it is their main market.
Treat CFBL and DKIM-FBL as optional. A CFBL-Address header is covered by DKIM and should be ignored by providers that do not know it. Do not expect reports until a provider announces support.
Watch APRF without building around it. Publishing a TXT record and receiving one JSON mail a day costs little, and the Comcast beta can be read today. If an ESP or relay sends on your behalf, consider listing its report address next to your own in rua, so that the party watching your sending sees the same numbers you do. The draft sets no requirement and no deadline, and details such as tag names and the report schema may still change between versions.
The longer view
Feedback started as something operators did for each other. It became a hosted service, then a product. The proposals since 2022 share one idea: the sender publishes where feedback should go and leaves it to the providers to answer, without forms and without an intermediary. Each one takes away a different part of the old arrangement, the registration, the hosting or the question of who complained, and none of them yet brings back the individual complaint for the providers that no longer send it for free.
Whether any of this gets adopted is up to the mailbox providers. APRF has a working group, a large provider among its authors and a live beta, which is more than the earlier proposals managed. That should not be read as a contest, though. A complaint loop such as CFBL tells a sender which recipient to stop mailing. APRF tells a sender how a stream is performing at a provider. Those are different questions, a sender needs the answer to both, and the outcome to hope for is that providers adopt both. Benecke describes the common ground well: "we're moving in the right direction as long as we're working towards more transparency, interoperability, and meaningful feedback for senders." We run SMTP relays at Teneo, on EU infrastructure, and these are the signals we read every day, so we will keep following the road.
Frequently asked questions
Is APRF a replacement for feedback loops?
No. APRF reports aggregate placement and engagement per DKIM selector, with no per-message data and no ARF. A feedback loop tells the sender about individual complaints, so that the address can be suppressed.
Which mailbox providers send APRF reports?
Comcast runs a beta for comcast.net. Google has an author on the draft, but we found no statement that Gmail will send reports, and none from Microsoft, Yahoo or Apple.
Sources: RFC 5965, RFC 6449 and RFC 9477, and draft-benecke-cfbl-address-header-07, on the IETF datatracker; draft-ietf-mailmaint-aprf-01, draft-brotman-aggregate-performance-reporting-00 and draft-brotman-dkim-fbl on the datatracker; the MAILMAINT list archive and a July 2026 message by John Levine on the ietf-dkim list; Google's help page on the Feedback-ID header; Validity's announcements of 1 May and 31 May 2019 and its blog post of 30 August 2023; the M3AAWG feedback loop resources page; Spam Resource posts by Al Iverson (July 2018, September 2023, July 2026) and a Digital Commerce 360 report of 11 July 2011, cited as dated community and press reports. Al Iverson's comments are quoted with his permission from a conversation with the author on 4 November 2026; Jan-Philipp Benecke's comments come from his written answers of 5 November 2026 and are quoted with his approval. Covers events up to 4 November 2026; drafts can change between versions.