An email bounce is a message that the recipient’s mail server refused or could not deliver, so it comes back to the sender with an error code that explains why. Bounces fall into two groups: hard bounces, which are permanent (the address or domain doesn’t exist), and soft bounces, which are temporary (a full mailbox, a busy server, a rate limit). Every sender gets some bounces. What matters is how many you get and what you do about them.

This guide explains what actually happens when an email bounces, how to read the bounce message itself, and how bounces differ from blocks, complaints, and auto-replies.

How an email bounce happens

Sending an email is a conversation between two servers using SMTP. Your sending server (or your email service provider) connects to the recipient’s mail server, found through the domain’s MX record, and announces the sender and each recipient. The receiving server answers every step with a three-digit reply code.

A simplified exchange that ends in a bounce looks like this:

S: 220 mx.example.com ESMTP ready
C: EHLO mail.yourcompany.com
S: 250-mx.example.com
C: MAIL FROM:<news@yourcompany.com>
S: 250 2.1.0 OK
C: RCPT TO:<jane.doe@example.com>
S: 550 5.1.1 The email account that you tried to reach does not exist.
C: QUIT

That 550 reply is the bounce. The receiver told your server, in the middle of the conversation, that it will not accept mail for that address.

Synchronous vs asynchronous bounces

There are two ways a bounce reaches you:

Synchronous (rejected during the SMTP session). The receiving server refuses the recipient or the message before accepting it, as in the example above. Your server or ESP records the error immediately.
Asynchronous (bounced after acceptance). The receiving server says 250 OK, accepts the message, and only later discovers it can’t deliver it, for example because an internal mail system behind a gateway doesn’t know the user. It then sends a separate bounce email back to your return-path address, sometimes hours or days later.

According to the M3AAWG Sender Best Common Practices (Version 3.0, February 2015), about 95% of returns happen synchronously. The remaining asynchronous bounces are the reason senders need a working return-path mailbox or a system that tags each message so bounces can be matched to the right recipient. If you run your own infrastructure, our post on VERP and bounce attribution covers that problem.

Anatomy of a bounce message

When a bounce arrives as an email, it is usually a Delivery Status Notification (DSN), a structured format defined in RFC 3464. A DSN is a multipart/report message with three parts: a human-readable explanation, a machine-readable status block, and (optionally) a copy of the original message or its headers.

The machine-readable part looks like this:

Reporting-MTA: dns; mx.example.com
Final-Recipient: rfc822; jane.doe@example.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; mailstore1.example.com
Diagnostic-Code: smtp; 550 5.1.1 <jane.doe@example.com>: Recipient address rejected: User unknown

Here is what each field tells you:

Field	What it means
`Final-Recipient`	The address that failed
`Action`	What the server did: `failed`, `delayed`, `delivered`, `relayed`, or `expanded`
`Status`	The enhanced status code (for example `5.1.1`)
`Diagnostic-Code`	The raw SMTP reply from the server that refused the message
`Remote-MTA`	The server that produced the error

The Action: delayed value is worth knowing. It isn’t a bounce yet. It’s a warning that the message is still being retried, and many mail systems send it after a few hours of failed attempts.

If you use an ESP, you rarely see raw DSNs. The provider parses them and hands you an event instead. Amazon SES, for example, sends a JSON notification with bounceType, bounceSubType, and per-recipient status and diagnosticCode fields, as shown in its notification contents documentation.

Reading the bounce code

Every bounce carries two codes, and they work together.

The basic SMTP reply code has three digits. The first digit is the one that matters most. Per RFC 5321, 4yz means a temporary failure where the action can be retried, and 5yz means a permanent failure where the client should not repeat the same request.

The enhanced status code has the form class.subject.detail, defined in RFC 3463. The class matches the first digit (4 or 5). The subject tells you what area the problem is in:

Subject	Area	Example
`x.1.x`	Addressing	`5.1.1` bad destination mailbox
`x.2.x`	Mailbox status	`4.2.2` mailbox full
`x.3.x`	Mail system	`4.3.0` temporary server error
`x.4.x`	Network and routing	`4.4.7` delivery time expired
`x.5.x`	Protocol	`5.5.2` syntax error
`x.7.x`	Security or policy	`5.7.26` failed DMARC

For a full reference with real examples from Gmail, Microsoft, and Yahoo, see SMTP bounce codes explained.

Hard bounce vs soft bounce

Most email platforms sort bounces into two buckets.

A hard bounce is a permanent failure. The most common cause is an address that doesn’t exist. Others include a domain that doesn’t exist or doesn’t accept mail. Amazon SES puts it plainly in its bounce type documentation: after a permanent bounce you should remove the address from your mailing lists immediately.

A soft bounce is a temporary failure: the mailbox is full, the server is down, the message is too large, or the receiver is throttling you. Your server or ESP retries for a period of time. If the retries succeed, the email is delivered and you may never notice.

	Hard bounce	Soft bounce
Typical SMTP code	`5xx`	`4xx`
Example	`550 5.1.1` user unknown	`452 4.2.2` mailbox full
Will retrying help?	No	Often
What to do	Suppress the address now	Let retries run; suppress if it keeps failing

The split is not always clean. Some 5xx errors are policy rejections about your mail (authentication, reputation, content) rather than a bad address, and some soft bounces repeat for weeks because the mailbox has been abandoned. We go through those gray areas in Hard Bounce vs Soft Bounce: Causes and Fixes, and our existing guide on bounce classification covers how each type should be handled operationally.

What a bounce is not

Several kinds of messages look like bounces but are something else.

Blocks

A block is a rejection aimed at the sender, not the recipient. A Gmail reply such as 550 5.7.26 Unauthenticated email ... is not accepted due to domain's DMARC policy (listed in Google’s SMTP error reference) means the recipient address is probably fine and your authentication setup is the problem. Many tools count blocks as bounces anyway, which is why you should always read the code before deleting addresses.

Spam complaints

A complaint happens after delivery, when the recipient clicks “Report spam.” Mailbox providers that run feedback loops send these back to the sender. Complaints are tracked separately from bounces and have much lower tolerance. Amazon SES, for example, starts a review at a 0.1% complaint rate compared with 5% for bounces.

Auto-replies

Out-of-office replies arrive at the same return-path address as bounces and sometimes get misread as failures. They mean the message was delivered. Amazon SES notes that it does not count automatic responses when it calculates an account’s bounce rate, even though the notification is labeled as a bounce.

Delayed delivery notices

As mentioned above, a DSN with Action: delayed means the sending system is still trying. Don’t remove an address because of a delay notice.

How bounce rate is calculated

Bounce rate is the share of attempted sends that bounced:

bounce rate = bounced messages / messages sent × 100

If you send 20,000 emails and 140 bounce, your bounce rate is 0.7%. Most teams track hard bounce rate separately, because that’s the number providers react to. Amazon SES bases its bounce rate on hard bounces only and ignores soft bounces, according to its reputation metrics documentation.

What counts as “too high” depends on your platform. A few published limits:

Amazon SES: account placed under review at a 5% bounce rate; sending may be paused at 10% (AWS).
HubSpot: marketing email can be suspended if you exceed a 5% hard bounce rate in a month (HubSpot Knowledge Base).
Postmark: lists a bounce rate below 10% of all emails sent as one of its conditions for sending without a daily limit (Postmark support).

These are ceilings, not targets. A healthy list runs far below them.

Why email bounces matter

A few bounces cost you nothing. A pattern of them costs you a lot:

Reputation damage. The M3AAWG best practices document notes that receivers use the volume of permanent failures as one input when deciding how to treat a sender’s future mail. Large numbers of hard bounces suggest a poorly managed signup process or an old list.
Account enforcement. ESPs pause or suspend accounts with high bounce rates because your bounces hurt their shared IP reputation.
Lost revenue and broken flows. A password reset or receipt that bounces is a support ticket waiting to happen.
Bad data downstream. A bounced address in your CRM means a lead you think you can reach but can’t.

What to do when emails bounce

Read the code, not just the label. A 5.1.1 and a 5.7.26 are both “hard bounces” in many dashboards, but they need opposite fixes.
Suppress hard bounces right away. Don’t retry an address that doesn’t exist. Google’s sender guidelines also advise automatically unsubscribing recipients who have multiple bounced messages.
Let soft bounces retry, then set a limit. One full mailbox is noise. The same address soft-bouncing across several campaigns is a dead address. Our post on mailbox full bounces suggests a practical rule.
Look for a source. If bounces spike on one list, import, or signup form, the problem is upstream. Fix collection instead of cleaning up after it.
Check addresses before you send. Catching typos, dead domains, and disposable addresses before they enter your list prevents a large share of avoidable bounces.

That last step is where the free email verifier on this site helps. It checks syntax, confirms the domain exists and has MX records, flags disposable and role-based addresses, detects free-provider domains, and suggests corrections for common domain typos such as gmial.com. It does not open an SMTP connection to the mailbox, so it can’t confirm that a specific inbox exists, but it removes the most common causes of preventable hard bounces before you hit send.

For a step-by-step prevention plan, see How to Reduce Your Email Bounce Rate.

FAQ

What is the difference between a bounce and a block?

A bounce usually means the recipient address can’t receive mail, for example because it doesn’t exist or the mailbox is full. A block means the receiving server rejected your message because of something about you, such as failed authentication, a poor sender reputation, or a blocklist listing. Both arrive as error codes, but blocks usually carry x.7.x policy codes and should not lead you to remove the recipient.

Do bounced emails hurt my sender reputation?

Yes, hard bounces in particular. Mailbox providers read a high volume of mail to nonexistent addresses as a sign of a poorly maintained or purchased list. Soft bounces matter less, but an address that soft-bounces over and over should eventually be suppressed.

How do I know if an email bounced?

If you send through an ESP, bounces show up in your campaign reports or as webhook events. If you send from a regular mailbox like Gmail or Outlook, you’ll get a “Delivery Status Notification (Failure)” or “Undeliverable” email back, with the SMTP error code in the body.

Can a bounced email still be delivered later?

A soft bounce can. The sending server keeps retrying, and the message is delivered if the temporary problem clears. A hard bounce won’t be delivered no matter how many times you retry, so retrying only adds more failures to your record.

Does an out-of-office reply count as a bounce?

No. An auto-reply means the message reached the mailbox. Some platforms receive auto-replies through the same channel as bounces, but they shouldn’t be counted toward your bounce rate or used to remove contacts.

What Is an Email Bounce? Hard vs Soft Bounces Explained