bounce managementEmail Bounce Back: What SMTP Bounce Codes Mean and How to Respond

An email bounce back (also called a bounce back email or returned email) is an automated message from a mail server telling you that your email wasn't delivered. Somewhere in it is a three-digit code. Its first digit tells you what to do: a 4 means a temporary problem that may clear up on a retry, and a 5 means a permanent failure, so don't keep sending the same message to that address.

Get that distinction wrong across a 50,000-recipient campaign and you either suppress valid addresses or keep mailing dead ones, and both hurt your sender reputation. This guide shows you how to read a bounce back message, what each common code means, and what to do next. For bounce rates and how to calculate them, see our guide to email bounce rate benchmarks.

What Is an Email Bounce Back?

A bounce back is a notice that a message couldn't be delivered. You'll also see it called a returned email, an undeliverable message or a bounce-back message. Technically it's a delivery status notification (DSN): a message generated by a mail server or gateway that reports the result of a delivery attempt, with a status code and diagnostic text for each recipient (RFC 3464).

So the meaning of an email bounce back comes down to two cases:

• Hard bounce: a permanent failure (5xx). The address doesn't exist, or delivery can't succeed.
• Soft bounce: a temporary failure (4xx). The server was busy, the inbox was full, or you were rate limited.

Both are covered code by code further down this page.

There's a third case worth separating out: a 5xx block that isn't about the address at all, but about your sending reputation or authentication.

How to Read a Bounce Back Message

A bounce back message usually has two parts: a notice explaining that delivery failed, followed by the headers of your original message. Most of it is noise. What you need is the line with the 4xx or 5xx number in it (MxToolbox).

Here's a shortened example. It's for illustration only, not a real log, and the addresses are placeholders. The wording of the notice varies by provider; the code line uses Gmail's documented text for a recipient that doesn't exist.

EXAMPLE ONLY: not a real bounce, addresses are placeholders

Your message to jane.doe@example.com couldn't be delivered.

Remote server returned:
550 5.1.1 The email account that you tried to reach does not exist.

----- Original message headers -----
From: you@yourcompany.example
To: jane.doe@example.com
Subject: Spring newsletter
Date: Thu, 1 Oct 2026 09:12:44 +0000

To read it:

1. Find the code line. Look for the three-digit code (550) and, if present, the enhanced code next to it (5.1.1).
2. Check the first digit. 5 is permanent, 4 is temporary.
3. Read the text after the code. Here, Gmail says: "The email account that you tried to reach does not exist." (Google). That's a hard bounce for a bad address.
4. Check the recipient. Look for a typo in the address before you suppress it.

A tip for bounces from Microsoft Exchange servers: older Exchange bounces include diagnostic information for administrators, and its "Generating server" line shows which server issued the bounce. MxToolbox described this in a 2011 article, so the exact layout may differ today.

Why Do Emails Bounce Back?

Whether the subject line says your email was undeliverable or returned, the reason is in the code. These are the common causes. The codes in this table come from Google's list of Gmail SMTP errors; other providers use similar codes with different wording.

Reason	Hard or soft	Typical code	What to do
The address doesn't exist	Hard	550 5.1.1	Fix it if it's a typo; otherwise suppress
The recipient domain doesn't exist	Hard	553 5.1.2	Check the domain for typos; otherwise suppress
The mailbox is full	Soft	552 5.2.2	Retry later; suppress if it keeps happening
The server is busy, rate limiting you, or greylisting	Soft	4xx (Gmail uses 421 4.7.x for rate limiting)	Let your sending tool retry; slow down if you're rate limited
You're blocked for reputation or policy reasons	Block (5xx, but the address may be fine)	550 5.7.1	Don't suppress the recipient; fix your reputation or the policy issue
SPF, DKIM, DMARC or other authentication checks failed	Block	Gmail lists these under codes from 550 5.7.24 to 5.7.40	Fix your DNS authentication with a domain health check
The message is too large	Permanent for this message, not the address	552 5.3.4	Shrink the message or attachments and resend

How SMTP Delivery Produces Bounce Codes

Every email delivery involves a conversation between two mail servers — your sending server (or your ESP's server) and the recipient's mail server. This conversation follows the SMTP protocol and proceeds in a specific sequence:

1. Connection: Your server opens a TCP connection to the recipient's mail server (identified by the domain's MX records).
2. HELO/EHLO: Your server identifies itself.
3. MAIL FROM: Your server declares the envelope sender address (the Return-Path).
4. RCPT TO: Your server declares the intended recipient. This is where most bounces occur — the receiving server accepts or rejects the recipient at this stage.
5. DATA: If RCPT TO is accepted, your server transmits the message body and headers.
6. Response: The receiving server issues a final response code indicating whether it accepted the message for delivery.

At each step, the receiving server responds with a three-digit code. If the code starts with 2, the command succeeded. If it starts with 4, the command failed temporarily. If it starts with 5, the command failed permanently. These response codes are the raw material of your bounce reports.

Anatomy of a Bounce Code

SMTP response codes follow a three-digit structure where each digit carries meaning.

The First Digit: Outcome Class

First Digit	Meaning	Action
2xx	Success	Message accepted for delivery
4xx	Temporary failure	Retry later — the problem may resolve
5xx	Permanent failure	Do not retry — the delivery cannot succeed

The Second Digit: Category

Second Digit	Category
x0x	Syntax — the command was malformed
x1x	Information — status or help responses
x2x	Connection — related to the transmission channel
x5x	Mail system — related to the recipient's mail system status

The Third Digit: Specific Condition

The third digit narrows the cause further within the category. For example, within the 55x range: 550 means the mailbox is unavailable, 551 means the user is not local, 552 means the mailbox storage limit was exceeded, and 553 means the mailbox name is not allowed.

Hard Bounces: Permanent Failures (5xx)

A 5xx response means the receiving server has definitively rejected the delivery attempt. These addresses require immediate action — continuing to send to them damages your sender reputation and wastes resources.

Common 5xx Codes

550 — Mailbox unavailable / User unknown

The most common hard bounce. The recipient address does not exist on the receiving server. The RCPT TO command was rejected because the mailbox is not found.

• Cause: Typo in the address, employee left the organization, account deleted, or the address never existed.
• Action: Suppress immediately. Add to your permanent suppression list. Do not retry.

551 — User not local; please try forwarding

The receiving server knows the user but they are not hosted locally. Some servers provide a forwarding address in the response.

• Cause: The recipient has moved to a different mail system, and the old server is configured to provide forwarding hints.
• Action: If a forwarding address is provided, update your records. If not, suppress the address.

552 — Exceeded storage allocation

The recipient's mailbox is full and cannot accept new messages.

• Cause: The user has not cleaned their mailbox, or the account has a small quota.
• Action: This is technically a temporary condition, but many ESPs classify it as a hard bounce after repeated occurrences. A common rule of thumb: retry once after a day or two, and suppress if it persists across two or more campaigns.

553 — Mailbox name not allowed

The address syntax is valid in general but violates the receiving server's specific policies for mailbox names.

• Cause: The local part of the address contains characters or patterns the server does not permit.
• Action: Suppress immediately. The address cannot receive mail on that server.

554 — Transaction failed / Message rejected

A general rejection that can occur at any stage of the SMTP conversation. Often accompanied by an extended status code or human-readable explanation.

• Cause: Content filtering (spam detection), policy violation, IP blocklisting, or authentication failure.
• Action: Read the full bounce message carefully. If the rejection is content-based or reputation-based, the address itself may be valid — fix the underlying issue rather than suppressing the recipient. If the rejection specifically indicates the mailbox is invalid, suppress.

The 550 Subcategories in Practice

Large mailbox providers often return 550 with additional context in the human-readable portion of the response:

• 550 5.1.1 The email account that you tried to reach does not exist. (Gmail) — Permanent. Suppress.
• 550 5.2.1 (Gmail) — Usually an inactive account, but Google also lists this code for receiving rate limits. Read the full message before you suppress.
• 550 Requested action not taken: mailbox unavailable (generic) — Permanent. Suppress.
• 550 5.7.1 Service unavailable, client host blocked — Not a mailbox issue. This is a reputation or policy block on your sending IP/domain. Do not suppress the recipient — investigate your sending reputation.

This last example illustrates why reading the full bounce message matters. A 550 code does not always mean the address is bad — it sometimes means your server is blocked.

Soft Bounces: Temporary Failures (4xx)

A 4xx response means the delivery failed for a reason that may resolve on its own. Your sending system should retry these automatically, but you need policies for when retries should stop.

Common 4xx Codes

421 — Service not available / Try again later

The receiving server is temporarily unable to process the connection, often due to load or maintenance.

• Cause: Server overload, temporary outage, rate limiting, or greylisting.
• Action: Retry with increasing delays between attempts. If you send through an ESP, it usually retries for you; check its retry window.

450 — Mailbox unavailable (busy)

The mailbox exists but is temporarily locked or unavailable.

• Cause: The mailbox is being migrated, backed up, or the server has a transient lock.
• Action: Retry. If the 450 persists across multiple sends over several days, investigate further.

451 — Requested action aborted: local error in processing

The receiving server encountered an internal error.

• Cause: Server-side bug, database timeout, or resource exhaustion.
• Action: Retry. Not related to your sending behavior.

452 — Insufficient system storage

The receiving server's disk is full, affecting all incoming mail — not just your message.

• Cause: Server-wide storage problem.
• Action: Retry. If it persists for several days, the receiving organization likely has infrastructure issues.

Greylisting: A Special Case of 4xx

Greylisting is an anti-spam technique where the receiving server temporarily rejects the first delivery attempt from an unknown sender with a 4xx code (typically 450 or 451), expecting legitimate senders to retry. Your sending system must handle this by retrying after a short delay. If it does not retry, greylisted messages appear as bounces when they would have been accepted on the second attempt. See our full guide: greylisting explained.

Enhanced Status Codes: The x.y.z Extension

RFC 3463 introduced enhanced status codes that provide more granular information alongside the basic three-digit code. RFC 3463 defines them as class.subject.detail, in the format x.y.z where:

• x — Class (2 = success, 4 = persistent transient failure, 5 = permanent failure)
• y — Subject (0 = other, 1 = addressing, 2 = mailbox, 3 = mail system, 4 = network/routing, 5 = mail delivery protocol, 6 = message content, 7 = security/policy)
• z — Detail (specific to the subject category)

Key Enhanced Status Codes

Enhanced Code	Meaning	Action
5.1.1	Bad destination mailbox address	Suppress — address does not exist
5.1.2	Bad destination system address	Suppress — domain does not exist or has no MX
5.2.1	Mailbox disabled, not accepting messages	Usually suppress, but read the full message first (Gmail also uses 550 5.2.1 for receiving rate limits)
5.2.2	Mailbox full	Retry once, then suppress if persistent
5.3.0	Other mail system status	Read full message — varies by provider
5.7.1	Delivery not authorized, message refused	Check reputation and authentication — not necessarily a bad address
4.2.2	Mailbox full (temporary)	Retry with backoff
4.4.1	No answer from host	Retry — receiving server is unreachable
4.7.1	Delivery not authorized (temporary)	Often rate limiting — reduce send volume and retry

Enhanced status codes are more reliable than the basic three-digit code alone because they disambiguate situations where the same basic code (e.g., 550) is used for fundamentally different reasons.

Building an Operational Response Framework

Raw bounce codes become actionable when you map them to automated responses in your sending infrastructure.

Decision Matrix

Code Pattern	Classification	Automated Response	Suppression?
550 + 5.1.1 / 5.1.2	Hard bounce — invalid address	Suppress immediately	Yes, permanent
550 + 5.2.1	Usually hard bounce — inactive account (Gmail also uses it for receiving rate limits)	Read the full message, then suppress if it's an inactive account	Usually, after checking
550 + 5.7.1	Block — reputation/policy	Alert ops team; do not suppress recipient	No
552 / 5.2.2	Soft — mailbox full	Retry once next send; suppress once it reaches your soft-bounce threshold	Conditional
421 / 450 / 451	Soft — temporary server issue	Automatic retry with increasing delays	No
4.7.1	Soft — rate limited	Reduce sending rate; retry after delay	No
553 / 5.1.3	Hard bounce — bad address syntax	Suppress immediately	Yes, permanent

Implementing the Framework

1. Parse both codes: Always extract the basic three-digit code and the enhanced status code when available. The enhanced code takes precedence for classification decisions.
2. Categorize before acting: Map each bounce to hard, soft, or block. Do not treat all 5xx codes as hard bounces — 550 + 5.7.1 (policy block) is fundamentally different from 550 + 5.1.1 (invalid address).
3. Set soft-bounce thresholds: Define how many consecutive soft bounces to a single address convert it to a suppression. An address that keeps soft-bouncing is typically converted to a hard bounce after repeated failed attempts (Campaign Monitor). Three consecutive failures across separate campaigns is a common rule of thumb, not a standard.
4. Separate suppression lists by reason: Track why an address was suppressed. An address suppressed for "invalid mailbox" should never be retried. An address suppressed for "mailbox full" might be retried later, with a validation check first.
5. Alert on reputation signals: Bounces with 5.7.1 or messages mentioning blocklists, authentication failures, or policy violations should trigger alerts to your deliverability team — these indicate systemic problems, not individual address issues.

Got a Bounce Back for an Email You Didn't Send?

That's typically backscatter. A spammer forges your address as the sender, the message goes to an invalid recipient, and the recipient's server sends the bounce back to you (LuxSci). On its own, a fake bounce back email like this doesn't mean your account was hacked.

What to do:

• Don't reply to the bounce.
• Set up SPF, DKIM and DMARC for your domain so receiving servers can reject forged mail. Check your setup with the free domain health check.
• If you use a catch-all alias, consider turning it off, and filter mailer-daemon messages for mail you didn't send.

What to Do After a Bounce Back

Here's how to fix an email bounce back, step by step:

1. Classify it. Find the code: 4xx is temporary, 5xx is permanent.
2. Hard bounce for a bad address: suppress it. Stop sending to that address.
3. 5.7.1 block: fix your reputation or authentication. Don't suppress the recipient; the address may be fine.
4. Typo: correct it and resend. gmial.com bounces, gmail.com doesn't.
5. Repeated soft bounces: set a threshold. Decide how many consecutive soft bounces turn an address into a suppression.

To see whether your overall bounce rate is a problem, use the rate formula and benchmarks in our guide to reducing email bounce rates.

Key Metrics and Bounce Handling Checklist

Metrics to Monitor

Track hard and soft bounce rates per campaign, how often soft bounces turn into suppressions, and which codes dominate your bounce reports. For how to calculate bounce rate and what counts as a good number, see our email bounce rate benchmarks.

Operational Checklist

• Bounce parsing extracts both three-digit and enhanced status codes
• Hard bounces (5.1.1, 5.1.2) trigger immediate suppression; 5.2.1 is checked against the full message first
• Reputation blocks (5.7.1) trigger alerts, not suppression
• Soft bounces retry automatically, with a defined cut-off
• Consecutive soft-bounce threshold defined (three failures is a common rule of thumb)
• Suppression list records bounce reason and timestamp
• Greylisting handled by automatic retry after a short delay
• Bounce reports reviewed weekly for pattern changes
• Pre-send validation catches invalid addresses before they generate bounces
• Separate monitoring for infrastructure bounces (4xx) vs. address bounces (5xx)

Common Bounce Handling Mistakes

Treating All 5xx as Invalid Addresses

A 550 response with a 5.7.1 enhanced code means your server was blocked by policy — the recipient address may be perfectly valid. Suppressing these addresses loses viable contacts. Always read the enhanced code and the human-readable bounce message before classifying.

Never Suppressing Soft Bounces

A mailbox that has been full for six months is effectively dead. If your system retries indefinitely without a conversion threshold, these addresses accumulate in your active list, generating predictable failures every campaign and depressing your delivery metrics.

Suppressing Too Aggressively on Soft Bounces

The opposite problem. Converting a single soft bounce to a hard suppression loses addresses that experienced a one-time server issue. As a rule of thumb, wait for two to three consecutive soft bounces across separate send events before suppressing.

Ignoring Bounce Reason Distribution

If 80% of your bounces are 5.7.1 policy blocks from a single provider, you do not have a list quality problem — you have a reputation or authentication problem with that provider. The operational response is completely different. Monitor bounce reasons as a distribution, not just a total rate. For how to calculate that total and what counts as a good number, see our guide to email bounce rate benchmarks.

Not Validating Before Sending

Bounce handling is reactive — it processes failures after they occur. Validating your list before a campaign reduces hard bounces at the source and protects your sender reputation. Our guide on how to clean your list before sending walks through the steps, and you can also read how to check if an email is valid one address at a time.

Stop Bounces Before They Happen

The cheapest bounce back is the one that never happens. To check a single address, use our free email verifier: no account needed, up to 5 checks per hour. To clean a whole list, create a free account and get 200 free validations, no credit card required. After that, pricing is pay-as-you-go and credits never expire.

Validation reduces bounces; it can't remove every one. Some domains accept mail for any address, and some servers won't confirm whether a mailbox exists, so a few bounces can still get through.

Conclusion

SMTP bounce codes encode specific, actionable information about why a delivery failed, and every returned email carries one. The three-digit base code tells you whether the failure is permanent or temporary. The enhanced status code tells you whether the problem is the address, the mailbox, the server, or your own reputation. Building an automated response framework that parses both codes, classifies bounces accurately, and applies appropriate suppression or retry logic transforms bounce management from a reactive chore into a system that continuously protects your list quality and sender reputation. The critical distinction is between address-level failures that require suppression and infrastructure or policy failures that require investigation — treating them interchangeably is the most common and most costly mistake in bounce handling.