SMTP Error Codes Reference
Understand and troubleshoot SMTP response codes. Browse success responses, intermediate replies, temporary failures, and permanent rejections with step-by-step fix guides. Validate your mail server DNS configuration with the DNS Inspector, check SPF records, and verify SMTP port connectivity.
5xx Permanent Failures
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.
Syntax Error, Command Unrecognized
The server did not recognize the SMTP command. The command may be misspelled, malformed, or unsupported.
Syntax Error in Parameters or Arguments
The SMTP command was recognized but the parameters or arguments are malformed or invalid.
Command Not Implemented
The SMTP server recognized the command but has not implemented it or has disabled it.
Bad Sequence of Commands
The SMTP commands were sent in the wrong order. The server requires a specific command sequence.
Command Parameter Not Implemented
The command is recognized but a specific parameter or extension used is not implemented.
Mailbox Unavailable / Action Not Taken
The recipient's mailbox does not exist, or the server has permanently rejected the message due to policy.
User Not Local; Please Try a Different Path
The recipient is not hosted on this server. The server may suggest a forwarding address.
Exceeded Storage Allocation
The message was rejected because it exceeds the recipient's storage limit or the server's message size limit.
Mailbox Name Not Allowed
The email address syntax is invalid or the mailbox name violates server naming rules.
Transaction Failed
The entire mail transaction has failed. Used as a catch-all permanent rejection, often appearing at connection time.
Authentication Failed
The SMTP authentication credentials were rejected. The username, password, or token is incorrect.
4xx Temporary Failures
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.
Service Not Available
The SMTP server is temporarily unavailable, closing the connection. The sending server should retry later.
Mailbox Unavailable
The recipient's mailbox is temporarily unavailable. The server will not process the command right now but the sender should retry.
Local Error in Processing
The server encountered an internal error while processing the command. The message should be retried later.
Insufficient System Storage
The server does not have enough storage to process the command. The sender should retry later when space may be available.
3xx Intermediate Responses
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.
2xx Success Responses
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.
Service Ready
The SMTP server is ready to begin a mail transaction and has announced its greeting banner.
Service Closing Transmission Channel
The SMTP server is closing the connection in response to a QUIT command.
Authentication Successful
The client has been successfully authenticated and can now send mail through the server.
Requested Action Completed
The SMTP command was successfully processed. Used for EHLO responses, MAIL FROM, RCPT TO, and DATA completion.
Cannot Verify User
The server cannot verify the recipient but will attempt delivery anyway.
How an SMTP Conversation Works
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). Use the Port Scanner to verify ports 25, 465, and 587 are reachable, and the DNS Inspector to check MX records point to the correct mail server.
Enhanced Status Codes Explained
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.
X (Class)
Matches the basic reply: 2 = success, 4 = temporary failure, 5 = permanent failure. This tells you the overall outcome before reading any further.
Y (Subject)
Categorizes the issue: 0 = other, 1 = addressing, 2 = mailbox, 3 = mail system, 4 = network/routing, 5 = mail delivery, 6 = content, 7 = security/policy.
Z (Detail)
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.
Temporary vs Permanent Failures
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.
4xx Temporary Failures (Retry)
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.
5xx Permanent Failures (Bounce)
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.
Troubleshoot SMTP Errors with Free Tools
Most SMTP delivery failures trace back to DNS misconfigurations, blocked ports, or authentication policy issues. Use these tools to diagnose the root cause.
DNS Inspector
Check MX and DNS records for your mail server to verify delivery routing.
SPF Record Checker
Validate SPF record syntax and DNS lookup count against the RFC 7208 limit.
DKIM Record Checker
Verify DKIM signing configuration and public key DNS records.
DMARC Record Checker
Check DMARC policy alignment and reporting configuration.
Port Scanner
Verify SMTP ports (25, 465, 587) are accessible from the internet.
Blacklist Checker
Check if your mail server IP is listed on DNS-based blacklists.
Email Deliverability Tester
Test email deliverability, spam score, and authentication results.
Related Error Code References
Email delivery failures often involve HTTP API errors, SSL/TLS certificate issues, and server-side log analysis. These companion references help diagnose the full delivery chain.