Bounces, complaints, and the suppression list your agent cannot argue with

Every sending domain that gets into trouble got there the same way: it kept sending to addresses that had already said no, in one of the four ways an address can say no. Handling those four correctly is most of what separates a domain that stays deliverable from one that quietly stops working.

29 July 2026 · 5 min read

The four signals, and what each one means#

Confusing the first two is the most common technical mistake. Treating a soft bounce as permanent loses you real recipients whose mailbox was briefly full. Treating a hard bounce as temporary is worse: repeated sends to addresses that do not exist are one of the clearest signals a mailbox provider has that a sender is not paying attention.

Complaints are in a different category again, because they are a judgement rather than a delivery fact. One is noise. A rate is a verdict, and the fix is never "send more carefully to that person", it is to look at what the agent has been sending to everyone.

What the platform enforces, so your agent cannot get it wrong#

Suppression is not advice, it is a refusal. An address that previously bounced or complained produces recipient_suppressed on any further attempt, listing the addresses in question, and the send does not happen. Cold sends carry a signed one-click List-Unsubscribe link, and using it suppresses that address for your workspace immediately, with later sends rejected before they ever reach the sending infrastructure.

That placement is the point. A model can be persuaded, distracted, or simply wrong; an enforced refusal cannot. It is the same principle as everything in keeping an autonomous agent from becoming a spam problem: the rules whose violation is expensive belong under the tool.

What your agent still has to do#

Enforcement stops the send. It does not stop the underlying problem, and three things remain yours.

React to the events. Register a webhook and handle message.bounced and message.complained: mark the contact, stop the workflow that was in progress, and tell whoever needs to know. A collections chase that keeps running against an address that hard bounced is a workflow that will never succeed, and nobody notices until someone asks why that invoice was never paid.

Read a refusal properly. recipient_suppressed means stop and escalate, not retry with a different subject line. The habit of treating refusal reasons as information is worth building into the prompt, per the system prompt for an email agent.

Honour the informal no. A reply saying "stop emailing me" or "remove me" counts legally and counts practically, and it does not go through the unsubscribe link. Detect the obvious phrasings, suppress, and escalate anything ambiguous to a person rather than guessing. The legal shape of this is in the compliance floor.

{
  "type": "message.bounced",
  "message_id": "msg_...",
  "to": "typo@custmoer.com",
  "reason": "mailbox_not_found",
  "permanent": true
}

Where bad addresses come from#

Suppression is a cure. The prevention is caring where addresses came from, and agents make this easier than marketing tooling does, because an agent's recipients are usually people who wrote first.

The dangerous sources, in rough order: addresses guessed from a naming pattern, addresses scraped from a website, addresses inferred by a model from a company name, and lists imported from anywhere at all. Guessing firstname.lastname@company.com is a hard bounce generator and occasionally a spam trap, and a spam trap is close to unrecoverable because it is an address that exists specifically to catch senders who guess.

An agent that only ever writes to people who have written to it will effectively never see a hard bounce, which is the strongest argument there is for shipping an inbound use case first, as in the warmup plan.

Reading the numbers#

Watch these weekly, per sending domain, not in aggregate across everything you send.

• Hard bounce rate. Should be near zero. Sustained above a fraction of a percent means your address sources are wrong, and no amount of careful sending fixes that.
• Complaint rate. Target zero. Anything you can see on a chart is already a problem.
• Soft bounce pattern. A cluster at one provider is a reputation signal, not a coincidence.
• Suppression list growth. Steady growth on an inbound agent means something upstream is sending where it should not.

If any of them move, stop expanding volume before you investigate, per deliverability for agent senders.

A short runbook#

1. Register webhooks for message.bounced and message.complained on day one.
2. On a permanent bounce, mark the contact, stop the workflow, and let a human see the pattern.
3. On a complaint, stop that recipient permanently and review what the agent has been sending to everyone.
4. Detect "stop" in replies and suppress on it; escalate ambiguity.
5. Never retry a recipient_suppressed refusal.
6. Watch the four numbers weekly, per domain.
7. Fix the source of bad addresses rather than the symptom.

Questions#

What is the difference between a hard and a soft bounce?

A hard bounce means the address does not exist and you must never send there again. A soft bounce is temporary, such as a full mailbox, and can be retried a few times before you give up.

Does the platform enforce suppression, or does my agent?

The platform. An address that bounced or complained produces recipient_suppressed and the send does not happen, so enforcement does not depend on the agent remembering.

What happens when someone clicks unsubscribe?

Cold sends carry a signed one-click List-Unsubscribe link, and using it suppresses that address for your workspace immediately. Later sends to it are rejected before reaching the sending infrastructure.

Does a reply saying "stop" count as an unsubscribe?

Yes, legally and practically. Detect the obvious phrasings, suppress on them, and escalate anything ambiguous to a person instead of guessing.

What bounce rate is acceptable?

Near zero for hard bounces. Anything sustained above a fraction of a percent means the addresses are not coming from real conversations, and that is a sourcing problem rather than a sending problem.

What should my agent do when a send is refused as suppressed?

Stop and escalate. Not retry, not rephrase. The refusal is protecting the domain the agent depends on.