Reading Feedback Loop Complaint Reports: Turning ARF Mail and SES Notifications Into a Suppression List

Collect the reports in one place, pull the complainant (or the Message-ID if it's redacted) out of each, suppress all of them on every platform at once, then group the complaints by subject, Feedback-ID and sending IP to find the campaign that drew them.

The feedback loop report parser reads pasted ARF messages and SES complaint JSON in your browser and gives you the suppression list and the groupings. Sources, read 2 November 2026: RFC 5965, the Amazon SES sending review FAQ (complaint section), Yahoo's Sender Hub FAQ and Google's Feedback Loop help.

Where the reports come from

Source	Format	How you get it
Yahoo (and AOL) CFL	ARF email	Enrol the DKIM d= domain in the Complaint Feedback Loop
Other providers' FBLs	ARF email, usually	Each provider's own enrolment
Amazon SES	JSON notification by email or SNS	Complaint notifications on the identity
Gmail	No per-message reports	Aggregate spam rate per Feedback-ID in Postmaster Tools

An ESP usually handles feedback loops for you and suppresses complainants automatically. The reports matter most if you run your own mail server, send through SES, or want to know which campaign drew the complaints. Background: email feedback loops explained.

Step by step

1. Gather the reports. Export the FBL mailbox as .mbox or .eml, or collect SES notifications from email or SNS.
2. Read each one. From ARF: Feedback-Type (usually abuse), Source-IP, Arrival-Date, Original-Rcpt-To, and the reported message's Subject, Message-ID, Feedback-ID, List-Unsubscribe and any X- campaign header you set. From SES JSON: complainedRecipients and complaintFeedbackType.
3. Resolve redacted recipients through the Message-ID or your own header in your sending logs. SES suggests storing that mapping for every message precisely because some providers strip the address.
4. Suppress everyone on every platform you send from. SES says to stop mailing them immediately and not even send an "you've been unsubscribed" email.
5. Group the complaints. One subject or one Feedback-ID: a campaign problem. One IP: a stream problem. Spread evenly: a list or permission problem.
6. Fix the cause. SES puts it bluntly: for every person who complains there are potentially dozens who didn't appreciate the mail and didn't complain.

What the counts tell you

Complaints are a sample, not the whole story. Providers without a feedback loop send nothing, and SES says its complaint rate only covers domains that send it feedback. If the reports cluster on one send, look at who got that send and how they signed up; see SES direct complaints review for the case where recipients complain to SES itself, and re-permission campaigns for a segment you're unsure about. For Gmail, add a Feedback-ID header to see spam rate per campaign.

Limits

The parser reads what you paste. Redacted recipients can't be recovered from the report itself, only from your own logs. Vendor-specific complaint webhooks may need converting to ARF or SES JSON first. And it can't tell you who else will complain; only permission fixes that.

Where SimpleVerifier fits

Verification doesn't stop complaints; real people who didn't expect the mail cause them. It does stop the same segment from bouncing when you send a re-permission email to it: upload it at /verify first. The first 100 checks are free with a Google sign-in. Pro is $39 a month with the first 100,000 checks a month at full speed, then slower, never cut off. See pricing.