What Those SMTP Error Codes Mean and Why You Should Care

Anybody who sends email has seen them, in one form or another - those SMTP error codes, often returned in bounced email, such as “550 Requested action not taken: mailbox unavailable” or “550 5 2 1 mail from refused spam site.” These are often in response to SMTP commands that have ‘gone wrong’ between your email server that sent the email, and the receiving email server that is unable to deliver it (or refuses to deliver it) for some reason. But what exactly do they mean? And why should you care? (’SMTP’ stands for Simple Mail Transfer Protocol.)

First, here is a list of SMTP codes and error codes, and what each message is supposed to say and mean:

211 - A system status message.
214 - A help message for a human reader follows.
220 - SMTP Service ready.
221 - Service closing.
250 - Requested action taken and completed.
251 - The recipient is not local to the server, but the server will accept and forward the message.
252 - The recipient cannot be VRFYed, but the server accepts the message and attempts delivery.

354 - Start message input and end with .. This indicates that the server is ready to accept the message itself

421 - The service is not available and the connection will be closed.
450 - The requested command failed because the user’s mailbox was unavailable (such as being full). Try again later.
451 - The command has been aborted due to a server error. (on their side)
452 - The command has been aborted because the server has insufficient system storage.

500 - The server could not recognize the command due to a syntax error.
501 - A syntax error was encountered in command arguments.
502 - This command is not implemented.
503 - The server has encountered a bad sequence of commands.
504 - A command parameter is not implemented.
550 - The requested command failed because the user’s mailbox was unavailable (such as not found)
551 - The recipient is not local to the server.
552 - The action was aborted due to exceeded storage allocation.
553 - The command was aborted because the mailbox name is invalid.
554 - The transaction failed for some unstated reason.

Unfortunately, many receiving systems seem to mix and match these error messages, rather than adhering to the prescribed code messages.

The good news is that the SMTP error messages you need to worry about as an email sender are really primarily limited to just a few - those in the 5XX range - and of those, the ones that you really need to worry about are the ones in the 55X range - i.e. 550-559. Of these, by far the most common one - the one that as a sender you will see most often and to which you must pay immediate attention - is the 550 SMTP error code, which can range from “user not found” to “mailbox unavailable” to any number of other similar variations, but which for you, dear mail sender, should almost always be read to mean “remove this email address from your mailing list immediately.”

(On the other hand, your mail server administrator should care deeply about many more of these codes, however we assume that if they are administoring your outbound mail server, they are already familiar with them.)

So, back to that 550 error code. Almost always, when you get an email bounced back (or inserted in your mail log!) with a 550 error code, it means that the receiving system could not deliver your email to the user to whom it was addressed because the mailbox is unavailable. Almost always, this means that the inbox either no longer exists, or that it never existed!

Why would you have an email address on your mailing list that has never existed? There could be a lot of reasons, including that someone entered it wrong, or that someone intentionally entered a fake email address into your system (such as when you require a user to divulge an email address in order to receive a download, etc.).

Regardless of how it ended up on your mailing list, if you send a mailing to it, it tells the receiving system one sure thing: that you don’t confirm email addresses before adding them to your mailing lists.

And, if you send email to that same non-existent email address after receiving the 550 message that the mailbox doesn’t exist, it tells that receiving system that not only don’t you confirm email addresses, but that you don’t care very much about list hygiene - i.e. that you don’t maintain your mailing lists according to best practices, either.

And, having determined this, very soon those receiving systems, including ISPs, will simply stop delivering your email to the inbox - first diverting it to the junk folder, then not delivering it at all, and then perhaps even blacklisting all of your email.

Now, it’s possible that a mailbox will be unavailable because a user has let their inbox get full. And we often get asked whether, because of that possibility, it’s ok to not remove an email address which has returned a 550 error?

Think about this: in this day and age of nearly unlimited email storage (nearly all ISPs now offer multiple Gigs of email storage), just how inactive does a user have to be in order for their inbox to fill up? And, even if they are going to come back some day and clear out their inbox, do you think that they are really going to stop to read your email? Or will they delete it unopened and unread, creating even more problems for you?

The bottom line is: why hang on to an email address that belongs to a user who will never be a positive asset for you, and can only cause you trouble?

So the next time an email that you send bounces back, take a good look at the information in the bounce message, and take the appropriate action based on that message. And don’t forget to check your mail logs for bounce messages too!

P.S. If you are actually receiving bounce messages that include “mail from refused spam site” or a similar message, the odds are good that your mail already has been blacklisted, and you’ll need to deal with that immediately.