Feedback loops and ARF: receiving complaints from recipients

When a recipient clicks "Report spam", some mailbox providers forward that signal to the sender. The circuit is called a feedback loop (FBL), and the standardised format of the reports is ARF (Abuse Reporting Format). For a sender, it is the only direct source of information about what recipients think of the mail they receive.

What a feedback loop is#

An FBL is an agreement between a mailbox provider and a sender: the provider undertakes to send a report for every complaint from one of its users to an address designated by the sender. The sender, implicitly, undertakes to unsubscribe the complainant and stop writing to them.

FBLs were introduced by AOL in the early 2000s and later adopted by Yahoo, Microsoft, Comcast and many other operators. Google is the exception: Gmail does not return a report per complainant but provides an aggregated complaint rate in Postmaster Tools, so as not to expose the identity of its users.

Providers that offer an FBL generally ask for:

• a dedicated receiving address (fbl@sender.net, for instance);
• proof of control over the IPs or domains concerned, often through DKIM validation of the signing domain;
• in some cases, enrolment through a third party that centralises requests across several providers.

The ARF format#

ARF, defined by RFC 5965, is a MIME message of type multipart/report made of three parts:

1. a human-readable part (text/plain) describing the report;
2. a message/feedback-report part carrying structured fields;
3. a copy of the original message, either complete or reduced to its headers (message/rfc822 or text/rfc822-headers).

A simplified report looks like this:

From: feedback@provider.example
To: fbl@sender.net
Subject: Abuse report for message 4F3A2B1C
Content-Type: multipart/report; report-type=feedback-report;
  boundary="=_arf_boundary"

--=_arf_boundary
Content-Type: text/plain; charset=utf-8

This is an email abuse report for a message received from
203.0.113.10 on Wed, 1 Oct 2026 09:14:22 +0000.

--=_arf_boundary
Content-Type: message/feedback-report

Feedback-Type: abuse
User-Agent: provider-fbl/1.0
Version: 1
Original-Mail-From: <bounce-42@sender.net>
Original-Rcpt-To: <recipient@provider.example>
Arrival-Date: Wed, 1 Oct 2026 09:14:22 +0000
Source-IP: 203.0.113.10
Reported-Domain: sender.net
Authentication-Results: mx.provider.example; dkim=pass header.d=sender.net

--=_arf_boundary
Content-Type: message/rfc822

[copy of the original message, often with the recipient address redacted]
--=_arf_boundary--

The Feedback-Type field takes the values abuse (a user complaint, by far the most common), fraud (phishing), virus, not-spam (the user moved the message out of the spam folder) or other. The complainant's address is often replaced by an anonymised string, which is why the sender must embed a unique identifier in every message (an X-Campaign-ID or Feedback-ID header, or an identifier in the return path) so that the recipient and the campaign can be traced back.

How to handle a complaint#

Processing must be automatic and immediate:

1. Extract the unique identifier from the original message attached to the report.
2. Find the recipient and mark them as unsubscribed across every list of the domain, not only the list used by that campaign.
3. Record the complaint with its date, the reporting provider, the campaign and the sending IP.
4. Compute the complaint rate per campaign and per provider: complaints divided by messages delivered to the inbox.

The 2024 requirements from Google and Yahoo set a threshold: the complaint rate must stay below 0.3% and ideally below 0.1%. Beyond that, the provider downgrades the reputation of the domain or IP, or refuses the traffic outright. An abnormal complaint rate on a single campaign usually points to a list segment, a misleading subject line or an excessive frequency.

What to check#

• FBLs are enabled with every provider that offers one, for every DKIM signing domain and every IP range.
• The address receiving reports is monitored by a program, not a mailbox read by hand.
• Every outgoing message carries an identifier that leads back to the recipient despite anonymisation.
• The List-Unsubscribe and List-Unsubscribe-Post headers (RFC 8058) are present: a recipient who finds the unsubscribe button does not use the spam button.
• The volume of reports received is consistent with the volume sent; complete silence from a provider often means an expired enrolment.

Common mistakes#

• Unsubscribing only from the campaign instead of all mail from the domain.
• Replying to the ARF report or writing to the complainant to "understand": the address is anonymised and the approach makes things worse.
• Forgetting to renew the enrolment after a change of IP or DKIM domain.
• Reading the absence of Gmail reports as an absence of complaints.
• Treating not-spam reports as complaints and unsubscribing a recipient who has just rescued the message from the spam folder.

A well-handled ARF stream is the earliest warning signal a sender has: complaints arrive within minutes, long before reputation visibly degrades.