Feedback loops (FBLs): track and suppress complaints

When a recipient hits "Report Spam," most receivers will tell you — but only if you ask, and only if you've enrolled in their feedback loop program. FBLs are free, mandatory for any serious sender, and the lever that separates programs that learn from their mistakes from programs that don't.

For the broader pre-send and post-send workflow, use the deliverability hub and pair FBL evidence with deliverability testing, list hygiene, and suppression rules.

The major programs

What an ARF report looks like

Abuse Reporting Format (RFC 5965) is a multipart email with three parts: a human-readable summary, a message/feedback-report machine-readable body, and an attached copy of the original message (often redacted).

Feedback-Type: abuse
User-Agent: SomeMailUA/1.0
Version: 1
Original-Mail-From: <newsletter [at] example.com>
Original-Rcpt-To: <user [at] receiver.com>
Arrival-Date: Mon, 26 Apr 2026 10:00:00 +0000
Reported-Domain: example.com
Source-IP: 203.0.113.42

Your processor reads Original-Rcpt-To, suppresses that address, and increments a complaint counter for the sending IP and From domain. Some processors also store the report itself for later analysis.

Enrolling step-by-step

Suppression discipline

• Suppress on first complaint, irreversibly.
• Store complaint reason and timestamp for audit.
• Audit your suppression engine quarterly — leaks happen.
• Treat complaints as stronger than unsubscribes. The recipient escalated.

Reading complaint trends

Spikes are more diagnostic than absolute levels. A campaign that doubles your baseline overnight has a content or segmenting problem; one that creeps up over months has a list decay problem.

What FBLs don't catch

• Spam-folder placement. Recipients can't complain about mail they never see.
• Silent unengagement. Users deleting without opening is invisible to FBLs but visible in receiver-side reputation models.
• B2B receivers. Most corporate mail systems don't run FBLs at all.
• Apple iCloud. Currently no public FBL.

Additional guidance: Email Feedback Loops: What They Are and How to Set Them Up

An email feedback loop (FBL) is a reporting channel where a mailbox provider forwards you a copy of every message one of its users marked as spam — so you can suppress that recipient immediately. Setup means registering your sending IPs or DKIM domain with providers like Yahoo (CFL) and Microsoft (JMRP), then piping the ARF-formatted reports into your suppression list. It's the fastest reputation signal you'll ever get.

Complaints are the metric Gmail and Yahoo weight most heavily in 2026, and the complaint thresholds are tight: roughly 0.1% at Gmail, 0.3% at Yahoo. An FBL is how you see those complaints in near-real time instead of discovering them weeks later in a reputation collapse.

What is an email feedback loop, exactly?

When a user clicks "Report spam," the provider does two things: moves the message to the spam folder, and — if the sender is registered for its FBL — packages a report and emails it to an address the sender designated.

The report arrives in ARF (Abuse Reporting Format), a standardized machine-readable MIME format defined by the messaging industry. Each report contains three parts: a human-readable summary, a machine-readable metadata block, and usually a copy of the original offending message (or its headers).

A typical ARF report looks like this:

Content-Type: multipart/report; report-type=feedback-report;
  boundary="----=_Part_88213_1902847.1754301600123"

------=_Part_88213_1902847.1754301600123
Content-Type: text/plain

This is an email abuse report for an email message received from
IP 203.0.113.44 on Tue, 04 Aug 2026 09:12:00 +0000.

------=_Part_88213_1902847.1754301600123
Content-Type: message/feedback-report

Feedback-Type: abuse
User-Agent: Yahoo-CFL/1.0
Version: 1
Original-Mail-From: <[email protected]>
Original-Rcpt-To: <[email protected]>
Reported-Domain: mail.example.com
Source-IP: 203.0.113.44
Authentication-Results: spf=pass smtp.mailfrom=mail.example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com
Arrival-Date: Tue, 04 Aug 2026 09:11:58 +0000

------=_Part_88213_1902847.1754301600123
Content-Type: message/rfc822

[original message headers and body]
------=_Part_88213_1902847.1754301600123--

Your job as the sender: parse Original-Rcpt-To (or match a header you embedded), suppress that address permanently, and log the complaint against the campaign that caused it.

Why is complaint data the fastest reputation signal?

Every other reputation input is a proxy. Engagement metrics lag. Seed tests sample strangers. Blacklist listings are trailing indicators. A complaint is a direct, unambiguous human judgment: I did not want this email — delivered to you within minutes of the judgment happening.

That speed matters because the thresholds are unforgiving:

• Gmail: keep spam complaint rates below roughly 0.1%. Sustained rates above that degrade placement; above ~0.3% you're in bulk-folder or rejection territory.
• Yahoo: similar model, with around 0.3% as the line, and domain-reputation-first scoring since April 2025.

At 100,000 emails per day, Gmail's 0.1% threshold is 100 complaints. A single bad segment or a confusing unsubscribe flow can generate that in one send. Without an FBL feed, you find out via declining opens. With one, you see the complaint curve within the hour and can kill the campaign or fix the segment before the next send compounds the damage.

What does the provider landscape look like in 2026?

Three ecosystems matter, and they work differently:

Yahoo CFL (Complaint Feedback Loop)

The most accessible traditional FBL. You register your DKIM-signing domain through Yahoo's sender portal, designate a feedback email address, and start receiving per-message ARF reports. Because it's keyed to your DKIM domain rather than IPs, it follows you across infrastructure changes. If you send meaningful volume to Yahoo addresses, this is non-negotiable — see the requirements at sender.yahooinc.com.

Google Postmaster Tools FBL

Gmail doesn't send classic per-recipient ARF reports to ordinary senders — privacy posture. Instead, its FBL (aimed at ESPs and high-volume senders) aggregates complaints by a customer/campaign identifier you embed via the Feedback-ID header, and reports rates in Postmaster Tools:

Feedback-ID: campaign-2026-08-promo:customer-4812:example.com

Even if you can't use the FBL itself, Postmaster Tools shows your overall Gmail spam rate — which we cover in Google Postmaster Tools v2. That aggregate number is your primary Gmail complaint signal.

Microsoft JMRP and SNDS

Microsoft's Junk Mail Reporting Program (JMRP) sends per-message ARF reports for Outlook/Hotmail complaints, but registration runs through the Smart Network Data Services (SNDS) portal and is tied to IP ownership — you prove control of the sending IPs. If you're on a shared IP pool at an ESP, the ESP owns the JMRP relationship, and you get complaint data only if they pass it through. Details in our Microsoft SNDS guide.

Who can actually register, and what do you need?

The gatekeeping is about accountability: providers only send complaint data to whoever provably controls the sending identity.

• IP-based programs (Microsoft JMRP/SNDS): you need control of the IP space — typically meaning you own a dedicated IP or are the ESP. Shared-IP senders depend on their ESP's handling.
• Domain-based programs (Yahoo CFL): you need a DKIM-signing domain you control, plus a working abuse-contact mailbox.
• Aggregate programs (Gmail): meaningful volume (roughly 5,000+ messages/day to Gmail users) before Postmaster Tools populates data, and FBL access is aimed at ESP-scale senders.

Practical implication: if you send through an ESP, ask them how complaint data reaches you. Good ESPs register for every applicable FBL and expose complaints as webhook events. Bad ones silently swallow them — meaning you keep mailing people who reported you, which is how reputations die.

How should you process FBL complaints?

Three rules, no exceptions:

1. Suppress immediately and permanently. The complaining address goes on your suppression list within seconds of report receipt, across all lists and campaigns. Not "removed from this segment" — suppressed, globally.
2. Never re-mail. Not after six months, not if they reappear in an imported list. Your suppression layer must be checked on every send and every import. We detail the mechanics in the email suppression lists guide.
3. Attribute and aggregate. Log each complaint against the campaign, segment, and acquisition source that produced the address. A complaint is data about why the mail was unwanted, not just an address to remove.

One nuance: treat FBL unsubscriptions like unsubscribes for content purposes. If someone reported your newsletter as spam because they couldn't find the unsubscribe link, the fix isn't just suppression — it's making one-click unsubscribe (List-Unsubscribe-Post, RFC 8058) prominent, which has been mandatory for bulk senders above 5,000/day since the Gmail and Yahoo bulk sender rules took effect.

What if your ESP handles FBLs for you?

Most senders never register for an FBL directly — their ESP does. That's fine, provided the ESP actually passes complaint data through. Audit the relationship with three questions:

1. Are complainers auto-suppressed globally? Good ESPs add FBL complainers to your account-level suppression instantly and block future sends to them. Confirm this happens per complaint, not via a nightly batch.
2. Can you see per-campaign complaint counts and rates? If complaints only surface as a blended account metric, you can't attribute them to the campaign or segment that caused them — and attribution is where the fixing happens.
3. Do complaints arrive as events you can act on? Webhooks or API-accessible complaint events let you wire suppression into your own CRM and data warehouse, so a complainer suppressed at the ESP also gets suppressed in every other tool that can send email.

The failure mode to watch: some senders run multiple platforms (ESP for marketing, a separate tool for transactional, a CRM for sales sequences). A complaint recorded in one system must suppress everywhere. Providers judge your domain — they don't care which of your tools sent the follow-up that re-mailed a complainer.

What does a minimal FBL processing pipeline look like?

If you process reports yourself, the core logic is small:

# Pseudocode: ARF report -> suppression + attribution
def handle_arf(report):
    rcpt = report.headers.get("Original-Rcpt-To")
    campaign_id = report.original_message.headers.get("X-Campaign-ID")

    if not rcpt:
        rcpt = lookup_subscriber_by_token(campaign_id)  # fallback via embedded ID

    email = normalize(rcpt)  # lowercase, strip tags
    suppression_list.add(email, reason="fbl_complaint", permanent=True)
    complaint_log.append(email=email, campaign=campaign_id,
                         source=report.headers.get("Source-IP"),
                         at=report.headers.get("Arrival-Date"))

    if hourly_complaint_count() > ALERT_THRESHOLD:
        pager.alert("Complaint spike — check latest campaign")

Two details people get wrong: normalize addresses before writing them to suppression (case, plus-tags, and whitespace variants all re-mail the same human otherwise), and log before you suppress so a parser bug doesn't silently eat your complaint data.

How do you do the complaint-rate math?

The math is simple; the discipline is in the denominators:

Complaint rate = FBL complaints / messages delivered to that provider

Worked example: you send 50,000 emails to Yahoo addresses on Monday. By Tuesday you've received 40 Yahoo CFL reports.

40 / 50,000 = 0.08%

Under Yahoo's ~0.3% line — fine for a single day. But if you trend 0.08% → 0.15% → 0.22% over three weeks, you have a trajectory problem, and waiting to cross 0.3% before acting means the reputation damage is already done. Set an internal alert at roughly half the provider threshold.

Also remember: FBL reports undercount true complaints. Many users just delete or disengage instead of reporting. If your FBL rate is 0.08%, your true annoyance rate is higher. Use FBL as a floor and a trend line, not as complete accounting.

How do you wire FBL data into your stack?

The production pattern:

1. Dedicated FBL mailbox (e.g., [email protected]) designated at registration. Not a human's inbox — a machine-read address.
2. Parser that extracts the ARF metadata: Original-Rcpt-To, Source-IP, Arrival-Date, plus any custom correlation header you embedded (campaign ID, subscriber ID).
3. Suppression write to your central suppression store, keyed by normalized email address.
4. Event log for trend dashboards and campaign attribution.
5. Alerts when hourly complaint volume crosses your internal threshold.

Embedding a per-recipient identifier in your messages (a custom header like X-Campaign-ID: promo-2026-08-04:sub-9f31a2) makes attribution trivial even when the provider redacts the recipient address — some do.

Before any of this works, your authentication has to be solid — providers won't send FBL data to senders whose identity they can't verify. Run the sender compliance checker to confirm your SPF, DKIM, DMARC, and List-Unsubscribe setup meets the current bulk-sender bar, and use the deliverability tester to verify a live message end to end.

One upstream lever worth pulling before your next send: invalid addresses inflate complaints indirectly, because bad lists correlate with stale, disengaged segments. Scrubbing your list with the email validation tool means fewer invalid recipients, fewer bounces, and ultimately fewer complaint opportunities.