Email Feedback Loops (ARF): How to Keep Complaint Rates Low

An email feedback loop (FBL) is a service where a mailbox provider notifies the sender each time a recipient marks a message as spam, usually as an Abuse Reporting Format (ARF) report defined in RFC 5965. You use those reports to stop mailing people who complained and to find which campaigns, segments or sources generate complaints. Keeping complaint rates low matters because they are one of the strongest reputation signals: according to Google's sender guidelines, the user-reported spam rate should stay below 0.1% and never reach 0.3%.

How feedback loops work

When a user clicks "Report spam" or "Junk", the provider records it as a reputation signal. If you are registered for its feedback loop, the provider also sends you a report, typically within minutes.

Registration differs by provider:

• Yahoo: the Complaint Feedback Loop, registered through Yahoo Sender Hub, keyed on your DKIM signing domain.
• Microsoft: the Junk Mail Reporting Program (JMRP), registered per IP, alongside SNDS data for those IPs.
• Many regional and ISP providers: run their own programs, often keyed on IP; registration processes vary.
• Gmail: no per-message reports. Google offers an aggregate feedback loop based on a Feedback-ID header and shows the overall spam rate in Postmaster Tools.

Because Gmail is often the largest share of a list, you cannot rely on ARF reports alone to see your complaint rate. You need Postmaster Tools too.

Anatomy of an ARF report

An ARF report is a multipart/report message with report-type=feedback-report:

From: feedback@fbl.example.net
To: fbl@bounces.example.com
Subject: FW: Weekly digest
Content-Type: multipart/report; report-type=feedback-report; boundary="ARF"

--ARF
Content-Type: text/plain

This is an email abuse report for an email message received from IP 203.0.113.10.

--ARF
Content-Type: message/feedback-report

Feedback-Type: abuse
User-Agent: ExampleFBL/1.0
Version: 1
Original-Mail-From: <b-7f3k9q2xv1@bounces.example.com>
Arrival-Date: Mon, 12 Oct 2026 14:03:20 +0000
Source-IP: 203.0.113.10
Reported-Domain: example.com

--ARF
Content-Type: message/rfc822-headers

From: Example <news@example.com>
To: <redacted>
Message-ID: <01HZX4Q7M2@mail.example.com>
X-Example-Recipient: 01HZX4Q7M2
--ARF--

Key fields from RFC 5965:

• Feedback-Type: abuse for spam reports; other values include fraud, virus and not-spam.
• Original-Mail-From: the envelope sender. If you use VERP, this alone identifies the recipient.
• Source-IP and Arrival-Date: which IP sent it and when.
• The third part contains the original message or its headers.

Many providers redact the recipient address for privacy. RFC 6590 describes this redaction. That is why you must embed your own identifier: a VERP return-path, a custom header with an opaque recipient ID, or both. A message you cannot map back to a recipient is a complaint you cannot act on.

What to do with each complaint

1. Suppress immediately for all non-transactional streams. The person told you, in the strongest available way, that they do not want this mail. Sending again generates another complaint.
2. Record context: stream, campaign, template, signup source, signup date, last engagement.
3. Do not suppress transactional mail automatically without thought: users sometimes report a receipt by mistake, and blocking security alerts can cause harm. Flag it for review instead.
4. Emit an event so your application, CRM and marketing tool all agree.

Measuring complaint rate correctly

The naive formula is complaints divided by messages sent, but the details matter:

• Measure per provider. Yahoo complaints divided by messages delivered to Yahoo, not your total volume.
• Remember Gmail's denominator. Postmaster Tools computes spam rate against mail delivered to the inbox. If much of your mail already lands in spam, people cannot report it, and the rate looks deceptively low.
• Measure per stream and campaign. A blended rate hides a problem campaign behind high-volume transactional mail.
• Watch trends, not single days. Small sends produce noisy rates.

Why people complain, and how to reduce it

They do not remember signing up

• Use confirmed (double) opt-in for marketing lists.
• Send a welcome message right after signup, when the person remembers you.
• Use a recognizable From name and address, consistent across messages.

Unsubscribing is harder than reporting spam

• Support RFC 8058 one-click unsubscribe, so the client shows a native unsubscribe button next to the sender name.
• Put a clear unsubscribe link in the body, not hidden in tiny gray text.
• Never require a login to unsubscribe.

The mail is not what they expected

• Match frequency to what was promised at signup.
• Offer a preference center with a "less often" option.
• Keep content aligned with the reason they subscribed.

The list has aged

• Run a sunset policy: stop sending to people who have not engaged for a long period, after a last re-permission attempt.
• Never mail purchased, rented or scraped lists. M3AAWG's sender best practices are unambiguous about permission.

Sudden spikes

A spike usually points to one cause: a segment that had not been mailed in a long time, an imported list, a change in frequency, or a misleading subject line. Compare complaint rates by segment for the affected send.

Automatic safeguards

Complaints compound quickly. A useful safety net is an automatic guard: if the complaint rate for an account or stream crosses a threshold over a rolling window, pause sending and alert someone before the provider's reputation system reacts. A paused campaign costs hours; a damaged domain reputation can take weeks to recover.

Common mistakes

• Not registering for FBLs, then wondering why complaints are invisible.
• No recipient identifier in the message, so redacted reports cannot be matched.
• Relying on ARF only and ignoring Gmail's Postmaster Tools.
• Calculating against total sends instead of per provider.
• Keeping complainers on the list because "they might buy something".
• Hiding the unsubscribe link.

Checklist

• [ ] Registered for Yahoo CFL, Microsoft JMRP and other available FBLs
• [ ] Domain verified in Google Postmaster Tools
• [ ] VERP or opaque recipient ID in every message
• [ ] ARF parser routing complaints to suppression within minutes
• [ ] Complaint rate tracked per provider, stream and campaign
• [ ] One-click unsubscribe and visible unsubscribe link
• [ ] Automatic pause above a complaint threshold

Pidgely processes ARF reports from feedback loops, matches them to recipients through VERP, suppresses complainers automatically and pauses an account through its reputation guard when complaint rates cross safe thresholds.