Hard bounce vs soft bounce: the difference, and what to do with each one

A bounce is a receiving mail server refusing a message. The refusal comes back as a reply code on the SMTP conversation, or as a message to your return path, and a sending platform turns it into an event. The distinction everybody needs is between the refusals that will never change and the ones that might.

A hard bounce is permanent. The mailbox does not exist, the domain does not resolve, or that server has decided it will not take mail from you. Sending again changes nothing except how often you are seen mailing addresses that do not work.

A soft bounce is temporary. The mailbox is full, the server is overloaded, or you are being asked to slow down. The same message to the same address may well succeed in an hour.

Getting bounce handling right is mostly about not confusing the two: a hard bounce you retry is wasted reputation, and a soft bounce you suppress is a customer you stopped talking to because their mailbox was briefly full.

There is a third type. Undetermined is a refusal the receiving server gave without saying clearly whether the problem is permanent, and it is reported as its own type rather than folded into one of the other two — because guessing in either direction is wrong. It is rare, and the right handling is to count it and watch.

RFC 5321 gives the first digit its meaning: a 5 is a permanent failure and a 4 is a transient one. RFC 3463 adds the enhanced status code — the three-part number after it — which narrows the reason in a way a human can act on.

550 5.1.1 The email account that you tried to reach does not exist.550 5.1.2 Domain not found550 5.7.1 Message rejected: sender not allowed

452 4.2.2 Mailbox full451 4.3.0 Temporary server error, try again later421 4.7.0 Too many messages from this sender, slow down

The text after the code is free-form and varies by provider, which is why parsing it is a losing game and why the platform reports a type instead. Read the type in code; read the text when you are investigating one specific message.

Mailbox providers read your bounce rate as a statement about your list. A sender who frequently mails addresses that do not exist looks either careless or like somebody working from a purchased list, and neither gets the benefit of the doubt when a filtering decision is marginal.

There is no single published threshold that applies everywhere, so the trend is the signal. A rate that climbs week over week means the list is decaying faster than you are cleaning it. A sudden spike almost always traces to one import, one form without validation, or one integration that started sending to a field it should not have.

The email bounce rate to watch is bounces as a share of attempted sends, per sending domain, per week. The metrics endpoint reports it alongside delivery and complaint rates, broken down by domain or by broadcast, which is usually enough to find the stream responsible without going through individual messages.

A bounce reaches you as an email.bounced webhook. The payload carries the message id, the recipient, and a bounce object whose type is the field your code branches on.

// Inside your verified webhook handler.if (event.type === "email.bounced") {  const { email_id, bounce } = event.data;
  switch (bounce.type) {    case "Permanent":      await suppress(recipientOf(email_id), "hard bounce");      break;    case "Transient":      await countSoftBounce(recipientOf(email_id));      break;    default:      // "Undetermined": the server refused without saying why. Count it,      // watch it, and suppress only if it keeps happening.      await countUndetermined(recipientOf(email_id));  }}

Three things that handler should not do. It should not parse the message text to decide what happened — the type is the decision. It should not retry a permanent bounce, ever. And it should not assume it runs once: events can be delivered more than once, so the suppression and the counter both need to be safe to repeat. The webhooks article covers the verification and deduplication that go around this.

A suppression list is the memory a transport does not have: the set of addresses this team will not send to, and why. A send to an address on it is stopped before it leaves, and reported as email.suppressed rather than silently dropped.

It applies to every kind of mail, including the transactional message whose author is certain it is important enough to be an exception. That is deliberate. The list exists so that an address which already bounced or complained is not mailed again by any part of your product, and a carve-out for “important” mail is how the whole mechanism stops working. If an entry is genuinely wrong, remove it explicitly — the API has a route for exactly that — rather than routing around the check.

Complaints belong on the same list. A complaint is not a bounce: the message arrived, and the recipient pressed the report-spam button. But the correct response is identical and more urgent, because a complaint is a direct signal to the mailbox provider in a way a bounce is not. The suppressions reference documents the reasons a row can carry.

Handling bounces well keeps a bad list from getting worse. Not collecting bad addresses in the first place is the part that actually moves the rate.

• Validate at the point of entry. Syntax, then a DNS check that the domain has a mail server at all. It catches typos and abandoned domains before they cost you anything.
• Confirm the address. Sending one message and requiring the recipient to act on it proves the mailbox exists and that somebody reads it. It is the single most effective control there is, and it is also what separates a list you can defend from one you cannot.
• Never buy or import a list you did not build. A purchased list is a bounce rate and a complaint rate in one purchase, and the damage lands on the domain your receipts go out from.
• Re-engage or remove. An address that has not opened anything in a year is more likely to become a spam trap than a customer. Removing it improves nearly every rate you measure.

Keep the two kinds of mail on separate subdomains as well, so that a campaign with a bad list cannot drag down the password resets going out beside it — the transactional and marketing article covers why, and the deliverability guide is the wider picture this one sits inside.