The traditional model requires per-ISP enrollment
For a self-hosted mail server, participating in feedback loops usually means separately enrolling with each major mailbox provider that offers one — the enrollment process, the report format, and even which providers offer an FBL at all vary, and providers that don't offer one give a sender no visibility into complaints from their users at all beyond indirect signals.
SES routes complaints through its own event system instead
Running through SES sidesteps most of that per-provider enrollment burden — AWS maintains its own relationships with major mailbox providers and surfaces a `Complaint` event through the same SNS/EventBridge event stream used for bounces and deliveries, in a consistent format regardless of which provider the complaint originated from. A configuration set determines where those complaint notifications actually route.
What arrives in a complaint event
A complaint notification typically carries the complaining recipient's address, the timestamp, and where available a complaint-type classification (abuse, fraud, virus, and so on) the reporting provider assigned. It does not carry the full context of why the recipient complained — that's inference a sender has to do from patterns across complaints, not something the event itself explains.
The action a feedback loop enables is suppression, immediately
The entire operational point of an FBL is enabling near-real-time suppression: an address that complains should stop receiving mail before the next send, not at the next manual list-cleanup pass. SES's automatic suppression-list behavior on complaint (the same mechanism used for hard bounces) is effectively feedback-loop handling built into the platform rather than logic a sender has to wire up separately.
Consuming the event stream is still a sender's own responsibility
SES surfacing a complaint event does not, by itself, do anything beyond adding the address to the suppression list — anything beyond that, like alerting a human when the complaint rate on a specific campaign spikes, or correlating complaints against a recent content or list-source change, requires a consumer actually subscribed to that configuration set's event destination and watching for it.
Why it matters
Feedback loops are the mechanism that turns a recipient's spam-button click into an actionable signal rather than an invisible one — without one, a sender has no way to know a specific recipient complained at all, and keeps mailing them indefinitely while their complaint rate silently climbs somewhere the sender can't see.
How to check it
aws sesv2 get-configuration-set-event-destinations --configuration-set-name <name>Common questions
Do I need to enroll in feedback loops separately when using SES?
No. AWS maintains the provider relationships and surfaces complaints through its own SNS/EventBridge event stream in a consistent format, which sidesteps the per-provider enrollment self-hosted senders otherwise have to manage individually.
What information does a complaint event actually include?
The complaining recipient's address, a timestamp, and where the reporting provider supplies one, a complaint-type classification. It doesn't include why the recipient complained — that has to be inferred from patterns across complaints, not read off a single event.
Does SES automatically suppress an address after a complaint?
Yes, the same account-level suppression mechanism used for hard bounces applies to complaints, which means the near-real-time suppression a feedback loop exists to enable is built into the platform rather than something you have to implement yourself.