# E-mail bounce (hard vs soft)

> An e-mail bounce is a message returned as undeliverable. Hard bounces are permanent, soft bounces temporary. How to read bounce codes and keep your bounce rate low.

Canonical: https://mobilevalidate.com/glossary/email-bounce · Last updated: 2026-09-26

![A cell tower sends signal to a SIM card; the line type is identified as mobile rather than landline or VoIP.](https://mobilevalidate.com/images/carrier-and-line-type-lookup.svg)

*Carrier lookup returns the line type (mobile, landline or VoIP) and the network behind the number.*


An e-mail bounce is a message that the receiving side refuses or returns as undeliverable. A **hard bounce** is a permanent failure: the address or domain doesn't exist, or the server will never accept mail for it. A **soft bounce** is a temporary failure: a full mailbox, a server that is down, or a receiver asking the sender to try again later. Retrying can fix a soft bounce, but never a hard one.

## How does a bounce happen?

When your mail server hands a message to the receiver over SMTP, every command gets a three-digit reply code. [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321) (§4.2.1) defines the first digit: `2yz` means success, `4yz` is a **transient negative** reply (try again later), and `5yz` is a **permanent negative** reply (don't repeat the same request).

If the receiver refuses during the SMTP conversation, your server records the failure straight away. If the receiver accepts first and fails later, it sends back a bounce message, a delivery status notification defined in [RFC 3464](https://www.rfc-editor.org/rfc/rfc3464). Both carry an **enhanced status code** from [RFC 3463](https://www.rfc-editor.org/rfc/rfc3463), where `4.x.x` is persistent transient and `5.x.x` is permanent. The official list of codes is kept in the IANA registry created by [RFC 5248](https://www.rfc-editor.org/rfc/rfc5248).

## Common bounce codes

| Enhanced code | Meaning | Type |
|---|---|---|
| `5.1.1` | Bad destination mailbox address (user unknown) | Hard |
| `5.1.2` | Bad destination system address (domain) | Hard |
| `5.7.1` | Delivery not authorized, message refused (often policy or reputation) | Hard, but check why |
| `4.2.2` | Mailbox full | Soft |
| `4.4.1` | No answer from host | Soft |
| `4.7.x` | Temporary policy block, e.g. greylisting or rate limiting | Soft |

Providers also add free text after the code. Read it: a `5.7.1` can mean a missing authentication record on your side, not a bad address.

## Why do bounces matter for deliverability?

Mailbox providers watch how senders treat their recipients. Repeated sends to addresses that don't exist suggest a bought, scraped or stale list. Gmail's [sender guidelines](https://support.google.com/a/answer/81126) tell senders to "automatically unsubscribe recipients who have multiple bounced messages" and to reduce volume when SMTP errors rise, alongside keeping user-reported spam rates below 0.30%. High bounce rates lead to throttling, spam-folder placement, and in the end blocks that hit your good recipients too.

For transactional mail, a bounce is also a lost message: a receipt, a one-time code or a password reset that never arrives.

## How do you keep bounces low?

1. **Suppress hard bounces immediately**, and soft bounces after repeated failures over several days.
2. **Check addresses at entry**: syntax, [MX record](/glossary/mx-record), and a mailbox check where you can.
3. **Confirm new sign-ups** with a link, especially on [catch-all](/glossary/catch-all-email) domains, where the SMTP stage accepts everything.
4. **Re-check old lists** before a send. Addresses decay as people change jobs and providers close inactive accounts. See [list decay](/blog/number-recycling-and-list-decay).
5. **Separate the causes.** Authentication or reputation failures need fixing on your side, not list removal.

## How does MobileValidate help?

Our [mailbox check](/services/email-verification) tells you whether a mailbox exists at **major webmail providers** before you send, without sending anything to the address. It returns `registered: true`, `false` or `null`. Addresses on company or custom domains are outside coverage, come back `unknown` with `UNSUPPORTED_PROVIDER`, and are not charged. See [lead verification](/use-cases/lead-verification) for checking form entries in one request.

## Frequently asked questions

### What is the difference between a hard bounce and a soft bounce?

A hard bounce is a permanent failure, such as a mailbox or domain that doesn't exist, and SMTP signals it with a 5xx code. A soft bounce is temporary, such as a full mailbox, a server outage or greylisting, and is signalled with a 4xx code. Retrying can succeed for a soft bounce but never for a hard one.

### Should I remove hard-bounced addresses?

Yes, immediately. Keep sending to them and mailbox providers read it as poor list hygiene. Gmail's sender guidelines tell senders to unsubscribe recipients who have multiple bounced messages.

### Can I prevent bounces before sending?

Largely. Checking the address when it enters your system, with syntax, domain and mailbox checks plus a confirmation e-mail, stops most hard bounces before the first send.