117 of 117 codes
Basic reply codes
System status or system help reply. Rarely used in practice.
Help message in response to the HELP command, with information on how to use the server or a specific command.
The server's initial greeting when the connection opens: the service is ready. Also returned in response to STARTTLS to indicate that TLS negotiation can begin.
The server is closing the connection, usually in response to the QUIT command.
Authentication with AUTH succeeded. Usually accompanied by the enhanced code 2.7.0.
The requested action was completed. This is the usual reply to EHLO, MAIL FROM, RCPT TO and at the end of DATA, when the server accepts the message.
The recipient is not local, but the server accepts the message and will forward it to the specified address.
The server does not confirm whether the user exists (VRFY disabled to prevent account enumeration), but will accept the message and attempt delivery.
Reply to ETRN: the server has started delivering the messages queued for the requested domain or node.
Server challenge during AUTH, Base64-encoded. The client must reply with the next piece of data for the mechanism (for example, the username or the password in AUTH LOGIN).
Reply to DATA: the server is waiting for the message content, which ends with a line containing only a period.
The service is not available and the server is closing the connection: shutdown, overload, too many connections or a temporary sending limit. The sender should retry later.
The user must change their password or switch to another authentication mechanism before they can authenticate. Accompanied by the enhanced code 4.7.12.
The mailbox is temporarily unavailable: busy, locked or transiently rejected by policy. Greylisting usually replies with this code or with 451.
The action was aborted due to a local server error, such as a failed DNS lookup or a filter that did not respond. The sender should retry later.
The server does not have enough storage to accept the message right now. It also indicates that the number of recipients per message was exceeded: the client should send the rest in another transaction.
Temporary authentication failure (for example, the credentials server is not responding) or TLS temporarily unavailable when STARTTLS is requested.
The server cannot accommodate the parameters sent in MAIL FROM or RCPT TO right now, but might accept them later.
Reply to ETRN: the server cannot process the message queue for the requested node right now.
Reply to ETRN: the requested node or domain is not allowed to request delivery of its queue.
The server does not recognize the command, or the line is too long. AUTH also uses it when a line of the exchange exceeds the maximum allowed length.
The command is valid, but its parameters or arguments are not: for example, a malformed address in MAIL FROM or an invalid name in EHLO.
The server recognizes the command but does not implement it or has it disabled, like VRFY or EXPN on many servers.
The commands arrived in the wrong order, for example RCPT TO before MAIL FROM, or DATA without valid recipients. Some servers return it when you try to send without authenticating.
The server does not accept the specified parameter, for example an AUTH mechanism it does not support.
The host does not accept mail of any kind. It is sent as the greeting instead of 220, and the client must not retry.
The server requires authentication, or starting TLS with STARTTLS, before accepting the command. Typical when using submission port 587 without credentials.
The chosen authentication mechanism is too weak according to the server's policy. Some providers return it when they require app passwords or OAuth.
Wrong username or password, or credentials rejected. Accompanied by the enhanced code 5.7.8.
The chosen authentication mechanism is only allowed over an encrypted connection: STARTTLS must be run first.
The mailbox does not exist or is unavailable, or the message was rejected by policy (spam, blacklists, SPF, DKIM or DMARC). The enhanced code that accompanies it indicates the specific cause.
The recipient is not local and the server does not forward the message; it may indicate which address to send it to.
Storage allocation exceeded: the recipient's mailbox is full or the message exceeds the maximum size advertised by the SIZE extension.
The email address is invalid or not allowed, for example because of incorrect syntax or because the sender is not allowed to use that address.
The transaction failed. As the initial greeting it means there is no SMTP service for that client; after DATA, that the message was rejected, often because of its content or the sender's reputation.
The server does not recognize or implement an extension parameter sent in MAIL FROM or RCPT TO.
The recipient's domain publishes a null MX (an MX record pointing to “.”): it declares that it does not accept mail, so there is no point in retrying.
Enhanced status codes (RFC 3463)
Status with no further detail: used when only the class of the result is known (success, transient or permanent failure).
There is a problem with an address in the message that does not fit the more specific codes.
The recipient's mailbox does not exist on the destination server. This is the classic bounce for a mistyped address or a closed account.
The destination domain or system does not exist or cannot accept mail, for example because the domain does not resolve.
The recipient address has invalid syntax.
The recipient address matches more than one mailbox on the destination system.
The recipient address is valid. Appears as 2.1.5 in the positive reply to RCPT TO.
The mailbox existed but has moved, and there is no known forwarding address.
The sender address has invalid syntax.
The sender's domain does not exist or does not accept replies, for example because it has neither MX nor A records.
The message was delivered to a system that does not support status notifications, so its final delivery cannot be confirmed.
The recipient's domain publishes a null MX: it declares that it does not accept mail.
The mailbox exists, but something related to it prevented delivery and there is no more specific code.
The mailbox exists but is disabled and does not accept messages, for example a suspended account.
The recipient's mailbox has exceeded its storage quota.
The message exceeds the maximum size the recipient is allowed to receive.
The recipient is a distribution list and could not be expanded into its members.
The destination system had a problem that does not fit the more specific codes.
The destination mail system's storage is full.
The destination host is not accepting messages, due to an imminent shutdown, overload or maintenance.
The destination system does not support a feature the message requires.
The message exceeds the maximum size the server accepts for any recipient.
The destination system is misconfigured and cannot accept the message.
The message was accepted, but with a different priority than the one requested (MT-PRIORITY extension).
There was a network or routing problem that does not fit the more specific codes.
The destination server did not answer the connection attempt.
The connection was established but dropped or became unstable before the delivery was completed.
A directory service required for delivery failed, typically DNS resolution.
No route to the destination was found, for example because the domain has no usable MX or A records.
The mail system is congested and cannot process the message right now.
A routing loop was detected: the message went through the same servers too many times.
The maximum retry time expired and the message is discarded without having been delivered.
There was a delivery protocol problem that does not fit the more specific codes.
The command is invalid, not allowed at that point or not recognized.
The command has a syntax error and the server cannot interpret it.
The message has more recipients than the server accepts in a single transaction.
The command is valid, but its arguments are invalid or not supported.
There is a protocol version mismatch between the client and the server.
A line of the AUTH exchange exceeds the maximum length the server supports.
There was a problem with the message content that does not fit the more specific codes.
The destination does not support the content type of the message or of one of its attachments.
Delivering the message would require converting its content, but the sender prohibited it.
Delivering the message would require converting its content, and the server does not know how to do it.
The message was delivered, but information was lost in the content conversion.
The conversion of the message content failed.
The message content referenced by URL could not be retrieved (BURL extension).
The sender or the recipient does not support addresses with non-ASCII characters (internationalized email, SMTPUTF8).
The server needs to reply with UTF-8 text, but the client did not advertise SMTPUTF8 support.
The message has UTF-8 headers and cannot be transferred to one or more recipients that do not support them, so it is rejected.
Security status with no further detail. Appears on successful authentication (2.7.0), temporary AUTH failures (4.7.0) and policy rejections.
The sender is not authorized to send to that recipient: blocked because of a blacklist, reputation, anti-spam filtering or a disallowed relay attempt. In its 4.7.1 form it usually indicates greylisting.
The sender is not allowed to send to that distribution list.
The message would have to be converted from one security protocol to another, and that is not possible.
The message requires security features that the destination does not support.
A cryptographic operation failed in transport, for example signature verification or decryption.
The destination does not support the cryptographic algorithm used in the message.
The integrity check failed: the message was modified in transit or the checksum does not match.
The authentication credentials are invalid: wrong username or password.
The chosen authentication mechanism is weaker than the server's policy requires.
An external encryption layer, such as TLS, is required to use the requested authentication mechanism. Intended mainly for mechanisms that send the password in plain text.
The requested authentication mechanism is only allowed over an encrypted connection.
The user must change their password or switch to another authentication mechanism.
The account of the user trying to authenticate is disabled.
The server only accepts messages from systems it has an established trust relationship with.
The message priority is too low for it to be accepted right now (MT-PRIORITY extension).
The message is too large for the specified priority (MT-PRIORITY extension).
The mailbox has changed owner since the date given by the sender, so the message is not delivered (RRVS extension).
The recipient's domain has changed owner since the date given by the sender (RRVS extension).
The server cannot verify whether the mailbox has changed owner, as the sender requested (RRVS extension).
The message has no valid DKIM signature and the receiver's policy requires one.
The message has valid DKIM signatures, but none of them meets the receiver's policy (for example, because of the signing domain or the algorithm).
The message has no valid DKIM signature from the same domain that appears in the From header.
The sending IP is not authorized in the sender domain's SPF record.
The SPF evaluation returned an error, for example because of a malformed record or too many DNS lookups.
The sending IP has no reverse DNS (PTR), or the name it returns does not resolve back to that IP.
Several message authentication checks failed at once, such as SPF and DKIM.
The sender's domain publishes a null MX, so it could not receive replies or bounces, and the message is rejected.
The message appears to be part of a mass mailing of similar abusive messages.
Validation of the ARC chain failed; ARC preserves authentication results when the message passes through forwarders or mailing lists.
The message requires REQUIRETLS and the next server on the route does not support that extension, so it cannot be delivered with guaranteed encryption.
Paste the full server response, for example 550 5.7.1 Message rejected, to see both the basic and the enhanced code at once. For a basic code, the search also shows the enhanced codes that usually accompany it.
How it works
In an SMTP session, every client command (EHLO, MAIL FROM, RCPT TO, DATA…) gets a reply from the server that starts with a three-digit code. The first digit tells how it ended: 2 means success, 3 that the server expects more data, 4 a transient error and 5 a permanent error. The second indicates the area: x0z syntax, x1z information, x2z connections and x5z mail system. The text after the code is free-form and each server writes its own; software only looks at the number.
Since three digits say little about the cause, RFC 3463 defined enhanced status codes, in class.subject.detail format: 5.1.1 is a permanent failure (5) related to addressing (1) because the mailbox does not exist (1). The class repeats the meaning of the first digit (2, 4 or 5), the subject groups the cause and the detail pins it down. Servers that use them advertise it with the ENHANCEDSTATUSCODES extension in their EHLO reply, and the same code appears in the Status field of bounce messages.
The table brings together the basic codes from RFC 5321 and those added by commonly used extensions (AUTH, STARTTLS, ETRN and null MX), plus every enhanced code in the IANA registry, along with the basic codes each one usually appears with. Large providers add their own messages and help links, but always on top of these same numbers.
Examples
550 5.1.1 <nadie@example.com>: Recipient address rejected: User unknown in local recipient table5xx Permanent · X.1.1 Bad destination mailbox addressPostfix's typical bounce when the account does not exist. Retrying won't help: the address has to be fixed. If the same recipient used to work, the account has most likely been closed.450 4.2.0 <ana@example.com>: Recipient address rejected: Greylisted4xx Transient · X.2.0 Other or undefined mailbox statusGreylisting: the server temporarily rejects the unknown sender and expects it to retry. A legitimate mail server does so automatically after a few minutes and the message gets through; many spam tools never retry.AUTH LOGIN334 VXNlcm5hbWU6The 334 carries the challenge in Base64: VXNlcm5hbWU6 is “Username:” and the next one, UGFzc3dvcmQ6, is “Password:”. If the credentials are wrong, the server replies 535 5.7.8; if it requires encryption first, 538 or 530.Use cases
- Understand why an email bounced from the error message the server returned.
- Tell whether an error is transient and the queue will retry it, or permanent and you need to act.
- Diagnose authentication failures when setting up email sending from an application, a printer or a server.
- Interpret rejections caused by SPF, DKIM, DMARC, reverse DNS or blacklists in mail server logs.
- Classify bounces in a bulk email platform to remove nonexistent addresses.
- Read an SMTP session captured with telnet, openssl s_client or swaks.
Frequently asked questions
What is the difference between a 4xx and a 5xx error?
A 4xx is transient: the sending server keeps the message in its queue and retries it periodically, usually for four or five days, before giving up and generating a bounce. A 5xx is permanent: the bounce is immediate, and retrying the same message without changing anything will fail again.
Why does the reply contain two codes, such as 550 5.1.1?
The first is the three-digit basic code required by RFC 5321. The second is the RFC 3463 enhanced status code, which pinpoints the cause: a 550 can be due to a nonexistent mailbox (5.1.1), a policy block (5.7.1) or an SPF failure (5.7.23). For troubleshooting, focus mainly on the enhanced code.
What does the hyphen in 550-5.7.1 mean?
That the reply spans several lines. All of them carry the same code, but the intermediate lines separate it from the text with a hyphen and the last one with a space, so the client knows when the reply has ended. It is the same thing you see in the list of extensions returned by EHLO.
Why am I rejected with 550 5.7.1 if the address exists?
Because 5.7.1 is not about the recipient but about the sender: the server does not authorize you to deliver that message. The usual causes are that the sending IP is on a blacklist, that the domain's SPF, DKIM or DMARC check fails, that the IP has no reverse DNS, or that there was an attempt to use the server as a relay without authenticating. The text that comes with the code usually gives a clue.
Why do I get 530 or 535 when sending email from an application?
530 means the server requires authentication, or starting TLS, before accepting the message; 535 means the username or password is wrong. Check that the application uses port 587 with STARTTLS or port 465 with implicit TLS, that authentication is enabled and, with providers such as Gmail or Microsoft 365, that you use an app password or OAuth instead of your regular password.