Email Bounce Codes Explained: Hard vs Soft Bounces (and What to Do)

What a bounce actually is

A bounce is a rejection message returned when a receiving mail server refuses to deliver your email. Sometimes the rejection happens live, during the SMTP conversation, before your server has even finished handing over the message. Other times it arrives minutes or hours later as a separate Non-Delivery Report (NDR) — the classic "Mail delivery failed" email — because the message was accepted for further processing and only later found undeliverable.

Every bounce carries a reply code and usually a human-readable reason. Learning to read those codes is the difference between reacting blindly (re-sending to an address that will never accept mail) and reacting correctly (suppressing it permanently, or retrying only what is worth retrying). The codes follow a consistent structure, so once you understand the pattern you can decode almost any bounce you encounter.

The anatomy of an SMTP reply code

SMTP reply codes are three-digit numbers, and the first digit tells you almost everything you need to know. A code beginning with 2 means success. A code beginning with 4 means a temporary failure — try again later. A code beginning with 5 means a permanent failure — do not try again. On top of that, modern servers attach an enhanced status code (RFC 3463) in the form X.Y.Z, which gives a more precise reason.

So a bounce is essentially two signals stacked together: the class (4 = transient, 5 = permanent) and the detail (mailbox full, user unknown, policy rejection, and so on). Read the first digit to decide retry-versus-suppress, and read the enhanced code and text to understand why.

• 2xx — Success. The server accepted the command (250 is the everyday "OK").
• 4xx — Transient (soft) failure. The problem is temporary; the sending server should retry. Example: 452 (insufficient system storage), 421 (service not available, try later).
• 5xx — Permanent (hard) failure. The problem will not resolve on retry. Example: 550 (mailbox unavailable / user unknown), 553 (mailbox name not allowed).
• Enhanced codes (X.Y.Z): 5.1.1 (bad destination mailbox), 5.2.2 (mailbox full — often reported as transient), 5.7.1 (delivery not authorized / blocked by policy).

Hard bounces: permanent failures

A hard bounce is a 5xx permanent rejection. The address does not exist, the domain has no working mail server, or the recipient server has decided it will never accept your mail. The defining characteristic is that retrying is pointless and, worse, harmful — every repeat attempt on a known-bad address is another negative signal to the mailbox provider.

The most common hard bounce is 550 5.1.1, "user unknown" — the local part of the address has no mailbox behind it. This is exactly the failure email verification is designed to prevent, because the SMTP mailbox probe catches these addresses before you ever send to them. Other permanent failures include domains with no MX record and addresses blocked by recipient policy (5.7.x), which sometimes signals a reputation problem on your side rather than a problem with the address.

• 550 5.1.1 — mailbox does not exist. Suppress immediately and permanently.
• 550 5.1.2 — domain does not exist or cannot receive mail. Suppress; the whole domain is dead.
• 554 5.7.1 — message rejected by policy (often a blocklist or reputation issue). Investigate your sender reputation, not just the address.
• 553 5.1.3 — malformed address. Fix at the source; this is usually a data-quality problem.

Soft bounces: temporary failures

A soft bounce is a 4xx transient rejection. The address may be perfectly valid, but something is temporarily preventing delivery: the mailbox is full, the server is overloaded, the message is too large, or the receiver is greylisting you and asking you to try again shortly. Well-behaved sending servers automatically retry soft bounces on a back-off schedule for a day or two before giving up.

The key with soft bounces is patience followed by judgment. A single soft bounce means nothing — let your platform retry. But an address that soft-bounces on every send for weeks is functionally dead (a permanently full or abandoned mailbox looks like a soft bounce), and you should promote it to your suppression list. A good rule is to treat an address as hard-bounced after three to five consecutive soft bounces.

• 421 4.7.0 — service temporarily unavailable or rate-limited. Retry with back-off.
• 450 4.2.1 — mailbox temporarily unavailable (often greylisting). Retry shortly.
• 452 4.2.2 — mailbox full. Retry; suppress if it persists across many sends.
• 452 4.3.1 — insufficient system resources on the receiver. Retry later.

The one that looks soft but is really hard

The trickiest case is the address that is technically deliverable today but is a liability tomorrow. Full mailboxes (452 4.2.2) are the classic example: a full mailbox is often an abandoned mailbox, and an abandoned mailbox is a prime candidate to be recycled into a spam trap. Treating persistent soft bounces as eventual hard bounces is not just good hygiene — it is trap-avoidance.

Greylisting is the opposite trap: a 4xx that looks like a problem but is actually a normal anti-spam tactic. The receiver deliberately rejects the first delivery attempt from an unknown sender and accepts the retry. It resolves itself and should never be treated as a real failure. If you are curious how verification handles this, our greylisting guide covers it in depth.

Prevent the bounce instead of processing it

Every bounce you can prevent is a negative reputation signal you never generate. The most effective prevention is verifying addresses before you send, because the same SMTP mailbox probe that a receiving server would use to reject a 550 5.1.1 is exactly what a verifier runs in advance — catching the dead mailbox while it is still just a row in your list, not a bounce against your domain.

Verify a single address in real time, or run a whole file through the bulk endpoint before a campaign, and you strip out the hard-bounce sources before they cost you anything:

curl -X GET "https://verifly.email/api/v1/verify?email=prospect@example.com" \
  -H "Authorization: Bearer vf_your_api_key"

A bounce-handling policy that runs itself

Reading codes is only useful if it drives automatic action. Wire your system so that any 5xx suppresses the address on the first occurrence, any 4xx is retried on a back-off schedule, and any address that accumulates several consecutive 4xx failures is promoted to permanent suppression. Log the codes so a whole-domain failure (which signals a DNS or blocklisting problem, not a bad address) stands out from scattered per-mailbox failures.

Combine that reactive handling with proactive verification and your bounce rate stops being a fire you fight and becomes a number you barely think about. For the wider context on how bounces feed sender reputation, our bounce-rate playbook and the developer-focused email verification API walk through the full workflow.