Bounces
A bounce arrives after a send has already been accepted, so a message can be genuinely sent and still fail to arrive — the two are separate records. A permanent failure ends with the address suppressed, so nothing further is sent to it; a temporary failure is a result on that one message and does not condemn the address. Clearing a suppression is a person's decision.
A bounce is not a failed send#
Connect reports a message as sent only when the provider has acknowledged it, and there is a third state — uncertain — shown as uncertain rather than guessed either way, because re-sending on a maybe is how somebody receives the same reply twice. A bounce sits after all of that. The provider took the message, said so, and the receiving side rejected it afterwards.
That ordering matters when you are reading a thread. The sent record is still true; what changed is what happened to the message next. A send that failed at the moment of sending is a different problem with a different page — see a send that failed and an uncertain send.
Permanent and temporary#
| Kind | What the receiving side is saying | What it means afterwards |
|---|---|---|
| Permanent (hard) | No such recipient, or mail from you will never be accepted | The recipient is taken out of use: it is suppressed, and outreach to it stops |
| Temporary (soft) | Not now — the mailbox is full, the server is busy, the message was too large | Nothing. The result belongs to that one message |
The classification comes from the receiving side and reaches Connect through the sending provider, which is why the wording differs between providers for what is fundamentally the same rejection. Connect records what the provider reports rather than re-deciding it, in the same way that the canonical thread record holds what an adapter fetched rather than the adapter's own shape of it.
What a permanent bounce changes#
- The recipient is suppressed, and suppression is checked in one place before any outreach rather than at each place a message could be composed.
- A held draft to that recipient will fail immediately on approval, and the suppression is shown with its origin so the reason is visible rather than mysterious.
- Outreach stops. A reply to somebody who wrote to you first is a different path with different gates, and the two are never merged.
- The person record itself is untouched: a dead mailbox is a dead mailbox, not a dead relationship. Another identity for the same person on another channel is unaffected.
The last two points are the ones that surprise people. A permanent bounce on a prospecting contact does not silence a support conversation with the same company, because outreach and reply are separate paths by design. And because a person can hold several identities across channels, a dead email identity does not remove the phone number or the WhatsApp one beside it.
Clearing one#
Find the suppression and read its origin.
Result An entry from a permanent bounce is a factual claim about a mailbox. An entry from an unsubscribe, a complaint or a do-not-contact instruction is a claim about a person's wishes, and those are not the same thing.
Establish that it is genuinely usable again — a corrected spelling, a restored mailbox, the person confirming it themselves.
Result You have a reason that will still read as a reason in six months, which is the standard the entry was created against.
Clear the entry, if it is one that may be cleared.
Result Outreach to it resumes at the next compliance check. Nothing is re-sent retrospectively.
If it was simply mistyped, correct the identity on the person rather than clearing anything.
Result The corrected identity carries no suppression, and the mistyped one keeps its history.
Reading bounces as a health signal#
A run of permanent bounces on contacts that were assembled rather than confirmed is a sourcing problem, not a mail problem, and it is worth treating as one. Connect does not guess a prospect's email for exactly this reason: a mailbox that was never evidenced is one that bounces, and a stream of rejections is read by receiving systems as a signal about the sender.
Bounces are also not the only signal that something is wrong with a mailbox. A mailbox that authenticates and returns nothing is a quiet mailbox, which is a health verdict rather than an error, and it will never produce a bounce because it never sends. 'Connected' is not health, and neither is 'no bounces'.
Questions#
Does Connect retry a soft bounce automatically?
A temporary failure is recorded against the message; it is not turned into an automatic re-send loop, because a mail agent that re-sends on its own judgement is how a recipient gets the same message repeatedly. Where a reply still needs to go, sending it again is a person's decision on the thread.
Why is the message still marked sent if it bounced?
Because it was. The provider acknowledged it, and that acknowledgement is the evidence the sent state requires. The bounce is what happened next, and both facts are true; collapsing them would lose the one that proves the message left.
Can a bounce suppress the wrong person?
It suppresses an address, not a person. If two people share a record wrongly, that is a duplicate to be merged rather than a suppression to be cleared, and the suppression follows the identity to whichever record ends up holding it.