# Feedback loop (FBL): Definition and How It Works

Source: https://wraps.dev/glossary/feedback-loop

A feedback loop is a mailbox provider's mechanism for forwarding a recipient's spam complaint back to the sending infrastructure, so the address can be suppressed and the underlying cause investigated.

## 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.