SMTP status code: what does this reply or bounce code mean?
How does this check work, and what does the result tell you?
AdminKit's SMTP status code decoder reads the reply line or bounce text you paste, entirely in your browser, and explains the RFC 5321 reply code and the RFC 3463 enhanced status code in plain words — whether the failure is transient or permanent, and what a sending queue typically does next. It never contacts a mail server.
Part of the Email authentication cluster — more tools, guides and terms on email authentication.
Decoded entirely in your browser — nothing you paste is sent to AdminKit or anywhere else, and this tool never connects to a mail server or sends any mail itself.
What the result means
The basic reply code's first digit says whether the server's reply was a success, a transient failure or a permanent failure; the enhanced status code (when present) adds a registered, more specific reason. Both are a transcript of what the receiving server already decided — this tool explains the standard meaning, it does not re-run or second-guess the delivery attempt itself.
Next step
If the decoded reason points at authentication, confirm the record with AdminKit's SPF check, DKIM check or DMARC check. If you have the full bounce or the original message's headers, AdminKit's email header analyzer can trace the delivery path that led to it.
Keep this result
Copy a link to this check so you can share it or run it again later. Want a heads-up if something changes? That's early access, not a live feature yet — tell us and we'll set it up by hand.
How it works and limits
Paste a single SMTP reply line (e.g. 550 5.7.1 Message rejected) or a full bounce message and this tool decodes
it as you type, entirely in your browser — nothing you paste is sent to AdminKit or anywhere else, and the tool
never connects to a mail server itself. It is a reference and decoder, not a live SMTP client: it only explains the
text you already have.
What does the 3-digit basic reply code tell you?
RFC 5321 §4.2 defines every SMTP reply as a 3-digit code followed by free text. The first digit is the severity — 2 (success), 3 (intermediate, more input needed), 4 (transient failure, try again later) or 5 (permanent failure, something must change). The second digit groups the reply by category: 0 (syntax), 1 (information), 2 (connections), or 5 (mail system — where most delivery failures land); 3 and 4 are reserved and unused. The third digit adds server-specific detail within that category. This tool looks the full 3-digit code up against the standard ~24 codes RFC 5321 defines, where it is one of them, and always explains the first two digits even for a code it doesn’t recognize.
What is the enhanced status code, and why does it look like a version number?
Many servers also send an enhanced status code in class.subject.detail form, e.g. 5.7.1 — three numbers
separated by dots, not a software version. RFC 3463 defines the
class (2 = Success, 4 = Persistent Transient Failure, 5 = Permanent Failure) and eight subject groups
(0 = other/undefined, 1 = addressing, 2 = mailbox, 3 = mail system, 4 = network/routing, 5 = mail delivery
protocol, 6 = message content/media, 7 = security/policy). The detail number within a subject is registered
individually — RFC 5248 set up the registration process, and IANA’s
SMTP Enhanced Status Codes registry
is the live list, extended over the years by RFCs covering SMTP AUTH (RFC 4954),
internationalized addresses (RFC 6531), and SPF/DKIM/DMARC authentication
failures (RFC 7372), among others. This tool embeds that registry’s
subject/detail text so it can show the specific registered meaning alongside the class.
Limits
- This decodes the standard meaning of the codes only. The free text after the code (and often the detail behind a 5.7.1 or similar) is written by the receiving mail server and is not standardized at all — two servers can use the exact same code with very different wording, or non-standard wording entirely.
- A 5xx (or 5.x.x) code can still be a policy, reputation, or spam-filtering decision that the code’s registered
text alone does not fully explain — e.g.
5.7.1only tells you “delivery not authorized, message refused”, not which specific policy triggered it. - Not every subject.detail combination seen in the wild is in the current IANA registry; this tool still decodes the class and subject in that case and says plainly when the specific detail isn’t registered.
- This tool never sends mail, never connects to any mail server, and never validates whether a given code is the “correct” one for a situation — it only explains what the standards say a code means.
Once you’ve identified the failure as an authentication problem, confirm the underlying record with AdminKit’s SPF check, DKIM check or DMARC check, or trace the full delivery path with the email header analyzer.
Frequently asked questions
What does the first digit of an SMTP reply code actually mean?
RFC 5321 §4.2.1 defines it as the reply's severity: 2 means positive completion (success), 3 means a positive intermediate reply (the server wants more input, like after DATA), 4 means a transient negative failure (try again later, nothing needs to change), and 5 means a permanent negative failure (retrying the identical request is pointless — something has to change first).
Why does a bounce show both a 3-digit code and something like 5.7.1?
The 3-digit code is the basic SMTP reply code RFC 5321 requires every server to send; the dotted code is an optional enhanced status code RFC 3463 defines to give a more specific, machine-parseable reason using a class.subject.detail structure, registered in IANA's SMTP Enhanced Status Codes registry. Most modern mail servers send both together, but the enhanced code is not mandatory, so plenty of replies only carry the 3-digit code.
Is a 4xx code always safe to ignore?
No — a 4xx (transient) code means a standards-compliant sending queue should keep retrying for a while, but if the exact same 4xx keeps recurring for days, the underlying condition on the receiving side (a full mailbox, rate limiting, greylisting) has never actually cleared, and the message will eventually be bounced back as undeliverable once the sender's retry window expires.
Does decoding 5.7.1 tell me exactly why my message was rejected for policy reasons?
It tells you the general category — RFC 3463 defines 5.7.1 as "delivery not authorized, message refused", meaning the receiving server's policy engine (spam filter, authentication requirement, blocklist, etc.) refused the message — but the receiving server chooses what free text to attach after the code, and that text is where the specific reason usually lives. The code alone can't tell you whether it was SPF/DKIM/DMARC failure, a reputation block, or a content filter; read the free text and, if authentication is suspected, check the message with AdminKit's SPF, DKIM or DMARC check.