How to handle email bounces

A bounce is what happens when a mail server cannot deliver your message and sends it back. Every sender gets them, and on their own they are normal. What matters is how you react, because bounces are one of the clearest signals mailbox providers use to judge whether you are a careful sender or a careless one.

Here is what a bounce is, the difference between a hard and a soft bounce, and what to do with each.

What a bounce actually is

When you hand a message to a provider for sending, the receiving mail server either accepts it or refuses it. A refusal is a bounce. The receiving server returns a status code and a short reason, and your provider turns that into a bounce event you can see and act on.

A bounce is not the same as a spam complaint. A bounce means the message could not be delivered at all. A complaint means it was delivered but the recipient marked it as spam. Both hurt you, but they are separate events and you handle them differently.

Hard bounces vs soft bounces

Bounces come in two kinds, and the distinction decides what you should do next.

• A hard bounce is permanent. The address does not exist, the domain does not exist, or the server has flatly rejected the recipient. A hard bounce will never succeed, no matter how many times you retry. Common causes are a mistyped address, an employee who has left a company, or a mailbox that has been deleted.
• A soft bounce is temporary. The address is valid but the message could not be delivered right now. Common causes are a full mailbox, a server that is down, a message that is too large, or temporary throttling by the receiver.

The rule follows from the definition: never send to a hard-bounced address again, and retry a soft bounce a limited number of times before giving up. A good provider retries soft bounces for you on a sensible schedule, so a brief outage at the other end does not lose the message.

Why bounces hurt your reputation

Mailbox providers watch your bounce rate closely. A sender who keeps emailing addresses that do not exist looks either careless or like a spammer working from a purchased list, because legitimate senders who look after their lists do not accumulate dead addresses. Either way, a high hard-bounce rate tells the receiver your list is poor quality.

The consequence is worse deliverability for everyone on your list, not just the bad addresses. Providers respond by throttling you, filing your mail under spam, or rejecting more of it outright. Bounces compound: the more dead addresses you keep hitting, the lower your sender reputation falls, and the harder it becomes to reach the inbox even for valid recipients. Keeping your bounce rate low is one of the cheapest things you can do to protect deliverability. For the wider picture, see how to improve email deliverability.

Suppression lists

A suppression list is the mechanism that stops the damage. When an address hard-bounces, you add it to a suppression list, and from then on your system refuses to send to it. The next time your application tries to email that address, the send is blocked before it ever leaves, so you never bounce against the same dead address twice.

This is not optional housekeeping, it is the single most important bounce control you have. Without suppression, a dead address in your database gets emailed again on every receipt, every notification and every newsletter, and each attempt is another hard bounce counting against you. Spam complaints usually feed the same list, so a recipient who marks you as spam is also suppressed from future sends.

A suppression list should be automatic. You do not want engineers hand-editing a block list, you want the hard bounce to add the address with no action from you.

Acting on bounce events through webhooks

To react to bounces in your own system, you consume them as webhook events. Your provider sends an HTTP request to an endpoint you control each time a message bounces, carrying the message id, the address, and whether the bounce was hard or soft. Your endpoint can then update your records: flag the user, stop a dunning sequence, prompt them for a new address, or alert support.

Two things make this reliable. First, the events should be signed, so your endpoint can verify with an HMAC signature that the request genuinely came from your provider and is not a forged POST from someone who guessed your URL. Second, your endpoint should return a 2xx status quickly and do its heavier work afterwards, so the provider knows the event was received. If you want the full detail on consuming events safely, see email webhooks explained.

How Mailhuset handles it

Mailhuset handles bounces for you. We classify every bounce as hard or soft, retry soft bounces on a sensible schedule, and automatically add hard-bounced and complained addresses to your suppression list so you never send to them again. You can see every bounce in your dashboard and receive each one as a signed webhook, so your HMAC check confirms the event is real before you act on it. Mailhuset sends from the EU by default, and bounce handling works the same across transactional email, inbound and broadcasts.

See how we handle deliverability for how bounce handling and suppression fit into getting your mail delivered.