What is an email bounce?

Hard bounce vs soft bounce: what is the difference?

A hard bounce and a soft bounce differ in whether trying again can work. A hard bounce is a permanent failure, such as an address or a domain that does not exist; a soft bounce is a temporary one, such as a full mailbox or a busy server.

	Hard bounce	Soft bounce
Failure	Permanent	Temporary
SMTP reply	Starts with 5 (enhanced code 5.x.x)	Starts with 4 (enhanced code 4.x.x)
Typical causes	The address or its domain does not exist, or the domain takes no mail	A full mailbox, a server that is down or busy, a server asking the sender to slow down
What the sending server does	Gives up at once	Tries again for a while, then gives up
What you do	Remove the address	Keep it, and watch whether it keeps failing

The rule comes from the SMTP standard: a reply that starts with 4 is a temporary failure, and the request may be tried again; a reply that starts with 5 is permanent, and the same request should not be repeated (RFC 5321, section 4.2.1).

The first digit is a strong hint, not the whole story. RFC 3463 adds a detail code after it. It asks servers to report a full mailbox (x.2.2) as a temporary failure; some still send it with a 5, and many senders count it as a soft bounce anyway.

Why does an email bounce?

An email bounces when the receiving server cannot or will not deliver it. In a B2B list, hard bounces come from a handful of causes:

• The person left. A work email stops working once the employer closes the mailbox, and every list ages as people change jobs (data decay).
• The address was guessed. An address built from a name and the company’s email pattern may never have existed.
• A typo, in the name or in the domain.
• The domain takes no mail, or no longer exists: no working MX record, or a null MX that says so outright.

Soft bounces come from the receiving side: a mailbox over its storage limit, a server that is down or overloaded, or a server telling the sender to try again later. A message that is too large is often counted as soft too: the address is fine, but the same message fails again until it is made smaller.

A third kind sits apart: blocks. The server refuses the message because of the sender, not the recipient, for instance a domain that fails authentication or a sending IP address on a blocklist. These come back with x.7.x codes: 4.7.x when the refusal is temporary, 5.7.x when it is permanent. The address may be fine; the sending setup is what needs fixing.

What do SMTP bounce codes mean?

A bounce message carries two codes: the three-digit SMTP reply (RFC 5321) and, most of the time, an enhanced status code in three parts (RFC 3463). The class comes first, then the subject, then the detail: in 5.1.1, the 5 means permanent, the first 1 an addressing problem, the last 1 an unknown mailbox.

Each mail service writes its own text around the codes, so the same failure can look different from one server to the next. For an address that does not exist, Google answers 550 5.1.1 (Google) and Microsoft 365 answers 550 5.4.1 (Microsoft). The data above shows why both matter: among US companies with MX data, Google’s servers answer for 2,234,932 of them and Microsoft’s for 1,786,628.

Which is which?

Six bounce replies, as mail servers write them. Hard bounce or soft bounce?

1. 550 5.1.1 The email account does not exist

2. 452 4.2.2 The inbox is out of storage space

3. 556 5.1.10 The domain has a null MX

4. 421 4.7.0 Try again later, closing connection

5. 550 5.4.1 Recipient address rejected: access denied

6. 550 5.1.2 Bad destination system address

Show the answers

1. 550 5.1.1 The email account does not existHard bounceA 5 means permanent, and x.1.1 means the mailbox itself is unknown. Sending again will not create it.
2. 452 4.2.2 The inbox is out of storage spaceSoft bounceA 4 means temporary. The owner can make room, and a later attempt can go through.
3. 556 5.1.10 The domain has a null MXHard bounceThe domain declares that it takes no mail at all (RFC 7505), so no address there can work.
4. 421 4.7.0 Try again later, closing connectionSoft bounceThe server is pushing back for now, not rejecting the address. The sending server retries on its own.
5. 550 5.4.1 Recipient address rejected: access deniedHard bounceMicrosoft 365 sends this for an address that does not exist at the domain. A retry will get the same answer.
6. 550 5.1.2 Bad destination system addressHard bounceA 5 means permanent, and x.1.2 means the domain itself cannot take mail: no address there will work.

What is an email bounce rate?

An email bounce rate is the share of sent messages that bounced: bounces divided by messages sent, for a campaign or a period. Track hard and soft bounces apart. The hard bounce rate is the one that hurts a sender, because it shows mail going to addresses that never worked or no longer do.

No standards body sets a “good” rate, but sending platforms publish the limits they enforce. Amazon SES, for example, counts only hard bounces, asks senders to stay below 2%, places an account under review at 5% and may pause its sending at 10% (Amazon SES). The same page notes that mailbox providers watch bounce rates to spot bad sending practices, and that a high one can push mail into the spam folder.

How do you prevent hard bounces?

You prevent hard bounces by checking every address before the first send, never guessing one from a pattern, and checking old lists again before you use them. Three habits keep them down:

1. Check before the first send. Verify every new address with its mail server, and treat a catch-all email result as unconfirmed.
2. Stop guessing. An address built from a pattern is a bet, and a catch-all domain accepts the bet without telling you whether you lost.
3. Refresh on a schedule. Check lists that sat unused again before you send, and remove every hard bounce at once, as in a CRM hygiene routine.

When the addresses come from a data provider, ask what it does with an address it cannot confirm. Email Enrichment returns a work email only when BlitzAPI holds a record of that address tied to the person, tests verified emails again at least once every 30 days (documentation), and answers found: false, with no record counted, when it has none to give (API reference).