A feedback loop tells you which recipient marked your message as spam, so you can suppress that address before you mail it again. Two of the four large mailbox providers send you that report: Yahoo and Microsoft. Gmail runs something it also calls a Feedback Loop, and it is a different thing, an aggregate spam rate per campaign with no addresses in it. Apple offers none and says so in writing.
That split is the whole subject. Advice that treats "sign up for the feedback loops" as one task sends you looking for a Gmail complaint feed that has never existed.
A feedback loop is a complaint report, and RFC 5965 defines its format
The report format is the Abuse Reporting Format, defined by RFC 5965 in August 2010 and refined by RFC 6650 in June 2012. An ARF message is a multipart report carrying a machine-readable block plus the original message, or the parts of it the provider is willing to hand back.
RFC 6449, published November 2011 by the Messaging Anti-Abuse Working Group, is the operational document, and it is candid about the limits. Providers redact information deemed private, and some redact the recipient's address itself, which turns a suppression feed into a volume counter. Read what a provider actually sends before you build a pipeline that assumes an address will be in it.
The economics are worth stating once. A complaint is a recipient telling their provider that your mail is unwanted. The provider is under no obligation to tell you, and every feedback loop is a voluntary program with an application, terms of use, and the right to say no.
Yahoo keys its Complaint Feedback Loop on your DKIM domain
Yahoo's program is domain based, and it is explicit about the requirement: the Complaint Feedback Loop program only supports DKIM-signed email. Senders must sign outbound mail with DKIM so that Yahoo can determine the actual sender.
When a message signed with an enrolled DKIM key is marked as spam, Yahoo sends the enrolled address a report in ARF so the sender can suppress that recipient from further campaigns. Enrollment is three steps: create a sender profile, add and verify your domain, then enroll the domain.
Keying on the DKIM domain has a consequence worth planning for. If your platform signs every customer's mail with one shared d= domain, enrolling that domain pools every customer's complaints into one feed, and separating them again is your problem. Signing each customer on their own domain is what makes the feed actionable.
Microsoft keys JMRP on an IP you prove you control, and moved the portal in 2026
Microsoft's Junk Email Reporting Program is part of Smart Network Data Services, and the pairing is the point: SNDS gives senders data about individual IPs, and JMRP lets you receive reports when users junk your messages. Both are keyed on IP address, and access begins by requesting the IPs you are responsible for and passing an authorization check.
Three changes landed in 2026 and the announcements are dated 6 July 2026. SNDS moved to a new portal, replacing the long-standing address under sendersupport.olc.protection.outlook.com. Automated access URLs on that old host were marked for deprecation by 22 June 2026, so a script pointed at the old endpoint stops working rather than degrading. And trap hit counts were removed from the Data Report from 22 July 2026, with a warning that values reported during the transition may differ from previous reports and should not be read as exact.
Keying on IP decides who can use it. If you send through a shared pool at an email service provider, the IPs are not yours to claim, and the enrollment belongs to that provider. Ask them whether they are enrolled and what they do with the reports, because the answer determines whether a complaint at Outlook.com ever reaches your suppression list.
Gmail's Feedback Loop is aggregate, and never names a recipient
Gmail's FBL reports which of your campaigns are drawing complaints, not who complained. It is built on a header you add yourself, and the rules are specific.
The header is Feedback-ID and its value is four colon-separated fields. The last field, the SenderId, is mandatory, 5 to 15 characters, and must stay consistent across your mail stream. The first three are optional identifiers you choose, typically campaign, customer and mail type. Aggregate data is generated for the first four fields counting from the right, and if the SenderId is empty no data is generated at all.
Four conditions gate the data, and missing any one produces silence rather than an error:
- The traffic must be DKIM signed by a domain you own or control, after the header is added. Signing before the header leaves it unprotected, and the anti-spoofing check is the reason the requirement exists.
- That signing domain must be added and verified in Google Postmaster Tools, which is where the FBL dashboard appears. Only one such verified header should be present.
- The signing domain's SPF record must list the IPs you send from, and those IPs need PTR records resolving to a valid hostname.
- An identifier only gets a report once a day's traffic carries it in sufficient volume and in distinct user spam reports.
Two authoring mistakes are worth naming. Do not use a value that is unique per message, such as a Message-ID, because an identifier that never repeats can never aggregate. And do not repeat the same identifier across different fields, or unrelated traffic is summed together.
The data covers @gmail.com recipients only. What you get back is a rate against a campaign, which is a diagnostic. It is not a suppression feed, and no configuration produces one.
Apple does not offer a feedback loop, and says so
Apple's postmaster page for iCloud Mail answers it directly: iCloud Mail does not offer a feedback loop. There is no application to file and no queue to join.
What Apple asks instead is a list of sending hygiene requirements, and it treats them as conditions of bulk delivery rather than suggestions: mail only to recipients who explicitly subscribed, an unsubscribe link that works immediately, ARC headers on forwarded mail, compliance with RFC 5321 and RFC 5322, reverse DNS published for your sending IPs, and consistent sending IPs and domains.
What each provider actually gives you
| Provider | Keyed on | What arrives | Names the recipient |
|---|---|---|---|
| Yahoo CFL | Your DKIM d= domain | One ARF report per complaint | Yes |
| Microsoft JMRP | An IP you prove you control | One ARF report per complaint | Yes |
| Gmail FBL | Feedback-ID plus a verified Postmaster Tools domain | An aggregate rate per identifier | No |
| Apple iCloud | Nothing | Nothing | Not applicable |
A complaint report is only useful if it suppresses the address that day
RFC 6449 is blunt about the first job: the address in a complaint comes off your list. Counting complaints and acting on them are different projects, and only the second one changes anything.
Three habits separate a working feedback loop from a folder of unread mail:
- Suppress on receipt, globally, not per campaign. A recipient who complained about a newsletter did not consent to the next product announcement.
- Keep the report, not just the address. The ARF block carries the arrival date and often the original headers, which is what lets you trace a complaint spike back to a specific send rather than to a bad week.
- Watch the rate per stream, not the total. One transactional stream and one marketing stream averaged together hide the one that is failing.
The complaint-rate thresholds the large providers publish, and what happens when you cross them, are covered in our guide to the Gmail and Yahoo bulk sender requirements.
What to check before you apply for any of them
Every program above rests on authentication you either have or do not, and an application that fails these checks is rejected without much explanation.
- DKIM on a domain you control. Yahoo keys its entire program on it and Gmail requires it to trust your header. Our DKIM checker reads the published key and its length. Across the domains we test for the Unspam 2026 Email Deliverability Benchmark, 90% of the domains we test sign with a working DKIM.
- SPF listing every IP you actually send from, on the signing domain rather than only on the visible From domain. Our SPF checker walks the includes and counts the lookups against the limit that voids a record.
- Reverse DNS on your sending IPs, resolving to a real hostname. 99% of the domains we test already have valid reverse DNS, which makes the 1% that do not an easy application to lose.
- Exactly one
Feedback-IDheader. Our email header analyzer shows what a real message carries, which is where a duplicate added by a middlebox becomes visible.
To see the authentication and headers on a message as a receiver sees them, run a free spam test.
