What is an email bounce?

A delivery failure reported back to the sender. The receiving mail server refused the message and returned a reply code saying why — permanently, with a 5xx, or temporarily, with a 4xx. The bounce message, or NDR, carries that code.

Hard bounce vs soft bounce: what's the difference?

The first digit of the reply. A hard bounce is a 5xx permanent failure — usually a mailbox that does not exist — and the address should be suppressed. A soft bounce is a 4xx transient failure, such as a full mailbox or a busy server, and the message should be retried.

Why do emails bounce?

Most commonly the mailbox no longer exists, because the person left. After that: the domain has no mail server, the mailbox is over quota, the receiving server is throttling, or the rejection is about the sender rather than the recipient — a policy or reputation block, which looks permanent but is not about the address at all.

How to handle email addresses that bounce

Split on the class before doing anything. Suppress 5xx mailbox failures permanently and never retry them. Retry 4xx deferrals on a schedule and suppress an address that defers for days. For a 5xx about the sender, leave the address alone and fix the sending side.

How do you check if an email will bounce?

Ask the receiving mail server before you send. A verifier opens an SMTP conversation, names the address, reads the reply and stops before any message is transmitted — so you get the same answer the send would have produced, without the bounce being recorded against you.

Glossary

What is a hard bounce?

A hard bounce is a permanent delivery failure: the receiving server answered 5xx, usually because the mailbox does not exist. Retrying will not change it. A soft bounce is the transient counterpart — a 4xx reply that is worth trying again.

Also known as Permanent failure · Permanent bounce · 5xx bounce

The difference is one digit

SMTP reply codes are three digits, and the first one is the whole story. RFC 5321 defines 4yz as a transient negative completion — the command failed, but the condition is temporary and the sender should try again. 5yz is a permanent negative completion: the command failed and the sender should not repeat it in the same form.

The enhanced status code that usually accompanies it, defined in RFC 3463, repeats the class in its first digit and then says what kind of problem it was. 5.1.1 is class 5 (permanent), subject 1 (addressing), detail 1 (bad destination mailbox address) — the canonical missing mailbox. 4.2.2 is class 4 (transient), subject 2 (mailbox), detail 2 (mailbox full).

So "hard" and "soft" are not marketing categories. They are the protocol’s own distinction, and the whole set of enhanced codes is registered with IANA.

What each one usually means

Hard, and the address should be removed: the mailbox does not exist (550 5.1.1), the recipient was not found on a Microsoft system (550 5.1.10), the address is syntactically bad (553 5.1.3), or the domain has no mail server at all.

Soft, and the message should be retried: the mailbox is over quota (452 4.2.2), the server is too busy or throttling (421 4.7.0), or the sender is being greylisted (450 4.7.1).

The confusing middle is a 5xx that is about you rather than the recipient — a policy or reputation rejection such as 550 5.7.1. It is permanent as sent, but the address is fine and removing it would be the wrong correction entirely. Read the reply text, not just the digit.

How VerifyInbox handles it

A hard rejection of the mailbox is reported as undeliverable with the reason mailbox_not_found, retryable: false, and the smtpCode and smtpEnhancedCode the server actually sent, so you can see the evidence rather than take our word for it. A hard SMTP rejection outranks every classifier: a disposable or role address whose mailbox does not exist is undeliverable, not "risky". And a 5xx whose text names a block, a blocklist or an access denial is read as being about our probe, not about the address — it becomes unknown / ip_blocked, which is not charged.

What VerifyInbox returns when a server hard-rejects the mailbox
Field	Value
`emailStatus`	`undeliverable`
`reason`	`mailbox_not_found`
`mailboxStatus`	`invalid`
`smtpCode` / `smtpEnhancedCode`	The reply the server sent, e.g. `550` / `5.1.1`
`retryable`	`false`
Charged	Yes. The mailbox was tested and a definitive answer came back.

What to do with each

Hard bounce: suppress the address permanently, in the same pass. Not "remove from this campaign" — suppress, so it cannot be re-imported from another source next quarter. Do not retry it in your queue, and make sure your bounce handler distinguishes 4xx from 5xx before it writes anything.

Soft bounce: retry on a schedule and count. One deferral is normal traffic. The same address deferring for days is a mailbox that is full and probably abandoned, which is a hard bounce with a slower fuse.

A 5xx about the sender: do not touch the address. Fix the sending side — authentication, reputation, the listing named in the reply — and send again.

How to know before you send

The only thing that knows whether a mailbox exists is the receiving mail server, so the only way to find out before sending is to ask it. That is what verification does: it opens the same SMTP conversation, reads the same reply, and stops before anything is delivered. Nothing reaches the recipient.

What it cannot do is predict the future. An address confirmed today can be closed tomorrow, which is why the useful measure is how recently it was confirmed relative to the send.

Find out whether an address will hard-bounce before you send to it. No account, and it runs now: Email verifier

Related terms

Related SMTP codes

Sources

Primary sources checked 11 September 2026. If something here is out of date, tell us and we will correct it.