Understand and troubleshoot SMTP response codes. Browse success responses, intermediate replies, temporary failures, and permanent rejections with step-by-step fix guides.
Permanent failures indicate the command will never succeed and the sending server should not retry. The MTA should generate a Non-Delivery Report (NDR) bounce message to the original sender. These typically require correcting the recipient address, fixing DNS records, or resolving authentication and policy issues.
The server did not recognize the SMTP command. The command may be misspelled, malformed, or unsupported.
The SMTP command was recognized but the parameters or arguments are malformed or invalid.
The SMTP server recognized the command but has not implemented it or has disabled it.
The SMTP commands were sent in the wrong order. The server requires a specific command sequence.
The command is recognized but a specific parameter or extension used is not implemented.
The recipient's mailbox does not exist, or the server has permanently rejected the message due to policy.
The recipient is not hosted on this server. The server may suggest a forwarding address.
The message was rejected because it exceeds the recipient's storage limit or the server's message size limit.
The email address syntax is invalid or the mailbox name violates server naming rules.
The entire mail transaction has failed. Used as a catch-all permanent rejection, often appearing at connection time.
The SMTP authentication credentials were rejected. The username, password, or token is incorrect.
Temporary failures mean the server cannot process the request right now but the condition may change. The sending mail server should queue the message and retry on an exponential backoff schedule. If retries fail for 24-72 hours, the message is bounced.
The SMTP server is temporarily unavailable, closing the connection. The sending server should retry later.
The recipient's mailbox is temporarily unavailable. The server will not process the command right now but the sender should retry.
The server encountered an internal error while processing the command. The message should be retried later.
The server does not have enough storage to process the command. The sender should retry later when space may be available.
Intermediate responses indicate the server is waiting for additional input before completing the action. The most common is 354, which signals the server is ready to receive the message body after the DATA command.
These codes confirm that the server accepted and processed the command successfully. Each 250 response at different stages of the SMTP conversation confirms a different action — EHLO acceptance, sender verification, recipient acceptance, or message queuing.
The SMTP server is ready to begin a mail transaction and has announced its greeting banner.
The SMTP server is closing the connection in response to a QUIT command.
The client has been successfully authenticated and can now send mail through the server.
The SMTP command was successfully processed. Used for EHLO responses, MAIL FROM, RCPT TO, and DATA completion.
The server cannot verify the recipient but will attempt delivery anyway.
SMTP (Simple Mail Transfer Protocol) is a text-based, stateful protocol. Every email delivery follows a strict sequence of commands and responses between the sending client and the receiving server. Understanding this flow is essential for diagnosing where delivery failures occur.
The client opens a TCP connection to the mail server on port 25 (relay), 587 (submission), or 465 (implicit TLS). The server responds with a 220 greeting banner containing its hostname.
The client sends EHLO (Extended SMTP) or HELO with its hostname. The server responds with 250 and lists its supported extensions: SIZE, STARTTLS, AUTH, 8BITMIME, PIPELINING, and others.
If the server advertises STARTTLS, the client upgrades the connection to TLS. After the TLS handshake, the client sends EHLO again to get the encrypted session's capabilities.
On the submission port (587), the client authenticates using AUTH PLAIN, AUTH LOGIN, or XOAUTH2. A 235 response confirms success. Authentication is required for relaying through the server.
The client declares the envelope sender with MAIL FROM:<[email protected]>. The server responds with 250 if the sender is accepted. This is the address used for bounces, not necessarily the From header.
The client specifies each recipient with RCPT TO:<[email protected]>. Each gets a separate response: 250 for accepted, 550 for rejected. Multiple RCPT TO commands can be sent for multiple recipients.
The client sends DATA, receives a 354 response, then transmits the message headers and body. The message is terminated by a line containing only a single period. The server responds with 250 and a queue ID.
The client sends QUIT, the server responds with 221, and the TCP connection is closed. The message is now in the server's delivery queue.
Each step in this flow returns a specific SMTP response code. When delivery fails, the code tells you exactly which step broke down and whether the failure is temporary (4xx) or permanent (5xx).
In addition to the three-digit reply code, modern SMTP servers include enhanced status codes (defined in RFC 3463) in the format X.Y.Z. These provide much more specific diagnostic information than the basic reply code alone.
Matches the basic reply: 2 = success, 4 = temporary failure, 5 = permanent failure. This tells you the overall outcome before reading any further.
Categorizes the issue: 0 = other, 1 = addressing, 2 = mailbox, 3 = mail system, 4 = network/routing, 5 = mail delivery, 6 = content, 7 = security/policy.
The specific problem within the subject category. For example, 5.1.1 = bad destination mailbox address, 5.7.1 = delivery not authorized, 4.7.0 = temporary authentication failure.
When you see a response like 550 5.1.1 Recipient not found, the enhanced code 5.1.1 tells you it is a permanent failure (5), related to addressing (1), specifically a bad destination mailbox (1). This is far more actionable than the basic 550 alone.
Understanding the difference between temporary (4xx) and permanent (5xx) failures is critical for email delivery. The distinction determines whether the sending server retries or bounces the message.
The sending MTA queues the message and retries on an exponential backoff schedule — typically 15 minutes, 30 minutes, 1 hour, 2 hours, 4 hours, and so on. Most MTAs give up after 4-5 days of failed retries (configurable via maximal_queue_lifetime in Postfix or timeout_frozen_after in Exim). Common 4xx causes include greylisting, server overload, and temporary DNS failures.
The sending MTA immediately stops trying and generates a Non-Delivery Report (NDR) — commonly called a bounce message — sent back to the envelope sender (MAIL FROM address). Permanent failures include nonexistent recipients (550), authentication failures (535), blacklisting (554), and policy rejections. Retrying a 5xx error wastes resources and can damage your sender reputation.
Some servers miscategorize errors — returning 5xx for what should be temporary conditions, or 4xx for permanently invalid addresses. This is why reading the full response text and enhanced status code is important. If a server returns 452 4.2.2 Mailbox full, it is technically temporary, but if the recipient never clears their mailbox, it becomes effectively permanent. Conversely, 421 4.7.0 Try again later from greylisting will resolve on the second attempt within minutes.