SMTP codes can be so confusing, especially those SMTP response codes and SMTP error codes like the dreaded SMTP error 550. These are often returned in bounced email, such as “550 Requested action not taken: mailbox unavailable” or “550 5 2 1 mail from refused spam site.” They are 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? Why should you care and what should you do? And why do we say that SMTP error 550 is dreaded?
SMTP Error Codes and What They Mean
First, ‘SMTP’ stands for Simple Mail Transfer Protocol. It is the way that your sending email server connects with the email server on the other end.
Here is a general list of SMTP 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
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.
And, of course, the 500 series of SMTP error codes, which are the SMTP error codes to which you, as a general email sender, will most often see, and to which you need to pay attention. Unfortunately many receiving systems seem to mix and match these error messages, rather than adhering to the prescribed message code meaning. (IANA has a full comprehensive list of SMTP error codes and what they all mean.)
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 (i.e. those in the 500+ range) and of those, the ones that you really need to worry about are the ones in the 55X range – i.e. 550-559. And of those, by far the most common one and 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 email 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 administering 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 continue to 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 inbox providers and other 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 blocking 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 blocklisted, and you’ll need to deal with that immediately.