# SMTP Bounce Code Decoder

> Decode classic SMTP replies and enhanced mail-system status codes into likely scope, retry guidance, suppression decisions, and practical diagnostic steps.

- **Category:** Deliverability
- **Updated:** July 2026
- **Canonical page:** [https://emailbump.com/tools/bounce-code-decoder](https://emailbump.com/tools/bounce-code-decoder)
- **Interactive tool:** [Open the decoder](https://emailbump.com/tools/bounce-code-decoder)

## What the tool does

Paste a receiving server response such as:

```text
550 5.1.1 The email account that you tried to reach does not exist.
```

The decoder extracts a classic three-digit SMTP reply, an enhanced `X.Y.Z` status when present, and relevant text signals. It then reports:

- Success, transient failure, permanent failure, or unclassified response
- Likely scope: recipient, message, authentication, sender reputation, policy, sending system, or receiving system
- Whether retrying, pausing, fixing, suppressing, or manual review is appropriate
- Separate retry and recipient-suppression guidance
- A diagnostic runbook
- A portable incident note and JSON evidence bundle

Decoding runs entirely in the browser. Raw responses are not submitted to Email Bump or an external service. Paste only the response fields needed for diagnosis and remove customer addresses or identifiers that are not necessary.

## SMTP reply classes

The first digit of the three-digit SMTP reply identifies the broad result:

| Class | Meaning | Operational response |
| --- | --- | --- |
| 2xx | Positive completion | The receiver accepted the requested SMTP action |
| 4xx | Transient negative completion | The exact request may succeed later; retain it in one controlled delivery queue |
| 5xx | Permanent negative completion | Do not repeat the exact request unchanged; review or correct the cause |

RFC 5321 says clients must be prepared to handle unknown replies by interpreting the first digit. A 4xx response means the sending SMTP system should try again. A 5xx response means the exact request should not be repeated in the same sequence, though a person may correct the underlying problem and initiate a new request.

## Enhanced status-code anatomy

An enhanced status has three numeric fields:

```text
class.subject.detail
  5     1      1
```

- **Class:** `2` success, `4` transient failure, or `5` permanent failure
- **Subject:** the probable source category
- **Detail:** the specific registered condition within that category

Subject families include:

| Subject | Category |
| --- | --- |
| X.0.x | Other or undefined status |
| X.1.x | Address status |
| X.2.x | Mailbox status |
| X.3.x | Mail-system status |
| X.4.x | Network and routing status |
| X.5.x | Mail-delivery protocol status |
| X.6.x | Message content or media status |
| X.7.x | Security or policy status |

The current IANA registry is the source of truth for registered enhanced status codes. Provider-specific prose should supplement rather than replace the structured codes.

## Suppression is a scope decision

A permanent SMTP failure is not automatically proof that the recipient is invalid.

### Strong recipient-suppression evidence

```text
550 5.1.1 Destination mailbox does not exist
```

This specifically identifies a permanent bad destination mailbox. Suppress the address across relevant sending streams and retain the exact evidence and timestamp.

### Do not suppress the recipient

```text
550 5.7.26 Message failed SPF or DKIM checks
```

This is a sender-authentication failure. Correct authentication and alignment; the recipient may be completely valid.

```text
552 5.3.4 Message size exceeds the receiving-system limit
```

This is a message problem. Reduce the encoded message size or attachments.

```text
421 4.7.0 Temporarily deferred due to complaint or reputation signals
```

This is a transient policy or sender-reputation condition. Queue with controlled backoff, reduce or pause the affected stream, and investigate acquisition, complaints, engagement, volume, identity, and content.

Calling all of these “hard bounces” without preserving scope can suppress valid customers and hide a sender incident.

## Retry ownership

One transport queue should own delivery retries. If an application creates a second message while the provider is still retrying the first, both may eventually arrive.

- Retry the existing delivery attempt, not the underlying business event.
- Preserve a stable message identifier and provider event ID.
- Use controlled backoff and jitter for transient conditions.
- Do not immediately move unchanged traffic to a new domain or IP.
- Protect essential transactional streams from promotional pressure.
- Mark the attempt terminal only when the delivery owner exhausts its policy or receives a permanent response.

## Evidence to preserve

For any meaningful incident, retain:

- Exact raw response
- Timestamp and timezone
- Receiving host and recipient domain
- SMTP stage: connection, MAIL FROM, RCPT TO, or after DATA
- Sending domain, aligned envelope domain, DKIM identity, and IP
- Application message ID and provider event ID
- Message stream and template
- Retry count and queue age

Do not place full message bodies, secrets, or unnecessary personal data into diagnostic tickets.

## Frequently asked questions

### Is every 5xx response a hard bounce?

A 5xx reply is permanent for the SMTP request as submitted. The failure may belong to the recipient, sender, authentication, content, policy, or system. Only recipient-specific permanent evidence justifies recipient suppression.

### Should a 4xx response be retried immediately?

No. Let the sending MTA or provider queue retry with controlled backoff. Immediate application resends can amplify throttling, damage reputation, or create duplicates.

### Can the human-readable response text be trusted?

Preserve it and use it for context, but prioritize structured numeric semantics. Text varies by provider and can be ambiguous. When classic and enhanced codes disagree, treat the response as malformed or uncertain and avoid irreversible automation.

### Is mailbox full a permanent invalid address?

No. Enhanced status X.2.2 is normally a persistent transient condition. Follow a controlled retry and expiration policy. Repeated long-term quota failures can justify reducing future nonessential sends, but the first response is not proof the mailbox is invalid.

## Primary standards

- [IANA SMTP Enhanced Status Codes Registry](https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml)
- [RFC 3463: Enhanced Mail System Status Codes](https://www.rfc-editor.org/rfc/rfc3463.html)
- [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321.html)
- [RFC 5248: Registry for SMTP Enhanced Mail System Status Codes](https://www.rfc-editor.org/rfc/rfc5248.html)

## Related guidance

- [Pay close attention to bounces](https://emailbump.com/blog/email-bounce-handling-guide.md)
- [Reacting to Gmail reputation-based bounces](https://emailbump.com/blog/gmail-reputation-bounces.md)
- [Hard bounce definition](https://emailbump.com/glossary/hard-bounce.md)
- [Soft bounce definition](https://emailbump.com/glossary/soft-bounce.md)
- [Suppression list definition](https://emailbump.com/glossary/suppression-list.md)