SMTP Response Codes
The three-digit replies a mail server sends after each command.
Codes like 250, 450, and 550 each map to a different verdict.
Definition
SMTP response codes are the three-digit codes a mail server returns after every command in an email delivery attempt. A 2xx code means success (250 OK), a 4xx code means a temporary failure worth retrying (as with greylisting), and a 5xx code means a permanent rejection, such as a mailbox that does not exist.
We open millions of live SMTP conversations to verify email addresses, and the response code returned at each step is the entire basis of a verdict. There is no hidden signal beyond it: just a three-digit number the receiving server sends back, and a short human-readable message alongside it. Reading those codes correctly, and knowing which ones to trust, is most of what separates a reliable verification result from a guess.
The three code classes
Every SMTP response is a three-digit number, and the first digit tells you its class. That single digit is the fast read. The other two digits add detail but rarely change what you should do next.
- 2xx: success. The command or message was accepted.
250 OKis the one you will see by far the most often, returned after a sender identifies itself, names a recipient, or hands off a completed message. - 4xx: temporary failure. The server is declining for now and asking the sender to try again later. This is the class behind greylisting, an overloaded queue, or a policy check still in progress.
- 5xx: permanent failure. The server will never accept this exact command, no matter how many times it is retried. A nonexistent mailbox, a rejected domain, and a malformed address all land here.
The specific codes that matter
Most of the practical signal in an SMTP conversation comes down to a handful of codes, encountered mainly at the RCPT TO step where a sender names the recipient.
250: Requested action completed. The default success code, and the one that matters most when it appears atRCPT TO: it means the server accepted the named address.251: User not local, will forward. The address is not on this server, but the server will relay the message onward anyway. Less common, but still a success response.421: Service not available, closing the connection. Often a rate limit or a server shutting down its listener. The whole session ends, not just one command.450: Mailbox unavailable, temporary. The most common face of greylisting: the server is not refusing the address, just declining to confirm it on this attempt.451: Local error in processing. A catch-all for temporary trouble on the receiving end, such as an overloaded content filter or a transient backend failure.550: Requested action not taken, mailbox unavailable. The definitive “this address does not exist” response, and the code most directly responsible for a hard bounce.551: User not local, please try an alternate path. The server refuses to relay to this recipient at all, unlike the softer251.553: Mailbox name not allowed. The address as submitted is malformed or blocked by policy, distinct from a missing mailbox.
How response codes become an email verification verdict
A verification probe behaves like a real sending server up to the point of actually delivering the message: it opens a connection, introduces itself, and names the recipient with RCPT TO, then reads the code the receiving server sends back. That single code is the raw material for the verdict.
A clean 250 at that step reads as deliverable, the strongest live signal available short of actually sending mail. A 550-class response reads as invalid, since the server has stated outright that the mailbox does not exist or will not accept mail. A 4xx code is the hard case: it is neither a pass nor a fail, only a request to come back later. Reporting that instant as a flat “unknown” is the lazy read. We treat it as the temporary signal it is and re-probe the way a legitimate sender would, resolving most of them into a real answer instead of a shrug.
There is one more wrinkle a response code alone cannot resolve: a catch-all domain returns the same 250 for every address it is asked about, real mailbox or not, because it is configured to accept anything. A verification engine that trusts a bare 250 on a catch-all domain will happily certify addresses that were never real, so catch-all detection has to sit alongside the raw code rather than deferring to it blindly.
- This code-reading logic is the same engine behind the free email checker and the verification API, so you get a resolved verdict, not a raw code dump.
- To watch the exact codes a server returns in real time, open a live handshake with the SMTP test.
- To read the codes your own sends actually produced after the fact, inspect them with the bounce checker.
Read correctly, SMTP response codes turn a delivery attempt from a black box into a fully legible conversation: what succeeded, what to retry, and what will never work. For teams verifying lists at scale, where a misread 4xx or an unquestioned catch-all 250 is the difference between a clean list and a pile of silent bounces, the volume tiers are on the pricing page.
Explore more from Verifox
SMTP response codes sit inside a wider set of deliverability concepts. These are the terms most worth understanding next.
Common questions
SMTP response codes, answered
A three-digit code is often the only explanation you get for why an email failed. Here’s how to read the ones that actually matter.
What are SMTP response codes in simple terms?
They are the short numeric replies a mail server gives after every step of a delivery attempt, from saying hello to naming a recipient to sending the message body. Each code tells the sending side exactly what happened: accepted, try again later, or rejected outright.
Think of them as the receiving server grading each step of the conversation in real time. A human reading a mail log can tell the whole story of a delivery attempt just from the sequence of codes it produced.
What do the SMTP code classes (2xx, 4xx, 5xx) mean?
The first digit is the class, and it is the only part you truly need to react to. 2xx means success: the command or message was accepted. 4xx means a temporary failure: the server is asking the sender to try again later. 5xx means a permanent failure: the server will never accept this as written.
The full three digits add detail on top of that class, but the first digit alone is enough to decide whether to retry, wait, or give up. This handshake runs over SMTP, the protocol every mail server speaks.
What does a 250 response code mean?
250 OK is the standard success response. It shows up after a sender identifies itself, names a recipient, or hands off a completed message, and it means the receiving server accepted that step without objection.
When it appears at RCPT TO, the step that names the recipient, it usually means the mailbox exists and the server is willing to take mail for it, which is the strongest live signal a verification probe can get.
What do 450 and 451 mean, and should I retry?
Both are temporary failures. 450 typically means the mailbox is unavailable right now, often because of greylisting or a policy check that has not cleared yet. 451 signals a local error on the receiving side, like an overloaded server or a temporary content check that failed to complete.
Yes, retry. A well-behaved sending server queues the message and tries again after a short delay, exactly as it would for any greylisting deferral. Giving up on a 4xx throws away mail that would likely have gone through.
What do 550, 551, and 553 mean?
These are permanent failures, and retrying will not help. 550 is the classic “mailbox does not exist,” the code you get for a typo’d or deleted address. 551 means the user is not local and the server will not relay to them. 553 flags a malformed or disallowed mailbox name in the command itself.
Any of these at RCPT TO is a definitive signal that the address is invalid, which is exactly the response that produces a hard bounce if you send to it anyway.
How do SMTP response codes shape an email verification verdict?
A verification check opens a real SMTP conversation and reads the code the server returns at RCPT TO, the step that names the recipient, without ever sending the message. A clean 250 there is treated as deliverable. A 550-class code is treated as invalid.
A 4xx code is neither: it means the server would not give a definitive answer at that moment, which we resolve with a measured retry rather than reporting a flat “unknown.” You can watch this play out live with the free email checker.
Why does a catch-all server return 250 for every address?
A catch-all domain is configured to accept mail for any address at all, real mailbox or not, so it replies with the same 250 OK at RCPT TO whether you probe a real employee or a random string. The response code alone cannot tell them apart.
That is why a raw 250 is not automatically treated as proof of a deliverable mailbox. A serious verification engine separately flags catch-all domains and scores their addresses with lower confidence instead of a blanket pass.