What it means
A bounce is a rejection, and the rejection carries a code that says exactly why. That is the part most teams skip. They see a bounce count in a dashboard, treat every entry as one bad address, and suppress the lot. In reality the same bounce list usually contains three unrelated situations: addresses that genuinely do not exist, addresses that are fine but temporarily unreachable, and messages that were refused because of something about the sender rather than the recipient. Only the first should ever be suppressed.
The arithmetic is simple: bounces divided by messages accepted for delivery, times one hundred. Compute it separately for hard and soft, because averaging them hides the only number that matters. A campaign at 6 percent total with 5.8 percent soft bounces from one greylisting provider is healthy. The same 6 percent made of hard bounces means the list is not yours.
Reading the codes
Every SMTP reply has two layers. The three-digit code, from RFC 5321, gives the class: 2xx accepted, 4xx temporary failure, 5xx permanent failure. The enhanced status code that usually follows, from RFC 3463, gives the detail in the form class.subject.detail, so 5.1.1 is permanent, addressing-related, bad destination mailbox.
The first digit tells you whether to retry. The rest tells you whether to blame the address or yourself, and that distinction is the difference between good list hygiene and self-inflicted damage. The subject digit 7 means policy or security, which is always about the sender, never about whether the mailbox exists.
Synchronous and asynchronous bounces
Some rejections happen during the SMTP conversation, before your relay has finished handing over the message. Those are easy: you get the code in the same connection. Large providers, though, tend to accept nearly everything at the edge and decide afterwards, then generate a delivery status notification, defined in RFC 3464, and send it back to your envelope sender address.
That notification is a multipart message: a human-readable explanation, a machine-readable part with the failing recipient and status code, and normally a copy of the original headers containing its Message-ID. Without a process that reads the bounce mailbox or consumes provider webhooks, none of this reaches your CRM and your list quietly rots while every dashboard shows green.
The mistake that costs the most: treating a block as a bounce
A 5.7.1 is a 5xx, so naive logic files it as a hard bounce and suppresses the recipient. But 5.7.1 means the receiver declined on policy grounds. The mailbox is fine. What failed was your authentication, your reputation, or your content, and it failed for everyone at that provider at once.
The result is a campaign that suppresses several thousand perfectly good customers in an afternoon because of a DMARC misconfiguration that took ten minutes to fix. Classify by the subject digit, not just the class: 5.1.x and 5.2.x are about the recipient, 5.7.x is about you, and only the first group belongs in a suppression list.
Where bad addresses come from
- Purchased or scraped lists. Bounce rates of 20 percent and upwards, plus spam traps that do not bounce at all and quietly destroy your reputation instead.
- Typos at capture. The classic misspelled provider domains. A domain-suggestion step at the form catches most of them before they enter the database.
- Age. Business addresses decay at roughly two to three percent per month through job changes alone, so a list left untouched for a year is substantially dead.
- Role accounts. Shared addresses like info or sales are frequently filtered, are more likely to be a trap, and rarely engage.
- No confirmation step. Single opt-in accepts anything typed into a box, including other people addresses typed by a bot.
Related concepts
- Suppression list: where hard bounces go, and where blocks must not.
- Spam trap: the addresses that never bounce and hurt far more than the ones that do.
- Domain warm-up: soft bounces are the feedback loop a warm-up schedule runs on.
- DMARC: the usual cause of a sudden wave of 5.7.1 rejections.
- Cold outreach: the activity that generates the highest bounce rates by design.
How Pinlyx handles it
Bounces arrive on a return path under your own sending domain and are parsed into class, enhanced status code and provider reason, then attached to both the contact and the original message rather than to a global counter. Hard bounces write a suppression entry with the code that caused it. Soft bounces schedule a decaying retry and only escalate after several consecutive failures across separate sends. Policy rejections in the 5.7 family are routed away from suppression entirely and raise an alert on the sending domain, because the correct response there is to stop sending, not to delete customers.