SMTP reply codes and enhanced status codes: what does a bounce code mean?

Key takeaways

• Every SMTP reply starts with a 3-digit code defined in RFC 5321 §4.2. The first digit is what matters most: 2 = done, 3 = send more, 4 = temporary failure, 5 = permanent failure.
• Many servers add an enhanced status code in class.subject.detail form, such as 5.7.1, defined by RFC 3463. The class matches the first digit; the subject says which part of the system failed.
• 4xx means “retry later, unchanged”. 5xx means “do not send the same thing again”. Treat a 4xx that repeats for days as a problem in its own right.
• The text after the codes is chosen by the receiving server and usually holds the specific reason. The codes give you the category.
• Paste a reply line or bounce into AdminKit’s SMTP status code decoder to see both codes explained, entirely in your browser.

What does an SMTP reply line contain?

Each time a sending server issues an SMTP command (MAIL FROM, RCPT TO, DATA and so on), the receiving server answers with exactly one reply. RFC 5321 says that “every command MUST generate exactly one reply”. A rejection you find in a bounce message is a copy of one of those replies.

550 5.7.1 Message rejected due to local policy. Contact postmaster.
│   │     └─ free text: written by the receiving server, not standardized
│   └─ enhanced status code (RFC 3463): class.subject.detail
└─ basic reply code (RFC 5321): severity + category + detail

The basic code is mandatory. The enhanced code comes from a separate extension, RFC 2034, which a server advertises as ENHANCEDSTATUSCODES in its EHLO response. Once a server supports it, RFC 2034 says the codes “must appear in all 2xx, 4xx, and 5xx response lines other than initial greeting and any response to HELO or EHLO”. The free text is entirely up to the receiving server.

The same codes appear in bounce messages. A Delivery Status Notification reports the enhanced code in its Status: field and usually quotes the original reply in Diagnostic-Code:. Our email bounces and backscatter explained guide covers how those notifications are generated and where they go; this guide is about reading the codes themselves.

How do you read the 3-digit reply code?

RFC 5321 §4.2.1 gives each digit a job. The first digit tells an “unsophisticated SMTP client” what to do next; the second says roughly what kind of error occurred; the third and any text carry the finest detail.

First digit	RFC 5321 name	What the sender should do
2	Positive Completion	Done. Move on to the next command
3	Positive Intermediate	Send the data the server is waiting for (for example, the message after 354)
4	Transient Negative Completion	The command failed this time. Keep the message queued and try again later
5	Permanent Negative Completion	Do not repeat the exact request. Something has to change first

The RFC’s rule of thumb for choosing between 4 and 5 is useful when you read codes too: a reply is 4yz if the command “can be successful if repeated without any change in command form or in properties of the sender or receiver”. In other words, 4xx says “the same thing might work later”, and 5xx says “the same thing will not work”.

The second digit groups replies by function: 0 for syntax, 1 for information, 2 for the connection, and 5 for the mail system, where most delivery failures land.

These are the codes you will meet most often, with the wording RFC 5321 §4.2.3 gives them:

Code	RFC 5321 meaning	Typical situation
250	Requested mail action okay, completed	Accepted
354	Start mail input	Server is ready for the message body
421	Service not available, closing transmission channel	Server is shutting down or limiting connections
450	Mailbox unavailable (e.g., mailbox busy or temporarily blocked for policy reasons)	Greylisting, temporary block
451	Requested action aborted: local error in processing	Temporary problem on the receiving side
452	Insufficient system storage	Also the correct code for “too many recipients”
550	Mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons)	Unknown user or policy rejection
552	Exceeded storage allocation	Message too large or mailbox over quota
553	Mailbox name not allowed	Address syntax not accepted
554	Transaction failed	Generic rejection, often after DATA

One historical quirk: RFC 5321 §4.5.3.1.10 notes that older software used 552 for “too many recipients”. The correct code is 452, and clients “SHOULD treat a 552 code in this case as a temporary, rather than permanent, failure”.

What is an enhanced status code?

The basic code is coarse: 550 covers both “no such user” and “rejected by spam policy”. RFC 3463 adds a second, more specific code with the structure class "." subject "." detail. In the RFC’s words, the first part “indicates whether the delivery attempt was successful”, the second “the probable source of any delivery anomalies”, and the third “a precise error condition”.

The class has three values, and RFC 2034 requires it to agree with the basic code’s first digit:

• 2.x.x Success. The delivery action succeeded.
• 4.x.x Persistent Transient Failure. The message is valid, but a temporary condition persisted; “sending in the future may be successful”.
• 5.x.x Permanent Failure. The failure is “not likely to be resolved by resending the message in the current form”.

The subject tells you where to look:

Subject	RFC 3463 name	Where the problem usually is
x.0.x	Other or Undefined Status	No more detail available
x.1.x	Addressing Status	The sender or recipient address itself
x.2.x	Mailbox Status	The recipient’s mailbox (full, disabled)
x.3.x	Mail System Status	The destination mail system
x.4.x	Network and Routing Status	DNS, routing or connections between servers
x.5.x	Mail Delivery Protocol Status	The SMTP conversation itself
x.6.x	Message Content or Media Status	The message content or format
x.7.x	Security or Policy Status	Authentication, spam filtering or policy

RFC 3463 tells clients to report the class “even where subsequent subject sub-codes are unrecognized”, and the subject even when the detail is unknown. AdminKit’s decoder follows that: it always explains the class and subject, and says plainly when a specific detail is not in its copy of the registry.

Where do the detail numbers come from?

Detail numbers are registered individually. RFC 5248 created a registry for them, and the live list is IANA’s SMTP Enhanced Status Codes registry. Later RFCs keep adding entries. RFC 7372, for example, registered codes for email authentication failures so a receiver no longer has to fall back on the catch-all 5.7.1.

The registry also lists, for each code, which basic reply codes it is usually paired with. That pairing is useful when the free text is unhelpful.

What should you do with the common codes?

The table pairs frequently seen enhanced codes with their registry names and a sensible first step. The meanings come from the IANA registry; the actions are practical advice, not part of any standard.

Code	Registry name	What it usually means	First step
5.1.1	Bad destination mailbox address	The user part of the address does not exist	Check for typos; remove the address from lists
5.1.10	Recipient address has null MX	The recipient domain publishes a null MX: it accepts no mail	Stop sending to that domain
4.2.2 / 5.2.2	Mailbox full	Recipient over quota; the registry says this “should be used as a persistent transient failure”	Wait and let the queue retry; tell the recipient by another channel
4.4.1	No answer from host	The destination server did not respond	Usually clears by itself; check the recipient’s MX records if it persists
4.4.7	Delivery time expired	Your server gave up after retrying	Find the earlier 4xx reply that kept repeating
5.7.1	Delivery not authorized, message refused	Policy rejection: filtering, blocklist or a rule on the receiving side	Read the free text; check authentication and IP reputation
5.7.23	SPF validation failed	The receiver’s SPF check returned fail	Fix the SPF record for the envelope sender’s domain
5.7.26	Multiple authentication checks failed	More than one authentication check failed; the code does not say which	Check SPF, DKIM and DMARC for the sending domain

5.7.1 deserves a special note. The registry says the condition “can be the result of per-host or per-recipient filtering”, and RFC 3463 explicitly “does not discuss the merits of any such filtering”. The code tells you a policy said no. It does not tell you which policy. The specific reason, if the receiver chose to share it, is in the free text. Some large providers also document their own usage: Microsoft’s Exchange Online NDR reference lists 5.7.1 as “Delivery not authorized” and describes the conditions that cause it in that service.

How long does a sender retry a 4xx?

A temporary failure does not bounce straight away. The sending server keeps the message in its queue and tries again. RFC 5321 §4.5.4.1 says “the retry interval SHOULD be at least 30 minutes” and that “the give-up time generally needs to be at least 4-5 days”. Exact schedules are set by each mail server’s configuration.

That has two consequences when you are troubleshooting:

1. A delivery delay notice is not a bounce. Many servers send a “still trying” warning to the sender after a few hours. The message is still queued.
2. The final bounce can arrive days later, carrying 4.4.7 or the last temporary error. The real cause is whatever the receiver kept saying during those days, so look for the repeated 4xx reply in the bounce or in your server logs.

A 4xx that repeats for every attempt usually points to something only the receiving side can clear (a full mailbox, rate limiting, a temporary block) or to a sending problem that never changes between attempts.

How do you fix authentication-related rejections?

When the code or free text points at authentication (5.7.1 with an SPF or DMARC mention, 5.7.23, 5.7.26), the fix is in your DNS, not in the message:

1. Confirm what the receiver saw. If you have a copy of a delivered message from the same sender, its Authentication-Results header shows the verdicts; see how to read email headers to trace a message, or paste them into the email header analyzer.
2. Check the live records with AdminKit’s SPF check, DKIM check and DMARC check.
3. If SPF returns an error rather than a fail, the record may be over the 10-lookup limit; fixing SPF too many DNS lookups walks through that case.
4. If the rejection mentions a blocklist, check the sending IP with the blacklist check.

What can the AdminKit decoder not tell you?

The SMTP status code decoder explains what the standards say a code means. It does not send mail, connect to any server, or decide whether a server chose the right code. Two servers can return the same code for different reasons, and some return codes that are not in the registry at all; in that case the decoder still explains the class and subject. For the full context, combine the decoded codes with the free text and, where you have it, the delivery trace.

This guide is part of AdminKit’s email authentication cluster.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.