Complaint Feedback Loops (RFC 6449)

RFC 6449 ("Complaint Feedback Loop Operational Recommendations") documents how mailbox providers forward end-user spam complaints back to senders. Its stated intent: "to provide Feedback Consumers with information necessary to mitigate Spam or the perception of Spam."

Complaints are one of the primary reputation signals mailbox providers measure (see Foundations of Email Deliverability); an FBL is the sender's direct pipe into that signal.

Terminology

Term	Meaning
Spam (in FBL context)	Any message the recipient chooses to complain about, regardless of the author's intent
Feedback Provider	The entity sending complaint reports — typically a mailbox provider
Feedback Consumer	The recipient of the reports — the message originator, or an ESP/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 UI or provider mail client. (If the provider offers no such button, an effective FBL is essentially impossible.)
2. The provider matches the message to an enrolled Feedback Consumer — traditionally by the last-hop IP address that handed the message to the provider; increasingly by DKIM d= domain.
3. An ARF report is generated and sent immediately, without review — the consumer receives it in near real time.

DKIM-based vs IP-based FBL routing

A single DKIM d= value can span many servers and IPs; servers can be added or removed without touching the FBL registration ("when a Feedback Loop uses DKIM, no reconfiguration is necessary because the signing domain does not change"). IP-keyed FBLs must be updated whenever sending infrastructure changes. Prefer DKIM-based enrollment where the provider offers it; it also pairs naturally with DMARC alignment and per-stream signing domains (see Advanced IP Segmentation).

Enrollment mechanics (per M3AAWG's FBL resources page): domain-based signup requires the mail to be DKIM-signed and asks for both the signing domain (the d= value) and the selector (the s= value) from the DKIM signature — so the selector used on production mail must be known and stable at enrollment time. Aggregated FBLs, by contrast, roll up complaint counts keyed by IP, domain, or an identifier the sender chooses (the pattern Gmail implements with the Feedback-ID header — see Google Postmaster Tools). The per-provider signup directory — most traditional FBLs run through Validity's Universal Feedback Loop at fbl.validity.com — is maintained in M3AAWG Document Index & FBL Ecosystem.

ARF report structure (RFC 5965)

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

Part	Content
1. Human-readable text	Boilerplate explaining the report, provider contact info
2. Machine-readable metadata (message/feedback-report)	Protocol version, report type (abuse, fraud, …), optional envelope sender, receipt timestamp
3. Original message (message/rfc822)	Copy of the complained-about email — often redacted, especially the recipient's address, for privacy/legal reasons

Because the recipient address is frequently 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 & vetting: streamlined application process; verify the applicant is authorized for the IPs/domains claimed. Cross-check IP ownership via origin ASN, WHOIS/RWHOIS, reverse DNS; verify contacts via a confirmation mail to abuse@/postmaster@.
• Denial: applications may be refused when the requester appears to be gaming delivery policies via bogus enrollment, or is already blocked for bad reputation. Maintain a documented, transparent appeals process.
• Report contents: include a contact address for questions (ideally feeding a ticket system); optionally include summary delivery statistics (volume, inbox rate, spam-trap hits).
• Ongoing maintenance: periodically re-validate enrolled consumers against current criteria, and verify the report-receiving addresses still work.
• Privacy: report data must not be transmitted beyond the approved recipient; misuse warrants immediate termination. FBLs cross borders — local data-protection law governs what may be redacted or shared. Recipient/reporter email address and IP are the usual redaction targets.
• Terms of use should state: confidentiality obligations, requirement to keep contacts current, that FBL access grants no special sending privileges, and that enrollment is a privilege revocable at any time for any reason.
• Unsolicited FBLs (sending reports to non-enrolled senders) remain debated; if done, only toward mailbox/access providers, after attempting normal contact, and only to published WHOIS abuse addresses — unprepared consumers may be unable to handle the volume or format.

Recommendations for senders (feedback consumers)

Before enrolling

• Working role addresses: abuse@, postmaster@.
• A dedicated address to receive FBL reports.
• Demonstrable IP ownership: correct reverse DNS and WHOIS.
• Named contacts and escalation points.

Handling each complaint

• Treat a complaint like an unsubscribe: ensure no further mail from that list reaches that recipient — remove the address or add it to the suppression list.
• Scope of suppression is a judgment call aimed at reducing future complaints: suppressing across an entire ESP is likely too broad; suppressing across all of one customer's segmented lists is probably right.
• Transactional exception: sometimes the right action is to ignore the report — e.g. a customer who reports their own airline tickets as spam still needs the remaining tickets. Suppress marketing, not the transaction stream (a reason to isolate transactional mail — see Advanced IP Segmentation).

Measuring complaint rates correctly

RFC 6449 flags several arithmetic traps:

• Read-day vs send-day: complaints are counted the day the user read the message, not the day it was sent. A Mon–Fri sender sees an inflated Saturday "rate" — complaints divided by a tiny (possibly zero) send count.
• Inbox-denominator effect: providers typically divide complaints by messages delivered to the inbox, not messages sent. A sender with 500 of 10,000 messages inboxed (9,500 in bulk) has its complaints divided by 500 — bad reputation makes the measured rate worse still.
• Rough calibration from the RFC: 10 reports/day could signal serious problems for a small sender but be normal background for one sending 300,000/month; a 2% complaint rate is cited as potential grounds for immediate blocking. (Modern provider thresholds are far stricter — Gmail wants < 0.1%.)
• Trend, don't just count: ISPs should watch complaints per customer/IP per day — a sudden spike suggests a spammer signup or a compromised system. ESPs should break complaints down by customer, list, and campaign, and use rate (complaints ÷ sent) rather than absolute counts.

Automation

• Small consumers (lists of a few thousand): little or no automation needed; ARF reports are readable in a mail client. A lightweight filter that annotates the Subject with the reported IP makes patterns visible by sorting.
• Large consumers must extract per report: the complaining recipient, the originating mailbox provider, the responsible customer (for ESPs), campaign/list identifiers, and optionally source IP and DKIM d=.
• Because the recipient address is often redacted, embed recipient/campaign identifiers in the message itself where FBL processing won't strip them. Options: database primary keys (opaque but needs DB access), encrypted blobs (needs automated decryption), or Message-ID encoding — e.g. esp-423-27-42460@example.com is opaque to outsiders but parseable by the sender.
• Reuse the bounce pipeline: if the identifier converts to the same format as the VERP string used for bounce processing, the FBL processor can synthesize a "fake" hard bounce and hand it to the existing bounce processor to suppress the address (see Delivery Status Notifications).
• ISP consumers mostly need the source IP and responsible customer; the IP is usually in the ARF metadata, otherwise in Received headers.

Security considerations

The provider is responsible for ensuring reports go only to authorized consumers, with sender identity established from the connecting IP or DKIM signature domain — "both of which are hard to forge." This blocks spammers from enrolling for networks they don't own to harvest addresses and private data from reports.

Related

• List-Unsubscribe and One-Click Unsubscribe — the mechanism that lets users leave a list instead of complaining.
• Foundations of Email Deliverability — where complaint rate sits among reputation signals.