Do statements like “421. Try again later” or “550. Requested action is not taken: inbox is unavailable” pop up every once in a while when you send your email marketing campaigns and transactional emails?
I’m sure they do. As these are two of the most common SMTP error messages. But since these statements are so short and not descriptive, they don’t give senders much information about how to deal with sending errors. They leave them puzzled and concerned.
In this post, we’ll help you get past that. We will take a walk down the lane of SMTP error codes and suggest a recommended course of action for each of these messages.
Heads up: the good news is not all SMTP reply codes are error messages (we’ll go deeper into that in a while).
What are SMTP reply codes?
To share server status updates with users, SMTP employs a basic status code. It includes three digits and a text part. The numeral section of the code is designed for machine processing, while the text part helps users make sense of the message.
Below we’ll analyze the most common error types. To see the full list, read our guide highlighting all SMTP error codes and responses.
Cracking the code: what does the first digit mean?
Each digit in the string of three numbers has a specific meaning — the first one is the most important since it specifies the class of the alert.
- 2 marks the class of positive responses. If you see a reply code that looks like “2xx”, it means that a requested action has been completed successfully. A few examples of class 2 codes are “220. The server is ready” or “221. Closing connection”.
- 3 marks a class of reply codes stating positive intermediate responses. Simply put, these alert users that the server accepted a command but, due to technical difficulties, the operation is on hold. You may have seen class 3 reply codes like “354. Start mail input end”. While it’s hard to make sense of it, all the code wants to say is that the server has received the data for “To” and “From” fields and is waiting for a sender to specify the body of the message.
- Reply codes that start with 4 alert users about transient negative replies. This means the server was unable to accept the action or complete a command. However, as the name suggests, the errors of the 4 class codes are not permanent — once you fix server-side breakdowns, feel free to send a command to the server one more time. “420. Timeout connection problem” is a common transient error message, which means that a recipient’s firewall is blocking a sender’s email.
- 5 at the beginning of a reply code is an indication of the infamous “permanent error” messages. Unlike the errors that start with a 4, these errors won’t be fixed by simply reinitiating a command sequence. To deal with these errors, users need to contact email hosting providers and fix infrastructure breakdowns. Thus, eliminating 5xx errors typically calls for time and resources on the behalf of the sending team.
What went wrong? The second digit is a hint
So, the first digit helps teams identify the type and severity of the SMTP error. The second digit in the code is just as important as it hints at where the root of the problem is. Here’s a breakdown of what different digits in the second position in the code mean:
- 0 points to syntax errors. x0x error messages may show up when a user tries to run a non-existent command or makes a structural error when initiating the sequence. Think about messages like “500. Syntax error. Command not recognized”, which shows up when senders try running commands that don’t fit any functional category of the server.
- 1 marks information errors and requests. Messages like “211. System Help Reply” guide users to the help center in case they have questions about SMTP servers.
- 2 deals with connection issues, letting senders know that transmission is the root of the issue. In “420. Timeout connection problem”, users get an alert that, due to security or hardware issues, the recipient’s server cannot be accessed. In most cases, the error auto-resolves if you try running the command again later.
- 3 and 4 both mark unspecified errors. Yes, it is frustrating that we don’t have more hints on common errors like 431, 530, or 541 — so the least senders can do is get by with the hints of the text message and the meaning behind the remaining two digits.
- If you see a 5 as the second digit of the reply code, it means that the mail system is responsible for the error. The most common example of an x5x code is “550. Requested actions not taken. Inbox unavailable” which means that there’s no email address that matches the email you entered in “To”.
Third digit? We have no clue (yet)
In the documentation issued by RFC, there are no specifications as to what the third digits in the code are referring to. All we know is that they give advanced software information, contributing to more detailed readings.
The third digit in an SMTP reply code is called the implementor and ranges from 0 to 9.
Troubleshooting most common SMTP reply codes
Now that you know how to read the numeral part of SMTP reply codes, it’s time to decipher text messages (that, at times, are just as cryptic) and discover what is the best way to react to common error messages.
All in all, there are around 25 reply codes servers return to users. For the sake of efficiency, we will not review all of them and instead focus on troubleshooting the most common error messages.
| Reply code and message | Meaning | Next steps |
|---|---|---|
| Class 2 — Errors | ||
| 220. The server is ready | The server is ready to run commands | This message indicates that the system is working. Start entering recipient data and the body of the message. |
| 250. Requested mail action OK completed | This lets the sender know that the email was delivered successfully. | Sit back and wait for a reply. 🙂 |
| 252. Cannot VRFY the user – will attempt to deliver | As the text part suggests, the server recognized the recipient’s address as valid but could not verify it. Nevertheless, the SMTP will complete the delivery. | The email should be delivered even when not verified. However, after the server returns a 252 reply code, it’s better to double-check that the address is correct. |
| Class 3 — Reply codes | ||
| 354. Start mail input; end with <CRLF>, <CRLF> | This message is a response from the server — it lets a user know that the server has successfully retrieved sender and recipient data and is waiting for input in “Body”. | Since the reply code is a status update, not an error, there’s no need to fix anything. Enter the body of the message and hit the “Send” button. |
| Class 4 — Reply codes | ||
| 421. Service not available | This is a temporary error caused by a shutdown of the recipient server by the administrator. | Reconfigure the SMTP server in your email client. Remove your account from the client and log in again. Change the sending port from 25 to 587 (we do not recommend using 465 or 2525 since neither are RFC compliant). Disable the VPN network if you use one or ask the provider to whitelist the email server. |
| 442. The connection was dropped in transmission | This error points to Internet connection issues. | Restart your router or contact the Internet provider to troubleshoot connection errors. |
| Class 5 — Permanent errors | ||
| 550. Requested actions not taken. Inbox unavailable | The recipient’s address does not exist (the text part can also read “550 No such user here” or “550. Invalid recipient”.The server returns this message if the firewall blocks the sender. A 550 error also shows up if the sender address is invalid. The server returns 550 when a sender attempts to send emails from addresses that require SMTP authentication without providing credentials. | Check for typos in both “From” and “To”. Find out if your IP is blacklisted and change the address to avoid firewall blocks. Change the SMTP port. The default SMTP port 25 is often used for spamming, so ISPs are more likely to flag it. Enable SMTP authentication in your browser. |
| 554. Transaction failed | Similarly to 550, 554 is returned if the delivery is blocked by the recipient’s firewall or the address you entered in the “To” field does not exist. | Check whether the IP is on a block list. Ask the recipient to whitelist the email to facilitate delivery. Check the recipient’s address for typos. |
| 500. Syntax error. Command not recognized | This message indicates that a command you tried to send does not match the list of known SMTP or ESMTP requests. | If you use a firewall or antivirus software, you are more likely to have to deal with 500-type errors. Temporarily disabling security tools, running a command, and restarting the software once there’s a server response is a quick way to troubleshoot the issue. |
| 523. The total size of the sending exceeds limits | This error is the result of entering too many addresses in the CC/BCC field. | To avoid dealing with 523 error messages, break your mailing list down into smaller batches. |
These are the most common SMTP error messages email senders get. It’s worth noting that some email clients return SMTP reply codes more often than others — in particular, Yahoo Mail and Outlook users are known for getting a lot of these alerts.
7 tips to avoid SMTP Errors
Although there are dozens of errors senders have to recognize and deal with, a lot of these have common origins and point to recurring issues. Thus, there’s a set of best practices that will help teams to stop getting server alerts. Here are 7 easy-to-implement tips that will improve server communication and transmission efficiency.
1. Use anti-spam tools
Since a wide range of error messages are connected to firewalls blocking sender addresses, a smart way to troubleshoot these challenges is by making sure your IP is not used for spamming. Start running regular anti-spam checks by using tools like Mailwasher or Zerospam.
In this article, you can learn more about measuring your email deliverability and how email testing tools work.
2. Limit sending volumes
Most ISPs have a threshold to how many emails they let senders send per hour — once you cross it, SMTP errors will show up and message delivery will be compromised. Although it’s natural for marketers to set high sending volume KPIs, be sure to keep the number of emails you send at 50 per hour or lower.
3. Double-check sender-recipient data
The bulk of transmission errors appear because a recipient’s email is no longer valid. To make sure users don’t enter wrong emails when they sign up to the mailing list, add an email verification tool to the website — this helps point out website visitors who enter invalid emails on purpose or make accidental typos.
Other than that, double-check if the address in the “To” field matches the one in the subscriber base.
4. Change ports
As mentioned above, few spam-strict ISPs block all messages coming from the sending port 25 since too many spammers use it to share unwanted and irrelevant messages.
That’s why, if you struggle with sending issues, it’s better to change the default SMTP port to 587 (or 467 for senders connecting with the server via SSL).
5. Change the firewall and antivirus configurations on your PC
While security tools help senders protect their addresses from phishing and spam abuse, sometimes this software is too harsh on blocking outgoing messages.
If your email campaign struggles to go through, chances are your firewall or antivirus is in the way. To handle the issue, make an exception for the SMTP server in software settings.
6. Enable SURBL
SURBL (short for Spam URL Real-Time Block List) is a technology that detects and disables malicious links in messages. Right now, there are servers that don’t support SURBL — if yours does, enabling it is a good idea.
This is a simple yet effective way to protect the online reputation of a sender and eliminate phishing risks — thus, the odds of your address making it to blacklists are lower and there are fewer SMTP error messages to deal with.
7. Test emails before hitting “Send”
Last but not least, email marketing and tech teams will be able to catch potential errors by thoroughly testing campaigns (like welcome, product launch, newsletter emails) before sending them to a batch of real users. Here are a few criteria you should pay attention to when running tests:
- Spam triggers in the subject line, copy, or call to action.
- Malicious or broken links.
- Sending frequency and volume.
- Message size (failing to comply with set requirements leads to SMTP errors).
- Reliable infrastructure (RFC-compliant ports, no resistance to sending an email on behalf of the VPN, firewall, or antivirus software, etc).
Product managers or software engineers use specific tools to configure virtual SMTP authentication servers for email testing.
One such tool is Mailtrap. It captures your outgoing test emails, allowing you to test your email sending scripts and analyze any SMTP errors. In addition, Mailtrap helps assess emails for spam score and SMTP headers validity. It also analyzes your HTML email templates for support across popular email clients, and explains what should be improved in HTML/CSS code.
It’s a team-friendly platform that allows marketers, developers, and QAs to oversee and run tests collectively in real-time.
Take control over SMTP reply codes
If you feel confused by deciphering the meaning of SMTP reply codes, now that you know how to read them, reacting to alerts will be easier and more straightforward. While there are specific tips to troubleshoot each error message, by following basic email marketing practices, you will be able to drastically reduce the number of server alerts per campaign.
The key to a successful campaign is staying mindful of sender reputation, checking on the campaign’s compliance with the requirements set by ISPs (recipient pool size, message size, and others), and using a set of tools to provide the team with a reliable tech backbone for marketing efforts.