bounce managementUnderstanding SMTP Bounce Codes: What They Mean and How to Respond

Your campaign goes out to 50,000 recipients and the bounce report comes back with a wall of three-digit codes — 550, 451, 552, 421 — each attached to a cryptic message from a remote mail server. Some of these codes mean the address is permanently dead and should never receive another message. Others mean the server was temporarily busy and will likely accept the message on the next attempt. Treating them the same way — or worse, ignoring the distinction entirely — leads to suppressing valid addresses, continuing to send to invalid ones, and gradually degrading your sender reputation through mishandled bounce events.

SMTP bounce codes are not arbitrary. They follow a structured system defined in RFC 5321 and extended by RFC 3463, and each code tells you something specific about why delivery failed. Understanding this system transforms bounce handling from guesswork into a precise, automated process that protects both your list quality and your deliverability.

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. Retry once after 24-48 hours. If it persists across two or more campaigns, suppress.

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 The email account that you tried to reach is disabled (Gmail) — Permanent. 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 using exponential backoff. Most ESPs retry automatically for 24-72 hours.

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 more than 48 hours, 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 5-15 minutes. If it does not retry, greylisted messages appear as bounces when they would have been accepted on the second attempt.

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. These appear in the format x.y.z where:

• x — Class (2 = success, 4 = temporary 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	Suppress — account deactivated
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	Hard bounce — disabled account	Suppress immediately	Yes, permanent
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 after 3 consecutive failures	Conditional
421 / 450 / 451	Soft — temporary server issue	Automatic retry with exponential backoff (up to 72 hours)	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. Three consecutive failures across separate campaigns is a common threshold.
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 after 90 days 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.

Key Metrics and Bounce Handling Checklist

Metrics to Monitor

Metric	Target	Red Flag
Hard bounce rate per campaign	< 0.5%	> 2% — list quality issue, pause and validate
Soft bounce rate per campaign	< 3%	> 5% — investigate server-side or throttling issues
Soft-to-hard conversion rate	Trending downward	Rising — retry logic or thresholds may be misconfigured
Bounce reason distribution	No single code > 50%	One code dominating — investigate systemic cause
Time to suppress hard bounces	< 1 hour after bounce event	> 24 hours — automation gap

Operational Checklist

• Bounce parsing extracts both three-digit and enhanced status codes
• Hard bounces (5.1.1, 5.1.2, 5.2.1) trigger immediate suppression
• Reputation blocks (5.7.1) trigger alerts, not suppression
• Soft bounces retry with exponential backoff up to 72 hours
• Consecutive soft-bounce threshold defined (e.g., 3 failures = suppress)
• Suppression list records bounce reason and timestamp
• Greylisting handled by automatic retry after 5-15 minute 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. Require at least 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.

Not Validating Before Sending

Bounce handling is reactive — it processes failures after they occur. Pre-send email validation catches invalid addresses, disposable domains, and syntax errors before they generate bounces. Running validation before a campaign reduces your hard bounce rate at the source, preserving your reputation score and keeping you below provider thresholds.

Conclusion

SMTP bounce codes encode specific, actionable information about why a delivery failed. 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.