All dispatchesView as Markdown

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

MC
Maya ChenDeliverability at Email Bump

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

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.

SMTP reply classes

Read the first digit
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

01 / 211System status or help reply

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

02 / 214Help message

Human-readable command or service help.

03 / 220Service ready

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

04 / 221Service closing transmission channel

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

05 / 235Authentication successful

The SMTP AUTH exchange completed successfully.

06 / 250Requested action completed

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

07 / 251User not local; will forward

The server accepts responsibility while indicating forwarding.

08 / 252Cannot verify user but will accept

The server accepts the message without confirming recipient verification.

Why 250 can appear several times

Successful transaction excerpt
S: 220 mx.example ESMTP ready
C: EHLO sender.example
S: 250-mx.example
S: 250-STARTTLS
S: 250 SIZE 52428800
...
C: MAIL FROM:<[email protected]>
S: 250 2.1.0 Sender accepted
C: RCPT TO:<[email protected]>
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

01 / 334Authentication challenge

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

02 / 354Start 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

01 / 421Service unavailable or closing

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

02 / 450Mailbox or requested action unavailable

Can indicate a temporarily unavailable mailbox or policy condition.

03 / 451Local processing error

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

04 / 452Insufficient system storage

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

05 / 454Temporary 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

01 / 500Syntax error; command unrecognized

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

02 / 501Syntax error in parameters

The command exists but its arguments are malformed.

03 / 502Command not implemented

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

04 / 503Bad sequence of commands

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

05 / 504Command parameter not implemented

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

06 / 530Authentication required

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

07 / 535Authentication rejected

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

08 / 550Mailbox or requested action unavailable

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

09 / 551User not local

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

10 / 552Storage allocation or message-size failure

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

11 / 553Mailbox name not allowed

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

12 / 554Transaction 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
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
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.

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.