By the time an IP lands on a blacklist, the complaints that put it there are already weeks old, and you never saw them. A feedback loop closes that gap. When a recipient marks your message as junk, the mailbox provider forwards you the complaint while you still have room to pause the campaign, suspend the account, or scrub the list before a provider or a blocklist reaches its own verdict.
What Comes Back When Someone Hits Spam
The complaint arrives as an ARF report: the Abuse Reporting Format defined in RFC 5965. It is a multipart/report message with three parts, in this order: a human-readable note, a machine-readable message/feedback-report block, and the offending message. All three are required, though the third can be the full message as message/rfc822 or the headers alone as text/rfc822-headers, which is the form Microsoft now sends. The middle part is the one your parser reads.
Content-Type: multipart/report; report-type=feedback-report;
boundary="=_fbl_9f8c2a1b"
--=_fbl_9f8c2a1b
Content-Type: text/plain; charset="US-ASCII"
This is an abuse report for a message received from 203.0.113.10
on Fri, 14 Aug 2026 09:12:44 +0000.
--=_fbl_9f8c2a1b
Content-Type: message/feedback-report
Feedback-Type: abuse
User-Agent: ExampleProvider-FBL/2.0
Version: 1
Original-Mail-From: <bounce@mail.example.com>
Arrival-Date: Fri, 14 Aug 2026 09:12:44 +0000
Source-IP: 203.0.113.10
Reported-Domain: mail.example.com
--=_fbl_9f8c2a1b
Content-Type: message/rfc822
Message-ID: <20260814091200.5b2e@mail.example.com>
Feedback-ID: newsletter:acct-4821:promo-aug:s5xk2mailco
X-Recipient-Id: r-9f8c2a1b7e4d
--=_fbl_9f8c2a1b--
Three fields in message/feedback-report are required and appear exactly once: Feedback-Type, User-Agent, and Version. Feedback-Type: abuse is the one you act on. The rest of that block is optional context; the message/rfc822 part is where the identifiers you care about live, assuming the provider left them there.
What Each Provider Actually Sends
Coverage is thinner than most senders expect, and the differences decide whether you can suppress a single recipient or only spot a bad campaign after it has already gone out.
| Provider | FBL Type | What You Get | The Catch |
|---|---|---|---|
| Yahoo | Per-complaint ARF | The recipient address, so you can suppress directly | Enroll your sending IPs |
| Microsoft (JMRP) | Per-complaint ARF | Header-only since June 11, 2026; the X-HmXmrOriginalRecipient header and the body are gone |
Your custom X-headers survive, but a value that looks like an email address is redacted too, which breaks VERP-style attribution |
| Gmail | Aggregate only | A campaign-level spam rate keyed off the Feedback-ID header |
No per-complaint report exists; you never learn which recipient |
| Apple (iCloud) | None | Nothing | There is no feedback loop to enroll in |
Microsoft's move to header-only reports, covered in our note on the Microsoft SNDS 2026 changes, is the one that catches people. Build your complaint handling for that case and Yahoo's fuller report costs you nothing extra. Gmail is a different tool entirely: it tells you a campaign drew complaints, never who complained, so it points you at a stream to tune and never at an address to suppress.
Build the Message So You Can Trace the Complaint
When the recipient comes back (Yahoo), suppression is a lookup. When it does not (Microsoft), you recover the recipient from identifiers you stamped on the message yourself. Set them at send time on every message:
Message-ID: <20260814091200.5b2e@mail.example.com>
Feedback-ID: newsletter:acct-4821:promo-aug:s5xk2mailco
X-Recipient-Id: r-9f8c2a1b7e4d
Message-ID keys back to the exact send in your log, which recovers the recipient and the campaign. X-Recipient-Id is a per-recipient token you generate: keep it opaque, a short hash. That stops it leaking PII in a forwarded report, and it survives Microsoft, which redacts any header value that parses as an email address. A VERP return-path does the same job in the envelope. Feedback-ID follows Google's a:b:c:SenderId layout: three optional fields for mail type, customer, and campaign, then a mandatory SenderId of 5 to 15 characters that stays constant across your mail stream. It has to be in place before you DKIM-sign, since Gmail attributes on the signed header.
None of this works without authentication underneath it, which is why getting SPF, DKIM, and DMARC right comes first.
Stop the Complaint Before It Happens: One-Click Unsubscribe
Every complaint counts against your sender reputation, even the ones you process cleanly. An unsubscribe you make easy is a complaint that never gets filed. Since February 2024, Google and Yahoo have required bulk senders to authenticate with SPF, DKIM, and DMARC, and to offer one-click unsubscribe on marketing and subscribed mail, honored within two days. Google draws its bulk line at 5,000 messages a day to Gmail accounts. Yahoo publishes no equivalent number, so the 5,000 figure is Google's alone. RFC 8058 defines the mechanism:
List-Unsubscribe: <https://mail.example.com/u/9f8c2a1b7e4d>,
<mailto:unsub@mail.example.com?subject=r-9f8c2a1b7e4d>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
The value is fixed: List-Unsubscribe-Post: List-Unsubscribe=One-Click, and both headers must be covered by your DKIM signature. The mail client renders an unsubscribe control, and a single POST to the HTTPS URL removes the recipient with no confirmation page in between. CAN-SPAM still allows up to 10 business days to process an opt-out, but at bulk scale you honor these fast for a practical reason: an unsubscribe link people cannot find sends them to the spam button instead, which is exactly the complaint you were trying to avoid.
Acting on the Stream
Process reports automatically. A complaint suppresses that recipient from future sends on the spot, because mailing someone again after they flagged you is the surest way to earn a second complaint. Past suppression, watch the shape of the stream. A spike tied to one campaign, one customer, or one compromised account is a signal to dig into that stream now.
Set a threshold and page on it. Google's guidance is to keep your spam rate under 0.10 percent and never let it reach 0.30 percent, and your own baseline usually sits well below that, so a climb toward the line deserves the same alarm you would wire on any error-rate spike.
Pair Complaints With Blacklist Monitoring
An FBL watches the cause; a blacklist listing is the effect that shows up later, sometimes without any complaint behind it at all. Running both means a complaint spike and a listing each get caught by the tool that sees it first. Generator Labs blacklist monitoring tracks your IPs and domains across hundreds of data sources, so if complaints ever do tip into a listing, you can tie it straight back to the stream your FBL already flagged. It runs alongside SSL certificate monitoring on the same sending hosts, since an expired mail-server certificate is another quiet way delivery stops. Before any of it, a quick email health check confirms the authentication that makes complaint mapping possible in the first place. Start monitoring.