SMTP Error Codes, From 211 to 556

An SMTP server answers every command with a three-digit reply code followed by a line of text. The first digit says whether the command worked: 2 for success, 3 for "send me more", 4 for a temporary failure, 5 for a permanent one. The second digit narrows the category. The third is the finest gradation. The text after the digits is written for a human, not for a parser.

That first digit is the only part you can act on without reading anything else. A 4xx means queue it and try again. A 5xx means stop. Everything below is the full list, grouped by class, with one line on what each code actually calls for.

How is an SMTP reply code structured?

RFC 5321 assigns each digit a job. The first denotes whether the response is good, bad, or incomplete. The second tells you approximately what kind of error occurred. The third, plus any supplemental text, carries the finest detail.

First digit:

Second digit: x0z syntax, x1z information, x2z connections, x3z and x4z unspecified, x5z mail system status.

RFC 5321 also gives a rule of thumb for deciding whether something belongs in 4yz or 5yz. A reply is 4yz if repeating the identical command, unchanged, could plausibly succeed later without the sender or receiver changing anything. If it could not, it belongs in 5yz.

Which SMTP codes mean success?

These are the 2xx and 3xx replies. Nothing here is an error, though one of them is routinely misread as proof of something it does not prove.

One consequence worth knowing. Once a server returns a 2yz after the <CRLF>.<CRLF> that ends a DATA block, it has accepted responsibility for delivering the message, or for retrying transient failures a reasonable number of times under its own policy. After that point the outcome is the receiving server's problem, and any failure reaches you as a bounce rather than as a live reply code.

What do the 4xx SMTP codes mean?

Temporary. The condition is expected to clear. Queue the message and retry, and do not remove the address from your list.

How long should a sender retry?

RFC 5321 sets a floor and a ceiling. Delay at least 30 minutes before the first retry after a failure. Keep retrying until the message is transmitted or you give up, and the give-up time generally needs to be at least four to five days. The pattern the spec describes, on the observation that failures are usually a crashed target system or connection, is two connection attempts in the first hour the message is queued, then backing off to one attempt every two or three hours.

One related rule that catches senders out: 5yz responses to the MAIL command must not be cached. A permanent failure applies to that transaction, not forever.

What do the 5xx SMTP codes mean?

Permanent. Repeating the same command in the same form will fail the same way. Fix the request, fix the address, or stop sending to it.

RFC 5321 is specific about the 500 and 502 split: 502 should be used when the command is recognized but not implemented, and 500 when the command is not recognized at all.

452 and 552 are not the same code

They are frequently described as if 552 had been retired in favour of 452. That is not what the spec says. Both are current, and they describe different conditions. 452 is "insufficient system storage", a server-wide problem, and it is transient. 552 is "exceeded storage allocation", the quota on that message or that mailbox, and it is permanent. A full mailbox and a full mail server are different failures with different remedies.

Which codes are not in RFC 5321?

Two: 521 and 556. Neither appears in RFC 5321's numeric list, which runs from 211 to 555. Both were added by RFC 7504 in 2015, which updates RFC 5321.

556 exists for the null MX case. When a relay can determine, without opening a connection, that the domain in a forward-pointing address does not accept mail, 556 is the appropriate reply. 521 is narrower than 554, which RFC 5321 recommends for a wider variety of refusals including mail not accepted from or for particular sources, destinations, or addresses.

This matters when reading old documentation. 555 comes from RFC 5321 in 2008. 556 comes from RFC 7504 in 2015. They are seven years and one document apart, and they are not a matched pair.

What are enhanced status codes?

The three-digit reply is coarse. RFC 3463 defines a second code that travels alongside it, in the form class.subject.detail, for example 5.1.1.

The class is restricted to three values: 2 for success, 4 for persistent transient failure, and 5 for permanent failure. No sub-code may carry a leading zero. The subject sub-code names the probable source of the problem, and it has eight defined values.

The detail sub-code is the precise condition. Three worth memorising, because they cover most of what lands in a bounce log:

• 5.1.1 Bad destination mailbox address. The mailbox in the address does not exist. RFC 3463 defines it as useful only for permanent failures. This is the classic hard bounce.
• 4.2.2 Mailbox full. The recipient exceeded a per-mailbox quota or physical capacity, and the RFC specifies it should be treated as a persistent transient failure.
• 5.7.1 Delivery not authorized, message refused. In RFC 3463 this is per-host or per-recipient filtering, and it is permanent.

Read the two codes together, not separately. The three-digit reply tells you how to behave. The enhanced code tells you why.

What do Gmail, Yahoo and Outlook actually return?

Provider behaviour is where the spec meets the real bounce log. All three publish their own references, and all three layer their own conventions on top of RFC 3463.

Gmail. Returns 450 4.2.1 when the recipient is receiving mail too quickly, 421 4.7.0 when the sending IP has no PTR record or the forward DNS does not point back to it, and 421 4.7.28 when it detects an unusual rate of unsolicited mail from an IP. 550 5.1.1 is "the email account that you tried to reach does not exist". 553 5.1.2 means the recipient domain could not be found. 552 5.2.2 is an inbox out of storage space. 550 5.4.5 is a daily sending limit. Gmail appends gsmtp to all of its error text, and gcdp when the block came from a Google Workspace administrator's custom rule.

Yahoo. Frames its bounces around two buckets. 421 and 451 are temporary problems, tied to traffic pattern, complaint rate, or busy servers, and may be retried later. 553 and 554 are permanent. Yahoo's instruction to senders is explicit: do not retry a 5xx, and remove addresses that generate 5xx bounces from the list.

Microsoft / Exchange Online. Documents the entire 5.7.0 through 5.7.999 range as a security or policy setting in the sending or receiving organization, which is consistent with RFC 3463's X.7 subject class. Microsoft also uses proprietary extended detail codes that are not in the RFC 3463 registry, such as 5.7.240 through 5.7.246, 5.1.241, and 4.4.317. A rate-limit example is 432 4.3.2, recipient thread limit exceeded, meaning the recipient mailbox is throttled for receiving too many messages too quickly.

One caveat on 4.7.0. RFC 3463 defines X.7.0 only as "other or undefined security status". The reading of 4.7.0 as a temporary rate limit or reputation block is a provider convention, Gmail's in particular, not something the RFC states.

Why SMTP codes matter for email validation

An SMTP probe asks a mail server whether it will accept a given recipient, by opening a session and issuing RCPT TO without ever sending a message. The reply code is the answer. Two common server configurations make that answer unreliable.

Catch-all servers. A catch-all, also called accept-all, is configured to return 250 for essentially any recipient at the domain, whether or not a mailbox exists behind it. A 250 from such a domain confirms that the SMTP transaction was accepted, not that the mailbox is real. Catch-all is operational terminology, not something any RFC defines, which is part of why behaviour varies. You can check whether a given domain behaves this way with our catch-all email checker.

Greylisting. A greylisting server builds a triplet from the sending IP, the envelope sender, and the envelope recipient. On first sight of a new triplet it rejects the delivery with a temporary error, on the theory that a legitimate sender will retry after the delay window and a spam sender will not. Postgrey, one of the widely deployed implementations, uses a five minute first-seen window by default. The exact reply code and text are implementation specific and not standardised, so expect a 4xx and do not build logic around one particular string.

The consequence for validation is the same in both cases. A single probe cannot always separate a valid address from an invalid one. A catch-all returns 250 for both. A greylisting server returns a 4xx for both, on the first attempt, regardless of whether the mailbox exists. Any validation result that reports a binary valid or invalid on one SMTP round trip is discarding that ambiguity rather than resolving it. Trueguard's email validation returns the ambiguous cases as ambiguous, including catch-all domains, rather than guessing.