Feedback Loop (FBL) — Complaint Reporting Standard

What an FBL is and isn't

The terminology around feedback loops is inconsistent across the industry. Different providers use different names for what is fundamentally the same mechanism:

The mechanism is the same in all cases: a recipient clicks the spam/junk button in their mail client, the mailbox provider captures the event, and a report is forwarded back to the sender. What differs by provider is the format (ARF or proprietary), the level of detail (per-message vs aggregate), the registration path (per-IP, per-domain, or via aggregator), and whether the recipient address is included or redacted.

Abuse Reporting Format (ARF) — RFC 5965

ARF is the IETF standard that defines what a feedback loop report looks like on the wire. Published as RFC 5965 in August 2010, it standardised what was previously a collection of provider-specific formats into a single multipart MIME structure that any parser can handle.

Anatomy of an ARF report

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

From: feedback@isp.example.com
To: abuse@sender.example.com
Subject: FBL report - complaint from user
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
              boundary="ARF-BOUNDARY-001"

--ARF-BOUNDARY-001
Content-Type: text/plain

This is an abuse report for a message received from IP 203.0.113.10
on Wed, 11 Mar 2026 09:15:00 -0500.

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

Feedback-Type: abuse
User-Agent: ISP-FBL/1.0
Version: 1
Original-Mail-From: campaign@sender.example.com
Arrival-Date: Wed, 11 Mar 2026 09:15:00 -0500
Source-IP: 203.0.113.10
Reported-Domain: sender.example.com
Authentication-Results: isp.example.com;
    dkim=pass header.d=sender.example.com;
    spf=pass smtp.mailfrom=sender.example.com

--ARF-BOUNDARY-001
Content-Type: message/rfc822

From: campaign@sender.example.com
To: user@isp.example.com
Subject: Weekly Newsletter #42
Message-ID: <news-42@sender.example.com>
List-Unsubscribe: <https://sender.example.com/unsub?id=xyz>

[original message body]

--ARF-BOUNDARY-001--

The headers that matter for processing

Who runs FBLs in 2026 — provider matrix

The FBL landscape in 2026 has consolidated significantly from its 2010s peak. Four operational paths cover the vast majority of consumer traffic:

The Gmail and Apple absence

The two biggest gaps in the FBL landscape are deliberate product decisions, not oversights. Google does not offer per-message complaint reports; the closest equivalent is the aggregate "spam rate" view in Google Postmaster Tools. Apple offers no FBL at all for iCloud. Together, these two cover a large portion of consumer email opens, and the practical consequence is that senders never get message-level attribution for the most important consumer audience.

The workaround for both is to maintain robust internal complaint inference: track unsubscribes, soft-deletes, lack of click engagement, and rapid bounce escalations as proxies for complaint behaviour you cannot directly observe. For the Apple side specifically, our note on Apple iCloud enforcement watch covers the operational pattern in detail.

Yahoo CFL — the DKIM-keyed FBL

Yahoo's Complaint Feedback Loop deserves its own subsection because it is operationally different from every other major FBL. Yahoo's feedback loop is unique compared to most others, in that you register your sending domain, and the FBL only covers (will only send reports about) mail that is properly authenticated with DKIM authentication.

Three operational consequences:

• Registration is per-DKIM-d-domain, not per-IP. You register the domain you sign DKIM with at senders.yahooinc.com; mail signed with that domain generates CFL reports regardless of which IP sent it.
• Mail without DKIM produces no reports. If you ship a campaign without DKIM (or with broken DKIM that does not verify), Yahoo complaints from that campaign are silently lost. The CFL effectively requires DKIM as a precondition.
• The recipient address is not redacted. Unlike Microsoft JMRP, Yahoo CFL includes the full Original-Rcpt-To in the ARF report, making automated suppression straightforward.

FBL enrolment patterns

Enrolling in FBLs is straightforward but time-consuming because every provider has its own portal, its own verification step, and its own quirks. The typical pattern across providers:

1. Verify control of the asset. For per-IP FBLs (Microsoft JMRP, Comcast, most others), this means receiving a verification email at a role address (postmaster@, abuse@) on the rDNS of the IP. For per-domain FBLs (Yahoo CFL), it means publishing a TXT record or signing DKIM correctly. Without this, the registration cannot complete.
2. Nominate a reporting address. This is where the ARF reports will be delivered. The address should be on a domain you clearly control, monitored by a process (not a human), and able to handle the volume — large senders generate hundreds of reports per day.
3. Wait for approval. Most providers approve within 24-48 hours; Yahoo CFL is often immediate; Validity Universal FBL typically takes 3-5 business days because they process registrations in batches.
4. Test with a deliberate complaint. Send a campaign to a personal account at the provider, mark it junk, and verify the report arrives at your nominated address within minutes to hours.

The role-address requirement

Multiple FBLs check that the role addresses postmaster@ and abuse@ on your sending domain are reachable and monitored. This is RFC 2142 conformance, and a surprising number of senders fail it because nobody set up those aliases when the domain was provisioned. Before starting FBL enrolment, verify both addresses receive and route mail to a monitored destination.

Operational processing of ARF reports

Receiving ARF reports is half the work. The other half is processing them in a pipeline that suppresses complainers fast enough to prevent the same recipient from generating further complaints.

The minimum viable pipeline

1. Dedicated inbox (fbl@yourdomain) routed to a parser, not a human.
2. ARF parser that extracts Feedback-Type, Source-IP, Original-Rcpt-To (or the per-recipient identifier you embedded), Arrival-Date, and the campaign ID from the embedded original message.
3. Recipient resolution. Use Original-Rcpt-To directly when present (Yahoo, Comcast, most providers). When redacted (Microsoft JMRP), look up the per-recipient identifier in your embedded headers or unsubscribe URL.
4. Immediate suppression. Add the recipient to your master suppression list within minutes. Target latency from receipt to suppression: under 5 minutes.
5. Campaign attribution. Tag the campaign ID from the embedded message, increment your per-campaign complaint counter, fire an alert if the rate exceeds threshold.
6. Audit log. Keep every parsed ARF report archived for at least 30 days for investigation purposes.

Per-recipient identifier — the workaround for redacted FBLs

Microsoft JMRP and a handful of smaller providers redact the recipient address in their ARF reports as a privacy measure. The standard workaround applies to every redacting FBL: embed a per-recipient opaque identifier in every outbound message so you can recover the identity from your own data.

• Custom X-header. Add X-Subscriber-ID: hash-or-token to every message. The ARF report includes the embedded original message including this header.
• Unsubscribe URL tokenisation. The List-Unsubscribe URL already includes a per-recipient token. ARF returns the message including that URL, so you can extract the token.

Both patterns work; many senders use both for redundancy. The recipient identifier should be opaque (a hash or random token, not the plain email address) to preserve the privacy intent of the redaction.

FBL complaint thresholds and what they trigger

FBL data feeds directly into deliverability decisions at the receiving end. Complaint rate — complaints divided by messages delivered — is one of the gating metrics that every major mailbox provider monitors:

The 0.3% line is the most consequential number in modern email deliverability. Gmail and Yahoo both enforce it; Microsoft has similar internal thresholds via SNDS. For the operational context on how to keep below the line and what happens when you cross it, see our note on 2026 email marketing benchmarks which has the threshold tier breakdown by vertical.

FBLs without suppression — the worst pattern

The single most damaging operational pattern with FBLs is enrolment without processing. A sender enrols in JMRP and Yahoo CFL, routes the reports to an inbox, and then... does nothing with them. The complaints accumulate, the recipients are not suppressed, and they continue receiving messages they have already flagged as spam. The next time they receive a message they complain again, and the cycle repeats — except now their complaints are reinforcing rather than dissipating, and the mailbox provider sees a sustained complaint signal that triggers stronger filtering.

FBL processing in CSE managed infrastructure

Every managed installation we operate ships with multi-provider FBL enrolment as part of standard onboarding: Microsoft JMRP, Yahoo CFL, Validity Universal FBL, and the smaller direct registrations where applicable. Reports route through a common ARF parsing pipeline that handles the per-provider quirks (redacted vs full recipient, header field variants like Received-Date vs Arrival-Date, DKIM-keyed vs IP-keyed registration mappings) and suppresses complainers across all of the client's lists within minutes of report receipt. Campaign-level complaint aggregation feeds a per-campaign alerting system that catches anomalies before SNDS or Postmaster Tools reflect them in their slower aggregate metrics.

For senders running their own infrastructure, the operational pattern is consistent: enrol in every available FBL, route reports to a parser-only inbox, suppress within 5 minutes of receipt, alert on per-campaign anomalies, archive 30 days for audit. The technical complexity is low; the operational discipline is high.

Related concepts

• JMRP — Microsoft's specific FBL implementation, paired with SNDS
• SNDS — Microsoft's aggregate dashboard that pairs with JMRP for source attribution
• Sender Reputation — the broader concept that FBL complaint rate measures one dimension of
• DKIM — required for Yahoo CFL coverage; relevant to all FBLs as authentication context
• 2026 email marketing benchmarks — the complaint-rate thresholds (0.10% / 0.30%) and the broader deliverability context
• Complaint rate spikes — tracing the source — the operational pattern of using FBL data for incident response
• Apple iCloud enforcement watch — the operational note on how to infer complaints when no FBL exists