# Handling a bounce, end to end

A bounce says the message did not reach the recipient, and the first job is to decide whether that is permanent or temporary. A permanent bounce suppresses the recipient and changes what the person's record claims about reaching them. A temporary one leaves it alone. Neither produces an automatic loop of re-sends, and neither is a reason to invent a different one.

- **Status:** Available
- **Audience:** both
- **Channels:** email
- **In the app:** #/inbox, #/relationships, #/prospects
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/workflows/bounce-handling/

## The flow, stage by stage

1. Trigger — a message that was accepted for delivery is returned or reported as undeliverable.
2. External event — the receiving side tells the sending side, either in a returned message or in a provider notification.
3. Authentication and workspace resolution — the report is matched to the mailbox that sent the original, and the mailbox names the workspace.
4. Ingest — the report is normalised to two facts: which address failed, and whether the failure is permanent.
5. Canonical record — the outcome is written against the message that was sent, so the thread shows what happened rather than showing a message that appears delivered.
6. Classification and reasoning — permanent or temporary. Everything downstream depends on this one decision, so it is made from what the report says rather than from a guess.
7. Knowledge, memory and rules — the person's record is updated where the failure is permanent, because contactability is a fact about the relationship.
8. Autonomy and approval — unaffected. A bounce is an outcome, not a permission question.
9. Action through a provider — none. Nothing is sent in response to a bounce, and no address is probed to find a working one.
10. Result — for a permanent failure, a suppression carrying `bounce` as its origin; for a temporary one, a failed message with its reason and nothing else.
11. Relationship, timeline and memory — the failure is visible on the person, so the next person to open the record knows the address does not work.
12. Audit, usage and Needs You — the outcome is recorded, and repeated failures against one mailbox surface as an operational problem rather than as a run of unlucky messages.

## Permanent and temporary

| Classification | Typical meaning | What changes | Retry |
|---|---|---|---|
| Permanent | The recipient does not exist, or the receiving side refuses it outright | A suppression with `bounce` as its origin; it is no longer treated as reachable | Never — it is wrong, and repetition cannot make it right |
| Temporary | The mailbox is full, or the receiving server declined for now | The message is recorded as failed with its reason; the recipient keeps their standing | Not automatic — the work that produced the message is what may run again later |
| Unclassifiable | The report does not say clearly | Recorded as a failure without a suppression | A person decides; nothing is assumed in either direction |

Suppressing on a temporary failure would delete a real relationship because somebody's inbox was full on a Tuesday. Not suppressing on a permanent one leaves a workspace sending into an address that has not existed for a year, collecting failures that make its other mail less likely to arrive. The classification is therefore the whole of the work.

## What a bounce is not permission to do

- **Not permission to guess another one.** A bounced address is evidence that it is wrong, not a hint about what the right one is. Connect does not construct an address from a name and a domain, and a bounce does not change that.
- **Not permission to re-send the same message harder.** A clean failure can be sent again once its cause is fixed; a repeated attempt against a permanent failure is a message to nobody and a mark against the mailbox.
- **Not a reply to write.** Nothing outbound is generated by a bounce, and there is nobody at the failing address to receive it.
- **Not a reason to delete the person.** The relationship, the history and the company link survive; what changes is that one address does not work.

> **Note** For a prospect, the honest consequence is a contactability change: the organisation may still be worth approaching, and the route to them is not this address. Evidence-first prospecting treats that as a research result rather than as a dead end.

## What you see, and what to do

1. Open the thread. A bounced message shows its outcome rather than reading as delivered.
   - Result: You are not left comparing your sent folder against a silence to work out what happened.
2. Read the classification before acting.
   - Result: Permanent and temporary need opposite responses, and acting on the wrong one is how a good address gets suppressed or a dead one gets hammered.
3. For a permanent bounce, look for another route to the person on their record.
   - Result: A person can hold identities on more than one channel, and the timeline shows which of them has actually worked.
4. For repeated temporary failures across many recipients, treat it as a mailbox health question.
   - Result: A pattern spread across recipients is about the sender or its provider, not about the people being written to.

## Failure modes

**The bounce cannot be matched to a message** — The address is still recorded as having failed. Matching to the original is a convenience; the failure is the fact.
**A bounce arrives long after the send** — It is recorded when it arrives. Nothing already delivered elsewhere is affected, and nothing is re-sent to compensate.
**An address bounces and later works** — Clearing the suppression is a deliberate act with a visible origin, the same as clearing any other.
**A sequence continues after a bounce** — Check whether the failure was classified as temporary. A permanent one stops the sequence through the suppression rather than through the sequence's own logic.

## Questions

### Does Connect try a different address after a bounce?

No. An address that failed is evidence about itself and nothing else. Connect does not construct or guess one from a name and a domain, and a bounce is not treated as an invitation to start.

### Why was a full mailbox not suppressed?

Because that failure is temporary. Suppressing on it would remove a working relationship because somebody was over quota for a day, which is a permanent response to a passing condition.

### Is the person deleted when their address bounces permanently?

No. The person, their history and their company link all stay. What changes is that one address is no longer treated as a way to reach them, and their record shows why.

## Related

- [Bounces](https://connectbyjbrh.com/docs/email/bounces/)
- [Applying a suppression, end to end](https://connectbyjbrh.com/docs/workflows/suppression-application/)
- [Deliverability](https://connectbyjbrh.com/docs/email/deliverability/)
- [Contactability](https://connectbyjbrh.com/docs/prospects/contactability/)
- [Evidence-first prospecting without guessed emails](https://connectbyjbrh.com/research/evidence-first-prospecting/)

## What this page is based on

- CHANNELS.md §1 — compliance and the single pre-outreach check
- CHANNELS.md §4 — prospecting, contactability and evidence
- `backend/app/comms.py`, `prospect_compliance.py`, `prospect_contacts.py`
- Connect capability registry (docs-source/facts.py) — `suppression_dnc`, `no_guessed_email`