There are multiple situations where you might encounter different kind of SMTP codes. Understanding these will speed up your troubleshooting and will help you to identify the correct point of contact.
What is an SMTP code?
An SMTP code is a status assigned to a specific email during its transferal from one server to another during the SMTP dialogue. Correctly identifying the code will allow you to quickly understand the current status of an email, and it's transferal.
What type of SMTP codes will I encounter?
SMTP codes are divided into 4 different categories, identifiable by their lead number. Each category is dedicated to a specific email behavior during its transferal:
- 2xx codes - Positive Completion Reply
- 220: Service ready
- 250: Requested mail action ok, completed
- 251: User not local, will forward
- 252: Cannot verify the user, but it will try to deliver the message anyway
- 3xx codes: Positive Intermediate Reply
- 354 – Start mail input; end with <CRLF>.<CRLF>
- 4xx codes: Transient Negative Completion Reply
- 421: Service not available, closing transmission channel
- 450: Requested mail action not taken: mailbox unavailable
- 452: Requested action not taken: insufficient system storage
- 5xx codes: Permanent Negative Completion Reply
- 500: Syntax error, command unrecognized
- 503: Bad sequence of commands
- 522: Recipient has exceeded mailbox limit
- 541: No response from host
Extended SMTP codes (ESMTP)
Next to the SMTP code, we'll find the Extended SMTP codes, intended to clarify further.
They're organized in three blocks of numbers, separated by dots:
- 2.x.x: Positive Reply
- Success specifies that the DSN is reporting a positive delivery
action
- Success specifies that the DSN is reporting a positive delivery
- 4.x.x: Pending Reply
- A persistent transient failure is one in which the message as
sent is valid, but persistence of some temporary condition has
caused abandonment or delay of attempts to send the message. If this code accompanies a delivery failure report, sending in the future may be successful.
- A persistent transient failure is one in which the message as
- 5.x.x: Negative Reply
- A permanent failure is one which is not likely to be resolved by resending the message in the current form. Some change to the message or the destination must be made for successful
delivery.
- A permanent failure is one which is not likely to be resolved by resending the message in the current form. Some change to the message or the destination must be made for successful
Each category is then further divided into sections further specifying the exact behavior, leading to return codes such as 2.0.0 or 4.5.0. The sections will specify the exact behavior the email encountered while being transferred. There are many specific SMTP codes, but you will encounter some of the more prominent ones in your day-to-day work, which is what we will focus on here. You will find a full list of SMTP codes you might encounter from Hornetsecurity from within the Control Panel manual.
Where can I find SMTP codes?
There are two main places to encounter SMTP codes:
- Control Panel
- As an automated reply to an email I have sent (NDR)
Control Panel
You can find the SMTP code for each individual email from Email Live Tracking by opening the Action menu and navigating to Info > SMTP.
NDR (Non-Delivery Reports)
If an email couldn't be delivered the sender of the email might receive an NDR, informing them of the issue and letting them know that additional actions are necessary. Those automated emails are referred to as Non-Delivery Reports or NDR's for short. How the NDR's are build is up to the sending server, but all of them will contain the SMTP code as well as an error description. The error description again up to the admin of the sending server, therefore the responses are not standardized and might vary quite a bit. It is important however to be able to identify the SMTP code from the message as this will assist in further troubleshooting.
2.x.x Return Codes
As mentioned previously, all codes stored in this category report a positive reply from the receiving mail server. This means that the email was successfully transferred from one server to another. Most prominent here will be 2.0.0, which shows a successfully transferred email, no issues encountered.
Why I need them: Most likely scenario here is to locate a lost email. For example, if a user reports that an email they expect did not arrive. If this is the case, it is important for you to find out where the email got stuck exactly. To do so, you can trace the route of the email back, and check whether the email was delivered to the next mail server in the delivery chain.
Example: Your user reports that an email they were expecting did not arrive. Since you are filtering your emails via Hornetsecurity you know that the email would have needed to take at least three hobs, before arriving at the user's inbox:
- The sender's mail server
- Hornetsecurity's mail servers
- The recipient's mail server.
It will make most sense to check Hornetsecurity's Control Panel at this point, since you will be able to figure out if the email arrived at all, if it was quarantined and finally if the email was delivered to the recipient's mail server. If the e-mail was received by Hornetsecurity and you were able to confirm that the email was delivered to the recipient's server from the Control Panel, then you will be able to narrow your search to that mail server as well.
4.x.x Return Codes
Email shown up in this category are encountering a temporary failure. The emails are basically pending for delivery. The email server has not yet given up on delivering the emails and will continue to try to deliver until a) the delivery was successful or b) the server receive a final error. From within the Control Panel you will notice that each delivery attempt Hornetsecurity performs will receive its own line along with the SMTP code and explanation on why the email could not be delivered.
Why I need them: These codes represent a temporary issue, and the email will eventually turn into a 2.x.x category when delivered or a 5.x.x error when the delivery has failed for good. When identifying the issue causing the 4.x.x error, you might be able to solving the issue, thus preventing mail loss. This is also a very common reason for delayed emails.
Example: A user reports that an email was received with a delay of multiple hours. From the Control Panel you were able to figure out that there was an issue delivering the email to the recipient's mail server, saying that the server was unavailable before finally being able to deliver the email. Therefore, you were able to isolate the issue to the receiving server.
5.x.x Return Codes
SMTP codes starting with 5 will mark emails whose delivery has finally failed. Further delivery attempts will not take place, and the sender will need to re-send any messages. Emails failing with any 5.x.x error will usually generate NDR's informing the sender that there was an issue delivering the email.
Why I need them: This is mainly needed for a post error analysis, as there is a chance that the email will run into the same issue when trying to re-send straight away. A 5.x.x error usually comes with a specific error message, provided by the receiving server. You want to analyze that information and take further actions before re-sending that email again, otherwise it is very likely that you will run into the same issue again.
Example: A user is contacting you reporting that they received an NDR informing them that an email could not be delivered to a specific recipient. Before re-sending the email, you should check the exact error message received and double check whether instructions came with the error message. Hornetsecurity for example will block all incoming emails with a 5.5.4 error if the sending IP address is currently blocked, due to past incidence of sending spam. The NDR will not only contain that information, but also a link with further instructions on how to proceed before re-sending the message.
External references: