SMTP response codes: a practical reference

SMTP response codes are three-digit numbers a mail server sends back after each client command. The code tells you whether the command succeeded, whether the server needs more data, or what kind of error occurred. If you send email at any scale, reading these codes is a non-negotiable skill: they explain why a message was rejected, delayed, or queued.

How the three-digit structure works

Every code is defined in RFC 5321. The first digit sets the response class:

• 2xx — success. The command was accepted and completed. Proceed.
• 3xx — intermediate. The server is waiting for more data from the client before it can continue.
• 4xx — temporary error. The command failed, but the problem may resolve on its own. Retry after a delay.
• 5xx — permanent error. Retrying will not help. Fix the underlying issue or remove the address.

The second digit indicates the category: 0 for syntax, 1 for informational, 2 for connection-related, 5 for the mail system. The third digit gives a specific situation within that category.

2xx codes: success

• 220 — server ready to accept a connection. This is the first response when you connect to an SMTP port. It usually includes the hostname and software version.
• 221 — server closing connection. The expected reply to a QUIT command.
• 235 — authentication successful. Returned after the client sends valid credentials via AUTH.
• 250 — command completed. The most common code you will see. Returned after EHLO, MAIL FROM, RCPT TO (when the address is accepted), and the end of DATA. In email validation, a 250 on RCPT TO means the server is willing to accept mail for that address.
• 251 — recipient is not local, but the server will forward the message.
• 252 — server cannot verify the user but will attempt delivery. Common on servers that deliberately hide mailbox existence.

3xx codes: intermediate

• 334 — server is waiting for the next authentication step. With AUTH LOGIN, the server prompts for a base64-encoded username then a base64-encoded password.
• 354 — server ready to receive the message body. The reply to a DATA command. The client sends headers and body, ending with a line containing only a period.

4xx codes: temporary errors

Temporary errors produce a soft bounce. The MTA queues the message and retries at increasing intervals, since the problem may clear up on its own.

• 421 — service temporarily unavailable. Causes include a server restart, maintenance, too many concurrent connections, or rate limiting.
• 450 — mailbox unavailable. Often greylisting: the server intentionally rejects the first connection from an unknown sender, expecting a retry in 5 to 15 minutes.
• 451 — processing error on the server side. Internal failure, filtering problem, or a DNS lookup error. Try again later.
• 452 — insufficient storage. Either the recipient's mailbox is full or the server itself ran out of disk space.
• 455 — server cannot accept the given parameters. Uncommon; usually related to ESMTP extension issues.

5xx codes: permanent errors

Permanent errors produce a hard bounce. Retrying will not change the outcome. Remove the address from your list or fix the issue on the sending side.

• 550 — mailbox does not exist or is unavailable. The most common hard bounce code. Also returned for policy blocks: "550 Message rejected due to DMARC policy" or "550 High spam score".
• 551 — recipient is not local and forwarding is not configured.
• 552 — recipient storage limit exceeded. Unlike 452, this is a permanent condition: the mailbox is abandoned or the owner has not cleared it for a long time.
• 553 — address format is invalid. A syntax error in the recipient name.
• 554 — transaction failed. A catch-all rejection code. Usually comes with an explanation: "554 Your IP is blacklisted" or "554 Rejected by content filter".

Enhanced status codes

RFC 3463 added enhanced status codes in X.Y.Z format. They appear in the text portion of the response and give more specific diagnostic information:

• 5.1.1 — recipient address does not exist. The classic hard bounce.
• 5.1.2 — recipient domain does not exist. No MX or A records found.
• 5.2.2 — mailbox full.
• 5.7.1 — rejected by security policy: SPF, DKIM, DMARC, or a content filter.
• 5.7.26 — DMARC policy violation for the sender's domain.
• 4.7.1 — temporary rejection on suspicion of spam. A retry may succeed if the sending IP is not on a blocklist.
• 4.2.1 — mailbox temporarily disabled or blocked.

The text portion of the response

Beyond the numeric code, the server returns a human-readable explanation. There is no standard format here — each MTA writes its own. Some real examples:

• 550 5.1.1 The email account that you tried to reach does not exist (Gmail)
• 550 Requested action not taken: mailbox unavailable (generic)
• 421 4.7.0 Try again later, closing connection (Yahoo)
• 554 5.7.1 Service unavailable; Client host blocked (Outlook)

The text carries real diagnostic value. When parsing bounce notifications, check both the numeric code and the message — the text often tells you exactly what went wrong.

SMTP codes and email validation

During SMTP-based address verification, a validator connects to the MX server, sends EHLO, MAIL FROM, and RCPT TO, then closes the connection before DATA. The RCPT TO response determines the address status:

• 250 — server ready to accept mail. The address most likely exists.
• 550 — mailbox not found. The address is invalid.
• 450/451 — temporary rejection. Recheck later.
• 252 — server cannot confirm existence but will attempt delivery. Result is inconclusive.

The codes are not always reliable. Catch-all domains return 250 for every address, including ones that do not exist. Some servers accept at RCPT TO but generate a bounce after DATA. Professional validators use SMTP responses as one signal among several, not as the final verdict.