Bounces
A bounce is a receiving server telling you it will not deliver a message. Permanent rejections are 5xx and mean stop; temporary ones are 4xx and mean try later. The dangerous category is neither: a message accepted with a 250 and then filed in spam, or discarded, produces no bounce and looks like success from the sender's side.
Three shapes a rejection arrives in#
- Rejected in the SMTP conversation
- The receiving server answers a command with a 4xx or 5xx code before accepting the message. This is the cleanest case: you learn immediately, with a code and usually a human-readable reason.
- Accepted, then bounced back
- The server answered 250, took responsibility, and later could not deliver. It sends a delivery status notification to the envelope sender — a structured report, not merely an email, with per-recipient status.
- Accepted, then nothing
- Delivered to a spam folder, or silently dropped by a policy that deliberately does not tell senders what it filters. No bounce exists to count.
The third shape is why bounce rate alone is a poor health metric. A domain with a bounce rate of zero and a reply rate of zero is not doing well; it is being filtered quietly.
Reading the codes#
Two numbering systems run in parallel. The three-digit reply code carries the class — 2xx accepted, 4xx transient, 5xx permanent. The enhanced status code that usually follows it (5.1.1, 4.2.2, 5.7.1) is more specific and more useful, because its middle digit names the subject: 1 for addressing, 2 for the mailbox, 4 for the network, 7 for policy and security.
| Code | Usually means | About the address, or about you? |
|---|---|---|
5.1.1 | No such user at this domain | The address. Remove it permanently |
5.1.2 | The domain does not exist | The address, and probably a typo captured at signup |
4.2.2 | Mailbox full | The address, temporarily. Retry, but not forever |
4.7.x on a first attempt | Greylisting — a deliberate delay to see whether a real server retries | Neither. Retrying correctly is the whole test |
5.7.1 | Refused by policy: reputation, authentication, or content | You. Suppressing the recipient here treats a symptom and hides the cause |
Hard, soft, and the honest middle#
The two-word taxonomy is a simplification that survives because it drives an action. Hard means permanent: the address is wrong and no amount of retrying fixes it, so it comes off the list immediately. Soft means transient: retry, with a limit, because a mailbox that has been full for three weeks is functionally a hard bounce.
The middle cases deserve their own handling. A block bounce is about the sender. A content rejection is about one message rather than one recipient. A rejection carrying 5.7.1 with an authentication complaint is a configuration fault that will affect every message until it is fixed. Collapsing all of these into *hard* produces a clean-looking list and an unexplained decline in delivery.
Does Connect use bounce data?#
Partly, and it is worth being exact about which part. Connect sends through the mailbox a workspace owns, so bounces return to that mailbox and are visible to the workspace exactly as they were before Connect was connected.
What Connect adds is at the send boundary: a message is reported as sent only when the provider has acknowledged it, with a third state — uncertain — shown as uncertain rather than guessed either way. That acknowledgement is handover, not delivery. A bounce, by definition, arrives afterwards, so no acknowledgement can ever prove a message landed.
Before any outreach, suppression, unsubscribe, complaints and do-not-contact are checked in one place, which is where a permanently failing address belongs. What these sources do not describe is an automatic per-code bounce classifier inside Connect, so this page does not claim one: the taxonomy above is the standard, and the suppression list is the mechanism Connect actually enforces.
Questions#
Why does a message show as sent when it clearly bounced?
Because those are different events at different times. The provider accepted the message and said so; the receiving server rejected it seconds or hours later and sent a notification to the mailbox. The record of the send is not wrong — it is a record of handover, which is the only thing a sender can actually witness at that moment.
How many soft bounces before I treat an address as dead?
There is no number in any specification, because it depends on the reason. A full mailbox that stays full across several sends over a couple of weeks is dead in every practical sense. A greylisting delay on the first attempt is not a bounce at all and should not be counted as one.
Is a high bounce rate the thing that hurts reputation?
It is one signal, and the one most easily gamed. Complaint rate carries more weight at most large providers, and a list built from real interest produces both fewer bounces and fewer complaints. Cleaning bounces off an otherwise bad list improves the metric without improving the outcome.