# Complaint Feedback Loops (RFC 6449)

> How mailbox-provider feedback loops (FBLs) work — ARF report structure, enrollment and vetting, and operational recommendations for feedback providers and senders.

Source: emailmarketing.net — https://emailmarketing.net/learn/list-management/complaint-feedback-loops

When a recipient clicks "Report Spam" on your message, a feedback loop (FBL) can send you a report of that complaint, so you can stop mailing that person and find out what went wrong. Complaints are one of the main reputation signals that mailbox providers measure (see [Foundations of Email Deliverability](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability)), and an FBL gives you direct access to that signal.

RFC 6449, "Complaint Feedback Loop Operational Recommendations", describes how mailbox providers forward these complaints to senders. Its stated aim is "to provide Feedback Consumers with information necessary to mitigate Spam or the perception of Spam."

## Terminology

| Term | Meaning |
|---|---|
| **Spam** (in the context of FBLs) | Any message the recipient chooses to complain about, whatever the author intended |
| **Feedback Provider** | The organization that sends complaint reports, typically a mailbox provider |
| **Feedback Consumer** | The organization that receives the reports: the sender of the message, or an ESP or ISP acting for it |
| **ARF** | Abuse Reporting Format, the standard report format (RFC 5965) |

## How a complaint becomes a report

1. The user clicks "Report Spam" in the webmail interface or in the provider's mail client. If the provider offers no such button, an effective FBL is practically impossible.
2. The provider matches the message to an enrolled Feedback Consumer. Traditionally it uses the **IP address of the last hop** that handed the message to the provider, and more and more often the **DKIM `d=` domain**.
3. An ARF report is generated and sent **immediately, without review**, so the consumer receives it almost in real time.

### FBL routing by DKIM domain or by IP address

A single DKIM `d=` value can cover many servers and IP addresses, and you can add or remove servers without changing the FBL registration ("when a Feedback Loop uses DKIM, no reconfiguration is necessary because the signing domain does not change"). FBLs based on IP addresses must be updated whenever the sending infrastructure changes. Prefer enrollment by DKIM domain where the provider offers it. It also fits naturally with [DMARC alignment](https://emailmarketing.net/learn/authentication/dmarc) and with separate signing domains for each stream (see [Advanced IP Segmentation](https://emailmarketing.net/learn/ip-management/advanced-ip-segmentation)).

How enrollment works, according to M3AAWG's page of FBL resources: signing up by domain requires the mail to be signed with DKIM, and asks for both the signing domain (the `d=` value) **and the selector (the `s=` value)** from the DKIM signature. The selector used on production mail must therefore be known and stable when you enroll.

Aggregated FBLs work differently. They total complaint counts by IP address, by domain, **or by an identifier the sender chooses**, which is the pattern Gmail implements with the `Feedback-ID` header (see [Google Postmaster Tools](https://emailmarketing.net/learn/postmaster-tools/google-postmaster-tools)). The directory of signup pages for each provider is kept in [M3AAWG Document Index & FBL Ecosystem](https://emailmarketing.net/learn/industry-best-practices/m3aawg-document-index). Most traditional FBLs run through Validity's Universal Feedback Loop at fbl.validity.com.

## ARF report structure (RFC 5965)

An ARF message is a MIME `multipart/report` message with three parts:

| Part | Content |
|---|---|
| 1. Text for people to read | Standard wording that explains the report, and the provider's contact information |
| 2. Metadata for machines to read (`message/feedback-report`) | The protocol version, the report type (`abuse`, `fraud`, …), the envelope sender (optional), and the time the message was received |
| 3. Original message (`message/rfc822`) | A copy of the email that was reported. It is often **redacted**, especially the recipient's address, for privacy or legal reasons |

Because the recipient's address is often redacted, senders **cannot rely on the To: address** in the returned message to identify who complained (see Automation below).

## Recommendations for feedback providers (mailbox providers)

- **Application and vetting:** keep the application process simple, and verify that the applicant is authorized for the IP addresses or domains it claims. Check IP ownership against the origin ASN, WHOIS or RWHOIS records and reverse DNS. Verify contacts with a confirmation message sent to `abuse@` or `postmaster@`.
- **Refusal:** you may refuse an application when the applicant appears to be enrolling falsely to get around delivery policies, or is already blocked for a bad reputation. Keep a documented, transparent appeals process.
- **Report contents:** include a contact address for questions (ideally one that feeds a ticketing system). You may also include summary delivery statistics (volume, inbox rate, spam-trap hits).
- **Ongoing maintenance:** periodically check enrolled consumers again against current criteria, and verify that the addresses receiving reports still work.
- **Privacy:** report data must not be passed on beyond the approved recipient, and misuse justifies immediate termination. FBLs cross borders, so local data protection law governs what may be redacted or shared. The email address and IP address of the recipient who reported the message are the usual items redacted.
- **Terms of use** should state the obligations of confidentiality, the requirement to keep contacts up to date, that access to an FBL gives **no special sending privileges**, and that enrollment is a privilege that can be withdrawn at any time for any reason.
- **Unsolicited FBLs** (sending reports to senders who have not enrolled) are still debated. If you send them, send them only to mailbox or access providers, only after trying to make contact normally, and only to published WHOIS abuse addresses. Consumers who are not prepared may not be able to handle the volume or the format.

## Recommendations for senders (feedback consumers)

### Before enrolling

- Working role addresses: `abuse@`, `postmaster@`.
- A dedicated address to receive FBL reports.
- Proof that you own your IP addresses: correct reverse DNS and WHOIS records.
- Named contacts and escalation points.

### Handling each complaint

- **Treat a complaint like an unsubscribe.** Make sure no further mail from that list reaches that recipient: remove the address, or add it to the suppression list.
- **How widely to suppress** is a judgment call, and the aim is to reduce future complaints. Suppressing the address across an entire ESP is probably too broad. Suppressing it across all the segmented lists of one customer is probably right.
- **The transactional exception:** sometimes the right action is to ignore the report. For example, a customer who reports their own airline tickets as spam still needs the remaining tickets. Suppress marketing mail, not the transactional stream (one reason to keep transactional mail separate; see [Advanced IP Segmentation](https://emailmarketing.net/learn/ip-management/advanced-ip-segmentation)).

### Measuring complaint rates correctly

RFC 6449 points out several traps in the arithmetic:

- **The day the message was read, not the day it was sent:** complaints are counted on the day the user read the message. A sender who mails Mon–Fri sees an inflated "rate" on Saturday, because complaints are divided by a tiny send count, or even zero.
- **The inbox as denominator:** providers typically divide complaints by the number of messages **delivered to the inbox**, not by the number sent. For a sender with 500 of 10,000 messages in the inbox (9,500 in bulk), complaints are divided by 500. A bad reputation therefore makes the measured rate even worse.
- The RFC gives a rough scale: 10 reports a day could signal serious problems for a small sender, but be normal background for one sending 300,000 a month. It cites a **2% complaint rate** as possible grounds for immediate blocking. Current provider thresholds are far stricter: Gmail wants < 0.1%.
- **Watch trends, not only counts.** ISPs should watch complaints for each customer or IP address each day, because a sudden spike suggests a spammer's signup or a compromised system. ESPs should break complaints down by customer, list and campaign, and use the rate (complaints divided by messages sent) rather than absolute counts.

### Automation

- **Small consumers** (lists of a few thousand addresses) need little or no automation, since ARF reports can be read in a mail client. A simple filter that adds the reported IP address to the Subject line makes patterns visible when you sort.
- **Large consumers** must extract from each report the recipient who complained, the mailbox provider that sent the report, the responsible customer (for ESPs), the campaign and list identifiers, and optionally the source IP address and the DKIM `d=`.
- **Because the recipient's address is often redacted**, put recipient and campaign identifiers in the message itself, where FBL processing will not strip them. The options are database primary keys (opaque, but you need database access), encrypted values (you need automated decryption), or encoding in the Message-ID. For example, `esp-423-27-42460@example.com` is opaque to outsiders but the sender can parse it.
- **Reuse the bounce pipeline.** If the identifier converts to the same format as the VERP string used for bounce processing, the FBL processor can create a "fake" hard bounce and pass it to the existing bounce processor, which suppresses the address (see [Delivery Status Notifications](https://emailmarketing.net/learn/bounce-handling/delivery-status-notifications)).
- ISPs that consume reports mostly need the source IP address and the responsible customer. The IP address is usually in the ARF metadata, and otherwise in the Received headers.

## Security considerations

The provider must make sure that reports go only to authorized consumers, and must establish the sender's identity from the connecting IP address or the DKIM signing domain, "both of which are hard to forge." This stops spammers from enrolling for networks they do not own in order to collect addresses and private data from the reports.

## Related articles

- [List-Unsubscribe and One-Click Unsubscribe](https://emailmarketing.net/learn/list-management/list-unsubscribe), which lets users leave a list rather than complain
- [Foundations of Email Deliverability](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability)