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

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.

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

1. 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".

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

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