Bounce handling series. This is the tactical guide to Feedback Loops (FBL). For related guides on DSN parsing, bounce categorization, and suppression lists, see the bounce handling hub →
Quick FBL reference
A Feedback Loop (FBL) is a service where a mailbox provider forwards a copy of every spam complaint to the sender, so the sender can immediately suppress the complaining recipient. Every serious sender registers for FBLs at every provider that offers one. Without them, complaint rates keep climbing invisibly until Gmail or Yahoo throttles the whole domain.
| Format | ARF (Abuse Reporting Format), RFC 5965 |
| Container | multipart/report; report-type=feedback-report |
| Providers with FBL | Google (via Postmaster Tools), Microsoft (JMRP + SNDS), Yahoo, Comcast, La Poste, Terra, iCloud |
| Providers without FBL | Apple iCloud (partial), most EU consumer ISPs, most B2B mail systems |
| Delivery | Emails to your registered address, or webhook/dashboard for some providers |
| Latency | Seconds to hours depending on provider |
When someone marks your message as spam in Gmail, Outlook, or Yahoo, the message was delivered successfully. It passed authentication, it passed content filters, it landed in the inbox. Then the recipient clicked “Report spam” and the receiver’s system generated a complaint. Without an FBL, you have no idea this happened. The complaint counts against your reputation, but you cannot suppress the complaining address, so you keep sending to them, they keep complaining, and your reputation keeps dropping. With an FBL registered, you receive a copy of the complaint immediately and can suppress on the spot. This guide covers the ARF format, the signup process at every major provider, and the code patterns to handle FBL messages in production.
Why FBLs matter more than ever
Gmail and Yahoo’s 2024 sender rules mandate a complaint rate below 0.3 percent for any bulk sender (5,000+ messages per day). Sustained rates above 0.1 percent trigger throttling; sustained rates above 0.3 percent trigger blocking. Without FBLs, you cannot see the complaints happening; you only see the aggregate reputation drop after enforcement kicks in.
Three specific ways FBLs earn their weight:
- Immediate suppression. Every complaint received via FBL is one fewer future send to that recipient, which means one fewer opportunity for that recipient to complain again.
- Reputation early warning. Rising FBL complaint counts across a segment tell you which acquisition source, list, or campaign is generating friction, days or weeks before Google Postmaster Tools reflects the drop.
- Compliance signal. Gmail and Yahoo look for evidence that senders monitor and act on complaints. Being registered for FBLs, and provably acting on them, is one of the signals they weight.
Missing an FBL registration is not a soft mistake; it is a self-imposed blind spot on a metric that decides your deliverability.
The ARF format (RFC 5965)
ARF is a structured MIME format for machine-readable abuse reports. Very similar to a DSN in shape, different in content. The container:
Content-Type: multipart/report;
report-type=feedback-report;
boundary="=_boundary_arf1"The report-type=feedback-report parameter distinguishes ARF from DSN (delivery-status) and other MIME reports. Inside, three parts:
Part 1: Human-readable summary (text/plain)
Explanation for a human reading the report. Usually short: “This is an email abuse report from Yahoo. The following user has complained…”
Part 2: Machine-readable report (message/feedback-report)
The core: structured fields describing the complaint. Fields are:
| Field | Meaning |
|---|---|
Feedback-Type | Type of report. Most common: abuse (spam complaint). Others: fraud, opt-out, virus. |
User-Agent | The complaint-generating system (e.g., YahooABG/1.0). |
Version | ARF version (currently 1). |
Original-Rcpt-To | The recipient that complained. THIS IS THE FIELD TO EXTRACT. |
Original-Mail-From | The envelope sender of the complained-about message. |
Arrival-Date | When the original message arrived at the recipient. |
Reported-Domain | The domain being complained about (usually your sending domain). |
Source-IP | The IP that sent the original message. |
Authentication-Results | The receiver’s auth verdict on the original message. See our Authentication-Results guide. |
Part 3: Original message (message/rfc822)
The full original message, or its headers only, that generated the complaint. Use the Message-ID from here to correlate the complaint to your send log.
FBL signup by major provider
Google (via Postmaster Tools)
Google does not offer a traditional per-message FBL. Instead, complaints are aggregated in Google Postmaster Tools as a Spam Rate metric per day. To access:
- Verify your sending domain in Postmaster Tools (DNS TXT record).
- Wait 48 hours for data to populate.
- Monitor the Spam Rate dashboard daily.
Google’s Spam Rate is your effective FBL: it shows the daily complaint percentage. Individual complaints are not delivered per-message. Automation happens at the aggregate level (throttle or suppress a segment if the daily rate spikes).
Microsoft (JMRP + SNDS)
Microsoft offers Junk Mail Reporting Program (JMRP), a proper per-message FBL. Signup:
- Go to Microsoft’s JMRP page.
- Provide sending IPs (yours or your ESP’s) and an FBL email address (like
fbl@sender.example.com). - Verify domain ownership.
- Wait 1-2 weeks for approval.
Approved senders receive ARF reports at the registered address for every complaint from Outlook.com, Hotmail.com, Live.com, and MSN.com. Also register for SNDS (Smart Network Data Services) which gives you IP reputation data separately.
Yahoo (Complaint Feedback Loop)
Yahoo runs a traditional FBL at Yahoo’s Complaint Feedback Loop. Signup:
- Submit sending domain and IPs.
- DKIM-signed messages are prerequisite.
- Approval typically within a week.
Reports arrive as ARF at the registered address. Covers Yahoo Mail, AOL Mail, and Verizon-owned addresses.
Comcast (Xfinity)
Comcast runs an FBL for Xfinity customers. Signup at postmaster.comcast.net. Similar signup process to Yahoo, DKIM required.
La Poste (French ISP)
La Poste offers an FBL for laposte.net addresses. Signup via their postmaster contact form. Covers a significant share of French consumer mail.
Apple iCloud
Apple does not offer a public FBL. Complaints are handled internally by Apple’s reputation system. For iCloud senders, monitoring reputation via SNDS-equivalent tools is not available; watch aggregate delivery metrics instead.
Others
Terra (Brazil), UOL (Brazil), Rambler (Russia), and a handful of national ISPs offer FBLs. Register per market. ESP dashboards often show a compiled list of FBL registrations you can enable.
Handling FBL messages in code
Once you receive ARF reports at your registered address, your inbound pipeline parses them and adds the complaining recipient to your suppression list.
Detection
An ARF report has the Content-Type multipart/report; report-type=feedback-report. Filter your inbound mail for this content type; anything else is not an FBL report.
Parsing (Python)
import email
from email import policy
with open('fbl.eml', 'rb') as f:
msg = email.message_from_binary_file(f, policy=policy.default)
if 'report-type=feedback-report' not in msg.get('Content-Type', ''):
print('Not an ARF report')
else:
for part in msg.iter_parts():
if part.get_content_type() == 'message/feedback-report':
recipient = part.get('Original-Rcpt-To', '').strip()
feedback_type = part.get('Feedback-Type', 'abuse')
source_ip = part.get('Source-IP', '')
arrival = part.get('Arrival-Date', '')
print(f'Complaint from {recipient} ({feedback_type})')
print(f'Original send from IP {source_ip} on {arrival}')
# Add to suppression list
suppress(recipient, reason='fbl_complaint', source=feedback_type)
elif part.get_content_type() == 'message/rfc822':
# Extract original Message-ID for correlation
original = list(part.iter_parts())[0]
message_id = original.get('Message-ID', '')
correlate_to_send_log(message_id)Suppression action
On any abuse-type FBL report, add the recipient to your suppression list immediately. Do not send again. Log the complaint with timestamp and source for reputation tracking. If complaint volume from a specific IP or segment rises, alert the deliverability team.
Not-quite-suppression cases
Some FBL reports are opt-out type (user requested unsubscribe via the mail client’s unsubscribe button). Handle these as unsubscribes rather than complaints; the outcome is similar (do not send) but the reason differs. See our List-Unsubscribe guide for the header-driven side of unsubscribes.
Integrating FBL with reputation monitoring
FBL reports give you individual complaints. Reputation monitoring gives you aggregate trends. Combining both is where the value compounds.
Per-IP complaint rate
Track FBL reports per sending IP over rolling 24-hour and 7-day windows. Sudden spikes on one IP (while others stay steady) indicate that IP or its recent traffic pattern is triggering complaints. Possible causes: a specific campaign, a specific segment, a specific creative variant, or IP-level reputation damage.
Per-segment complaint rate
Correlate FBL reports back to the sending campaign or segment via the original Message-ID. A segment with a 0.5 percent FBL rate is your problem source; the rest of the list may be at 0.05 percent. Isolating the problem segment lets you fix targeting or suppress the whole segment before it damages reputation.
Per-content complaint rate
Match FBL reports to specific templates or subject lines via Message-ID. A template with a much higher complaint rate has content that reads as spam to some fraction of recipients. Test alternatives on a small segment before rolling back to broad send.
10 common FBL mistakes
- Not registering FBLs at all. The most common mistake. Registration is free at every provider. Not registering means flying blind on complaint rates.
- Registering the FBL address on a mailbox that nobody monitors. Complaints pile up unread. Suppression never happens. Reputation drops. Monitor the FBL inbox as first-class ops data.
- Not suppressing on FBL complaints. The whole point is immediate suppression. Failing to act on complaints is worse than not being registered (Google notices lack of action).
- Confusing FBL complaints with hard bounces. Different categories, different sources. Complaints come from FBL registrations; bounces come from DSN parsing. See our bounce categorization guide for the split.
- Suppressing but not tracking source. Suppression alone is not enough. Log the FBL source (Yahoo, Microsoft, Comcast) so you can spot patterns per receiver.
- Not correlating to the original send. Extract the Message-ID from the third part of the ARF report and match it to your send log. Without correlation, complaints become anonymous statistics.
- Assuming Google Postmaster equals an FBL. Postmaster gives you an aggregate spam rate percentage. It does not give you individual complaint messages or the specific recipient addresses that complained. Register per-provider FBLs elsewhere.
- Registering FBL for shared ESP IPs when your ESP already handles them. Duplicate FBL registrations for the same IP cause noise. If your ESP registered the FBL and handles suppression, do not double-register.
- Ignoring
opt-out-type reports. Not all FBL reports are complaints; some are unsubscribe signals via the mail client’s built-in one-click. Both need suppression, but the categorization differs. - Not monitoring FBL delivery. If your registered FBL address stops receiving reports, either your reputation improved dramatically or the FBL registration lapsed. Verify quarterly by sending a test complaint through a controlled account.
FBL FAQ
Do I need FBLs if my ESP handles suppression?
If your ESP is the one that registered the FBLs (usually the case for shared IP pools at SendGrid, Mailgun, Postmark), then no, do not double-register. Your ESP catches the complaint and suppresses on your account. If you use dedicated IPs, self-hosted MTAs, or an ESP that does NOT handle FBLs (check your ESP’s documentation), you need to register FBLs yourself. When in doubt, ask your ESP whether they cover Yahoo, Microsoft JMRP, and others.
Why doesn’t Google offer a per-message FBL?
Google’s stated reason is privacy: forwarding individual complaint messages back to senders would reveal specific recipient identities and could enable retaliation against users who marked mail as spam. Google exposes complaint data as an aggregate percentage in Postmaster Tools instead. The tradeoff for senders: you cannot suppress individual Gmail complainers, but you get a daily Gmail complaint rate metric to monitor. If Gmail spam rate rises above 0.1 percent, investigate the segment or campaign; do not send to Gmail recipients from the flagged pattern until the metric recovers.
How long does FBL signup take?
Varies by provider. Microsoft JMRP typically approves in 1-2 weeks. Yahoo approves within a week. Comcast approves within days. Google Postmaster Tools activates within 48 hours after DNS verification. La Poste and smaller ISPs vary widely. Start the process well before you expect to need the data; do not wait until a reputation drop to register.
What FBL email address should I use?
Use a dedicated address on your sending domain, like fbl@sender.example.com or complaints@sender.example.com. Do not use a personal address or a role account someone else reads. Route incoming mail at this address to your bounce handling pipeline (same infrastructure that parses DSNs, extended to parse ARF). Do not use a mailing list or shared inbox; complaints need to hit the automation, not a human queue.
Should I remove FBL-complaining recipients permanently or temporarily?
Permanently. An FBL complaint is an explicit signal that the recipient does not want your mail. Sending again in six months to the same complainer risks another complaint, and Google and Yahoo cross-reference recent complaint history. Standard practice: add to global suppression list, no expiration. If a specific product need requires later contact (transactional receipt, security alert), route through a separate transactional stream that operates under different suppression rules.
What complaint rate should I target?
Under 0.1 percent (1 complaint per 1,000 sends) is the practical safe zone. Between 0.1 and 0.3 percent is the warning zone where Gmail and Yahoo start throttling. Above 0.3 percent triggers hard enforcement (blocks, spam folder placement of entire domain traffic). The 0.3 percent threshold is per-provider (Gmail measures its own rate independently from Yahoo). Monitor per-provider FBL data and Postmaster dashboards separately; a single provider spiking is easier to fix than an average drift across all.
Final words
FBLs are the difference between reactive reputation management (Google Postmaster Tools shows a drop, you investigate weeks later) and proactive suppression (a complaint arrives, you suppress within seconds). The registration process is straightforward, the parsing is a small extension of your existing DSN pipeline, and the effect on long-term reputation is significant.
The mental model: DSNs are for “cannot deliver”. FBLs are for “delivered but rejected by the human”. Both feed the same suppression list, both need parsing infrastructure, both need correlation to send logs via Message-ID. The next article in this series ties them together with suppression list best practices.
For related guides, see DSN parsing, bounce categorization, Google Postmaster Tools, the Google and Yahoo bulk sender rules, and the Deliverability hub.
Complaints often come from cold or purchased addresses.
SMTPing catches invalid addresses, disposables, catch-all traps, role accounts and dead mailboxes before send. Cleaner acquisition means fewer FBL complaints and a healthier reputation. 13 validation types, 25 free daily.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
