# Complaint feedback loops

A feedback loop is an arrangement with a mailbox provider under which complaints — someone pressing 'report spam' — are forwarded back to the sender, usually as a structured abuse report. The correct response is a permanent, immediate opt-out with no exceptions and no appeal, because the person chose the harsher of the two available buttons.

- **Status:** Reference
- **Audience:** both
- **Channels:** email
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/technology/feedback-loop/

## What actually arrives

Most feedback loops deliver an Abuse Reporting Format message: a multipart report carrying a machine-readable section (the report type, the arrival date, the reporting provider) and a copy of the original message or at least its headers. It goes to an address you registered, not to the envelope sender.

Two details shape everything you can do with it. First, many providers redact the complaining recipient's address, so the report tells you a complaint happened without telling you who. Second, at least one very large provider offers no per-message loop at all and instead reports aggregate complaint rates, keyed by an identifier the sender puts in a header — a view of the trend with no way to act on a single case.

The consequence is that matching a report back to a recipient is the sender's problem, solved by putting your own opaque identifier into each message — a per-recipient envelope sender, or a header the report echoes back — before you need it rather than after.

## The response, and the responses that look reasonable but are not

| Reaction | Verdict |
|---|---|
| Suppress the address permanently, everywhere, across every list and channel | Correct, and it should be automatic |
| Remove from the one campaign that generated the complaint | Wrong. The person did not object to a campaign, they objected to you |
| Send a 'sorry to see you go' confirmation | Wrong. It is one more unwanted message to someone who just said so in the strongest way available |
| Treat it as equivalent to an unsubscribe click | Understated. Both stop the mail; only one of them also damages your sending reputation |
| Investigate why consent was weak enough to produce it | Correct, and the part usually skipped |

> **Note** A complaint on a genuinely transactional message — a receipt, a password reset — is a signal that something upstream is wrong: the recipient did not recognise the sender, or a marketing message was dressed as transactional. Suppressing the address then quietly breaks the service mail that person may actually need.

## Registration and its limits

- Loops are per provider, and enrolment is usually tied to the sending IP addresses or the signing domain — which means a business sending through a shared platform is often covered by that platform's enrolment rather than its own.
- Not every provider runs one. Coverage is best at the largest consumer mailbox providers and thin everywhere else, so a complaint rate computed from feedback loops is a sample, not a census.
- Reports can lag. A complaint arriving days later against a message you have already counted as successful is normal.
- Volume is small in absolute terms and heavy in meaning. Complaint rates that matter are fractions of a percent, so a handful of reports against a modest send is already a warning.

## Does Connect use feedback loops?

Not as a registered participant. Connect does not enrol a workspace in any provider's feedback loop, does not receive abuse reports on a workspace's behalf and does not parse them. Enrolment is an arrangement between the domain or IP owner and the provider.

What exists in Connect is the enforcement side, and it is deliberately blunt. Suppression, unsubscribe, complaints and do-not-contact are checked in one place before any outreach leaves, and the **Connect Assistant cannot clear a do-not-contact entry** — that is a human decision by design, so a conversational instruction cannot undo a hard stop.

Blocking someone is stored as a Memory row tagged for the channel rather than written into the text of a note, because only the tag list is read when directives are resolved. That is what makes a block hold across channels and across future conversations instead of being forgotten with the thread it was set on. If you learn about a complaint through your own mailbox, recording it here is what makes it stick.

## Questions

### Someone complained about a message they asked for. What now?

Suppress them anyway, then look at why they did not recognise the message. The usual causes are a long gap since the last contact, a sender name that does not match the business they know, or a request captured in a way they would not remember agreeing to. Arguing with a complaint is never the move; the provider has already recorded it.

### Can I find out who complained?

Sometimes. Several providers redact the recipient, so the reliable method is to include your own per-recipient identifier in the message before you send it and match on that when a report comes back. Retrofitting this after the first surprising report is the common order of events and it does not work for the reports you already have.

### Does a complaint affect delivery to other people?

Yes, and that is why the rate matters more than the individual case. Providers assess a sender across their whole user base, so complaints from one badly sourced batch affect mail to everyone else at that provider, including messages that would otherwise have been welcome.

## Related

- [Suppression lists](https://connectbyjbrh.com/docs/technology/suppression/)
- [One-click unsubscribe](https://connectbyjbrh.com/docs/technology/unsubscribe/)
- [Email deliverability](https://connectbyjbrh.com/docs/technology/deliverability/)
- [Bounces](https://connectbyjbrh.com/docs/technology/bounce/)
- [Memory in Connect](https://connectbyjbrh.com/docs/memory/)

## What this page is based on

- RFC 5965 — An Extensible Format for Email Feedback Reports (https://www.rfc-editor.org/rfc/rfc5965)
- RFC 6449 — Complaint Feedback Loop Operational Recommendations (https://www.rfc-editor.org/rfc/rfc6449)
- Source pack: email — `docs-source/sources/CHANNELS.md` §1 (compliance, blocking as a tagged memory row)
- Connect capability registry (`docs-source/facts.py`)