# SMTP response codes explained: 220, 221, 250, 421, 451, 550, and more

> Read SMTP reply classes, enhanced status codes, and common success, temporary, permanent, syntax, authentication, recipient, policy, and message-size responses.

- **Category:** Developer Guide
- **Published:** August 4, 2026
- **Reading time:** 17 min read
- **Author:** Maya Chen, Deliverability
- **Canonical page:** [https://emailbump.com/blog/smtp-response-codes](https://emailbump.com/blog/smtp-response-codes)

An SMTP response is the receiving server's answer to a command. The first digit gives the broad outcome: 2xx succeeded, 3xx needs more input, 4xx is a temporary failure, and 5xx is a permanent failure for the current request. The exact three-digit reply, optional enhanced status code, diagnostic text, and command stage together determine what your sender should do next.

> **Never troubleshoot from one number alone**
>
> “550” can describe an invalid recipient, blocked sender, prohibited content, relay denial, or provider-specific policy. Preserve the complete remote response, recipient scope, outbound IP, timestamps, message ID, and whether it followed MAIL FROM, RCPT TO, or DATA.

## SMTP reply classes

### Read the first digit

```text
2xx  Positive completion     Command succeeded; continue the SMTP transaction.
3xx  Positive intermediate   Server expects additional data or authentication input.
4xx  Transient negative      Retry may succeed later; use bounded provider-aware backoff.
5xx  Permanent negative      Do not retry the same request unchanged. Fix, suppress, or reroute.

1xx is not used as an ordinary SMTP reply class in RFC 5321.
```

The second digit broadly identifies syntax, information, connection, authentication, or mail-system context. The third digit adds detail. Modern responses often include an enhanced status such as 5.1.1 or 4.7.0: the first digit is still success, persistent transient failure, or permanent failure; the second identifies subject; the third adds detail.

## Common 2xx success codes

### 211

**System status or help reply**

A response to an information request; details depend on the server.

### 214

**Help message**

Human-readable command or service help.

### 220

**Service ready**

The server greeting after the connection opens, or readiness to begin TLS after STARTTLS.

### 221

**Service closing transmission channel**

Normal response to QUIT or a clean server-initiated close.

### 235

**Authentication successful**

The SMTP AUTH exchange completed successfully.

### 250

**Requested action completed**

Common after EHLO, MAIL FROM, RCPT TO, and accepted message data; read the accompanying text.

### 251

**User not local; will forward**

The server accepts responsibility while indicating forwarding.

### 252

**Cannot verify user but will accept**

The server accepts the message without confirming recipient verification.

## Why 250 can appear several times

### Successful transaction excerpt

```text
S: 220 mx.example ESMTP ready
C: EHLO sender.example
S: 250-mx.example
S: 250-STARTTLS
S: 250 SIZE 52428800
...
C: MAIL FROM:<bounce@sender.example>
S: 250 2.1.0 Sender accepted
C: RCPT TO:<person@example.net>
S: 250 2.1.5 Recipient accepted
C: DATA
S: 354 Start mail input
...
S: 250 2.0.0 Message accepted for delivery
```

A 250 after RCPT TO accepts that recipient for this transaction. The final 250 after DATA means the receiving server accepted responsibility for the message; it does not prove inbox placement, reading, clicking, or even final mailbox delivery when another hop remains.

## Common 3xx intermediate codes

### 334

**Authentication challenge**

The server expects the next SMTP AUTH response. Treat encoded credentials as secrets, not harmless text.

### 354

**Start mail input**

Send message content, ending with the SMTP termination sequence. The server has not accepted the finished message yet.

## Common 4xx temporary failure codes

### 421

**Service unavailable or closing**

The server cannot continue now. Queue with backoff and investigate sustained endpoint-wide failures.

### 450

**Mailbox or requested action unavailable**

Can indicate a temporarily unavailable mailbox or policy condition.

### 451

**Local processing error**

Often temporary, but provider text can identify greylisting, resource, policy, authentication, or routing context.

### 452

**Insufficient system storage**

May reflect server resources or too many recipients; retry only within bounded queue policy.

### 454

**Temporary authentication or TLS failure**

Preserve the exact response and security stage before retrying.

A 4xx response requests delay, not aggressive repetition. Use exponential backoff with jitter, a maximum message age, per-domain concurrency controls, and recipient-level state. Expire password resets and time-sensitive alerts rather than delivering them after they are no longer useful.

## Common 5xx permanent failure codes

### 500

**Syntax error; command unrecognized**

Check protocol framing, unsupported commands, line endings, or a connection to the wrong service.

### 501

**Syntax error in parameters**

The command exists but its arguments are malformed.

### 502

**Command not implemented**

Do not assume the server supports an optional command merely because another provider does.

### 503

**Bad sequence of commands**

The client sent a valid command at the wrong stage—for example DATA before an accepted recipient.

### 504

**Command parameter not implemented**

Commonly appears when an authentication mechanism is not recognized or supported.

### 530

**Authentication required**

Authenticate, and usually negotiate the provider-required TLS first.

### 535

**Authentication rejected**

Fix identity, credential type, mechanism, token, or account policy; do not retry blindly.

### 550

**Mailbox or requested action unavailable**

A broad permanent reply whose enhanced code and text are essential.

### 551

**User not local**

The server may supply a forwarding address, but automatic redirection needs careful policy.

### 552

**Storage allocation or message-size failure**

Frequently used for messages exceeding a fixed limit; reduce size and resend only if still appropriate.

### 553

**Mailbox name not allowed**

Check address syntax, sender policy, or provider-specific restrictions.

### 554

**Transaction failed**

A broad permanent transaction or policy failure. Preserve the provider's full explanation.

## Enhanced status codes such as 5.1.1 and 4.7.0

### class.subject.detail

```text
5.1.1  Permanent / addressing / bad destination mailbox
5.1.8  Permanent / addressing / bad sender system address
5.2.1  Permanent / mailbox / disabled or unavailable mailbox
5.2.2  Permanent / mailbox / mailbox full
5.3.4  Permanent / system / message too big for system
4.4.1  Temporary / network-routing / no answer from host
5.4.6  Permanent / network-routing / routing loop detected
5.7.1  Permanent / security-policy / delivery not authorized
4.7.0  Temporary / security-policy / other or undefined status

Providers can add product-specific diagnostics; keep them verbatim.
```

## Classify by SMTP stage

- Connection or greeting: endpoint availability, reputation blocks, concurrency, network, and server readiness.
- EHLO or HELO: protocol identity, advertised extensions, command support, and malformed clients.
- STARTTLS: certificate, encryption negotiation, policy, or temporary TLS infrastructure failure.
- AUTH: identity, credential, mechanism, token, mailbox status, and organization policy.
- MAIL FROM: envelope-sender syntax, authorization, sender reputation, and submission policy.
- RCPT TO: recipient existence, relay permission, recipient policy, and per-address suppression scope.
- DATA or end of data: content, message size, headers, authentication, reputation, policy, or malware scanning.
- Later DSN: an accepted message failed at a subsequent hop; correlate the original message ID and envelope recipient.

## Retry, suppress, or escalate

### Operational decision model

```text
2xx  Record acceptance and continue. Do not call it inbox placement.
3xx  Provide the protocol input the server requested.
4xx  Queue with bounded backoff, jitter, expiry, and domain controls.
5xx  Stop unchanged retries. Classify recipient, sender, policy, auth, or content.

Recipient-specific permanent address failure → suppress that address.
Sender/account/configuration failure → hold affected stream and fix centrally.
Policy/reputation failure → preserve evidence, stop harmful traffic, remediate cause.
Unknown provider response → retain full text and consult provider documentation.
```

## Make delivery evidence actionable

Store provider responses with message, recipient, stream, and timestamp context so retries and suppressions follow the actual failure scope.

- Message-level activity
- Recipient-specific outcomes
- Bounded retry evidence

[Learn more](https://emailbump.com/signup)

## Frequently asked questions

## Does SMTP 250 mean delivered?

It means the specific command succeeded. A final 250 after message data usually means that server accepted responsibility, but it does not guarantee inbox placement or recipient engagement. A later hop can still generate a delivery-status notification.

## Should every 4xx error be retried?

Only within a bounded policy. Consider the provider response, message expiry, attempt count, recipient domain, and queue pressure. Repeated temporary failures eventually need expiration and investigation.

## Why do two providers use the same code differently?

The three-digit code supplies a standard class and broad meaning, while enhanced codes and text provide detail. Providers also expose proprietary policy identifiers. Build parsers that retain the raw response rather than replacing it with a universal label.

## Decode the next response

- [Bounce code decoder](https://emailbump.com/tools/bounce-code-decoder) — Classify an SMTP response while preserving its diagnostic boundaries.
- [550 permanent failure](https://emailbump.com/blog/550-permanent-failure-email) — Investigate one of the most common permanent SMTP classes in depth.
- [SMTP 535 authentication](https://emailbump.com/blog/smtp-535-authentication-failed) — Fix rejected credentials, mechanisms, TLS, tokens, and account policy.
- [SMTP server settings](https://emailbump.com/blog/smtp-server-settings) — Verify endpoint, port, TLS, authentication, and envelope configuration.

## Sources

- [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321)
- [RFC 3463: Enhanced Mail System Status Codes](https://www.rfc-editor.org/rfc/rfc3463)
- [RFC 5248: SMTP Enhanced Status Code Registry](https://www.rfc-editor.org/rfc/rfc5248)
- [RFC 4954: SMTP Service Extension for Authentication](https://www.rfc-editor.org/rfc/rfc4954)