# Email Feedback Loops: ARF Reports and Complaint Handling URL: https://email-validation.org/guides/email-feedback-loops/ Updated: 2026-11-06 > Documentation index: https://email-validation.org/llms.txt A complaint feedback loop (FBL) is a service in which a mailbox provider tells a sender when its users mark the sender's mail as spam. Most FBLs send one report per complaint in the Abuse Reporting Format (ARF), a standard message format. Yahoo and Microsoft send such reports; Gmail does not, and instead shows aggregated complaint data in Postmaster Tools. Treat every report as an unsubscribe: suppress the address at once, then find the campaign or sign-up source that caused it. ## How a feedback loop works [RFC 6449](https://www.rfc-editor.org/info/rfc6449/), "Complaint Feedback Loop Operational Recommendations", writes down practices that grew up in the industry over more than a decade. It began as a document of the Messaging Anti-Abuse Working Group (MAAWG) and is informational, not a standard. In its terms: - A **feedback provider**, usually the mailbox provider, collects spam complaints from its users. - A **feedback consumer**, the sender or its email service provider, applies to receive them. - When a user reports a message, the provider sends the consumer a report with the original message or its headers. Section 1 explains how a provider knows whom to send a report to: usually by the IP address that delivered the mail or by the domain in its DKIM signature, because both are hard to forge. That is why Microsoft's program works by IP and Yahoo's by DKIM domain. The RFC also notes that complaints are forwarded without human review, so a few reports will not be actionable, and that providers may redact data such as the recipient's address. ## The Abuse Reporting Format [RFC 5965](https://www.rfc-editor.org/info/rfc5965/) defines the report format, and [RFC 6650](https://www.rfc-editor.org/info/rfc6650/) updates it with rules for how to use it. Section 2 of RFC 5965 describes a report as a `multipart/report` message with `report-type=feedback-report` and three parts: 1. A human-readable explanation. 2. A machine-readable part of type `message/feedback-report`. 3. The original message (`message/rfc822`) or only its header block (`text/rfc822-headers`). Each report covers one message. A shortened example: ```text Content-Type: multipart/report; report-type=feedback-report; boundary="b1" --b1 Content-Type: text/plain This is a spam complaint about a message from 192.0.2.1. --b1 Content-Type: message/feedback-report Feedback-Type: abuse User-Agent: ExampleFBL/1.0 Version: 1 Original-Mail-From: Arrival-Date: Thu, 5 Nov 2026 14:02:11 +0000 Source-IP: 192.0.2.1 --b1 Content-Type: text/rfc822-headers Message-ID: From: Example News Subject: Your November offers --b1-- ``` Section 3 of RFC 5965 makes three fields required in the second part: `Feedback-Type`, `User-Agent` and `Version`. For complaint loops, RFC 6650, section 4.3, says reports should use `Feedback-Type: abuse` and should include `Original-Mail-From`, `Arrival-Date`, `Source-IP` and `Original-Rcpt-To` when the values are known. Section 4.5 adds two rules for you as the receiver: do not reject a report just because its feedback type is unfamiliar, and accept reports in which user data has been obscured, as described in [RFC 6590](https://www.rfc-editor.org/info/rfc6590/). In practice, the third part is where you find out what was reported. RFC 5965 says to rely on it first, since the fields in the second part are the provider's assertions. ## Which providers offer one | Provider | Program | Keyed on | What you get | |---|---|---|---| | Yahoo (and the domains it hosts, AOL included) | Complaint Feedback Loop | DKIM domain (`d=`) | One ARF report per complaint | | Outlook.com | Junk Mail Reporting Program | Sending IP | One ARF report per complaint, headers only | | Gmail | Feedback Loop in Postmaster Tools | `Feedback-ID` header and DKIM domain | Aggregated rates per identifier, no individual reports | ### Yahoo Yahoo's [Complaint Feedback Loop](https://senders.yahooinc.com/complaint-feedback-loop/) supports only DKIM-signed mail and is domain based. You create a Sender Hub profile, verify your domain and enroll it. Its [FAQ](https://senders.yahooinc.com/faqs/) says the DKIM domain in the `d=` tag must be enrolled, that reports go to any address you control, that IP-based reporting is no longer offered, and that an email service provider will generally enroll your domain for you. Yahoo's [sender best practices](https://senders.yahooinc.com/best-practices/) ask for an active loop on every DKIM domain. ### Microsoft JMRP covers complaints from Outlook.com users and is tied to IP addresses you control through Smart Network Data Services. In 2026, reports changed to headers only, and practitioners report that the recipient's address is hidden. Setup, data and the changes are in [Microsoft SNDS and JMRP](https://email-validation.org/guides/microsoft-snds-jmrp/). ### Gmail Google's [Feedback Loop](https://support.google.com/mail/answer/6254652) works differently. You add a header to each message: ```text Feedback-ID: campaign42:customer7:newsletter:examplesender ``` The last field is a mandatory sender ID of 5 to 15 characters; up to three optional identifiers come before it, such as campaign, customer or mail type. The message must be DKIM-signed, after the header is added, by a domain you have verified in Postmaster Tools. Google reports identifiers with an unusual spam rate in a Postmaster Tools dashboard, and only once an identifier has enough volume and enough distinct complaints. Google warns against per-message values such as a unique message ID, because they produce no useful totals. The data covers `@gmail.com` recipients and is totaled per identifier, not per person, so it shows which campaign has a problem but not whom to remove. See [Google Postmaster Tools](https://email-validation.org/guides/google-postmaster-tools/). ## How to process reports ### Prepare before you enroll RFC 6449, section 4.1, lists what to have ready: access to your `abuse@` and `postmaster@` addresses, because providers send confirmation links there, and a dedicated address for reports. Section 4.4 suggests a separate alias per feedback loop, so you always know which provider a report came from. ### Make every message traceable Providers may remove the recipient's address, so put your own identifier in each message when you send it. RFC 6449, section 4.4, suggests the local part of the `Message-ID`, as in `` above: campaign 42, message 981, recipient 55017. A VERP return path carries the same information, but some reports do not include it. Avoid identifiers that look like an email address, since redaction may remove them. ### Suppress the complainer at once RFC 6449, section 4.3.1, tells senders of commercial mail to treat a complaint like an unsubscribe. Stop mailing that person from the list, and if you run several segmented lists, suppress them across all of them. The RFC calls suppressing the address across a whole ESP, for every customer, likely too broad. Put the address on your [suppression list](https://email-validation.org/glossary/#suppression-list) so that an import or a sync from your CRM cannot add it back. Transactional mail is the exception that needs judgment. If someone reports a receipt or a ticket they bought, the RFC suggests deciding case by case, for example by asking them through your website whether they still want those messages. See [transactional vs marketing email](https://email-validation.org/guides/transactional-vs-marketing-email/). ### Look for the source Section 4.3.2 explains how to read the trend. Count reports per day, campaign and list. A spike from new subscribers points at how addresses were collected; a spike from long-time subscribers points at one message, its content or its branding. Check whether the people who complain signed up through one form, one partner or one import. ## Complaint rate thresholds | Provider | Published limit | |---|---| | Gmail | Keep the rate below 0.10% and never reach 0.30% ([email sender guidelines](https://support.google.com/mail/answer/81126)) | | Yahoo | Keep the rate below 0.3% ([sender best practices](https://senders.yahooinc.com/best-practices/)) | | Outlook.com | No published number; complaints are a main reputation factor | Your own figure will not match theirs exactly. Yahoo calculates the rate from mail delivered to the inbox, and Google counts messages that reached the inbox and were then marked as spam. RFC 6449, section 4.3.2, shows why the difference matters: 10 complaints on 10,000 sent messages look like 0.1%, but if only 500 reached the inbox, the provider sees 2%. It also notes that complaints are counted on the day people read the mail, so a quiet weekend after weekday sends can show a rate above 100%. ## How the complainer reason relates A feedback loop tells you after the fact that one of your recipients complained. Some people often report legitimate mail as spam. A check flags addresses believed to belong to such people with the reason [`complainer`](https://email-validation.org/docs/statuses/valid/#complainer): the status is `valid`, because the mailbox accepts mail, and the action is `remove`. Removing them before you send avoids complaints you would otherwise only see in a report. The page on [why complaints hurt](https://email-validation.org/docs/statuses/valid/#why-complaints-hurt) explains what reports do to your reputation. Neither tool replaces the basics. Many complaints come from people who do not expect your mail or cannot find the way out, so confirm sign-ups with [double opt-in](https://email-validation.org/guides/double-opt-in/) and offer [one-click unsubscribe](https://email-validation.org/guides/list-unsubscribe-one-click/). ## Questions ### Do I need to enroll if my email service provider handles complaints? Often not. Yahoo's FAQ says providers generally enroll their customers' domains and process the complaints. Ask yours whether it does, and whether it shows you the complaint counts. ### Why do I get fewer reports than Postmaster Tools suggests? Gmail sends no individual reports, and Microsoft and Yahoo send them only for the IPs or domains enrolled. Mail that was filtered to spam also draws few complaints, so a low count is not proof that recipients are happy. ### Should I email a complainer to ask why? No. RFC 6449 notes that senders rarely contact the person who complained, and that person has already told you they do not want your mail. Suppress the address and fix the cause. ## Try it Check a list with [bulk email verification](https://email-validation.org/bulk-email-verification/) and remove the rows whose action is `remove`, or try one address in the free [email checker](https://email-validation.org/email-checker/). ## Related - [The valid status: why complaints hurt](https://email-validation.org/docs/statuses/valid/#why-complaints-hurt). - [Glossary: complainer](https://email-validation.org/glossary/#complainer) and [sender reputation](https://email-validation.org/glossary/#sender-reputation). - [Statuses and actions](https://email-validation.org/docs/statuses/#actions). ## Related guides - [Microsoft SNDS and JMRP explained](https://email-validation.org/guides/microsoft-snds-jmrp/) - [How to use Google Postmaster Tools](https://email-validation.org/guides/google-postmaster-tools/) - [One-click unsubscribe and the List-Unsubscribe header](https://email-validation.org/guides/list-unsubscribe-one-click/) - [Sender reputation explained](https://email-validation.org/guides/sender-reputation/) - [Gmail and Yahoo sender requirements](https://email-validation.org/guides/gmail-yahoo-sender-requirements/) - [All guides](https://email-validation.org/guides/) ## Sources - [RFC 6449, Complaint Feedback Loop Operational Recommendations](https://www.rfc-editor.org/info/rfc6449/): sections 1, 4.1, 4.3 and 4.4 on how loops work, preparation, suppression, trends and identifiers. - [RFC 5965, An Extensible Format for Email Feedback Reports](https://www.rfc-editor.org/info/rfc5965/): sections 2 and 3, report structure and fields. - [RFC 6650, Creation and Use of Email Feedback Reports](https://www.rfc-editor.org/info/rfc6650/): sections 4.3 and 4.5, fields for complaint reports and handling rules. - [RFC 6590, Redaction of Potentially Sensitive Data from Mail Abuse Reports](https://www.rfc-editor.org/info/rfc6590/). - [Yahoo: Complaint Feedback Loop](https://senders.yahooinc.com/complaint-feedback-loop/) and [FAQs](https://senders.yahooinc.com/faqs/): eligibility, enrollment, ARF, ESPs. - [Yahoo: Sender best practices](https://senders.yahooinc.com/best-practices/): 0.3% limit, inbox-based rate. - [Google: Feedback Loop](https://support.google.com/mail/answer/6254652): the `Feedback-ID` header and aggregated reporting. - [Google: Postmaster Tools dashboards](https://support.google.com/mail/answer/14668346): spam rate and Feedback Loop dashboards. - [Google: Email sender guidelines](https://support.google.com/mail/answer/81126): spam rate targets. - [Microsoft: Postmaster troubleshooting](https://substrate.office.com/ip-domain-management-snds/postmaster/troubleshooting): complaint rate as a reputation factor. ## Get up to 500 free credits. No card needed. New accounts get 500 free credits (100 when you sign up with a free email provider such as Gmail, Outlook or Yahoo, or another personal mailbox such as a paid one like Fastmail or one from your internet provider). Try it on your own list before you buy. [Create your account](https://email-validation.org/signin/?new=1) or [open the free email checker](https://email-validation.org/email-checker/).