## TL;DR

Bounces are machine mail, not human replies, and they all carry standard markers. Check for delivery-status content and auto-generated bounce headers before any engagement classification, mark the address undeliverable, and halt the sequence for that lead. Following up on a dead address burns sender reputation for zero possible return.

```
agent couldn't tell the difference between a bounce notification and a human reply, so it kept following up on dead addresses
```

## Steps

1. Sample the misclassified messages and confirm they are bounces: look for "delivery status notification", "undelivered mail returned to sender", "message blocked", or diagnostic codes like 550 and 554.
   Expected: the "human replies" are provably machine-generated bounces.

2. Add bounce detection as the first classification stage: check the content type for delivery-status parts, match known bounce sender patterns and subject lines, and scan for SMTP diagnostic codes. Any hit means "not a human reply".
   Expected: bounces never reach the engagement or objection classifier.

3. Classify hard vs soft: 5xx codes and "user unknown", "mailbox unavailable", "domain not found" are hard bounces. 4xx codes, "mailbox full", and "temporarily deferred" are soft.
   Expected: each bounce gets a hard or soft label, not just "bounced".

4. On a hard bounce, mark the address undeliverable, remove the lead from active sequences, and log the diagnostic code. On a soft bounce, keep the lead in sequence but cap retries (3 attempts is sane) and back off between them.
   Expected: dead addresses stop receiving mail; temporarily failing ones get limited retries.

5. Audit the incident window: find every lead whose sequence continued after a hard bounce and suppress the dead addresses now. Check sender reputation metrics for the damage window.
   Expected: no active sequence points at a known-dead address.

## Use this when

- Follow-ups continue after delivery failures
- Bounce messages appear in reply logs as engagement
- Sender reputation dropped after mailing dead addresses

## Not for this skill when

- The message is an out-of-office auto-reply (auto-reply detector)
- The message is an opt-out (suppression path)
- The issue is soft-bounce retry policy specifically (tune the retry cap, the detector already works)
- Bounces are not being received at all (check the return-path and bounce inbox configuration)

## Variant phrasings

- "agent followed up on bounced addresses"
- "bounce notification classified as human reply"
- "dead addresses kept getting sequence emails"

## Why it happens

The reply pipeline ingested everything in the reply mailbox as a "reply". Bounce notifications land in the same mailbox as human responses, and a classifier looking for engagement signals will happily score phrases inside a quoted bounce ("thank you") as positive. Nobody added the machine-mail filter at the intake, so dead addresses looked alive.

## Edge cases

- Challenge-response spam filters ("click here to prove you are human") are machine mail that is not a bounce. Classify as machine, do not engage, and consider suppressing the address.
- A soft bounce that persists past the retry cap should graduate to hard. Do not retry forever.
- Internationalized bounce messages need localized patterns; English-only matching misses them.
- Some providers send bounces asynchronously, hours after the send. The detector must run on every inbound message, not just messages arriving right after a send.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_g292XYeDwSwKPCATRrQzLw