SMTP Error Codes

As your email goes from your mail client (Microsoft Outlook, Gmail, iOS Mail App) to the recipient, it passes through series of email servers. As a message goes from one server to the next, the receiving email server issues an SMTP code -- 3 digit responses from a mail server processing your message. While almost all of them will be in the 2xx range (200 or 2.0.0), when there are problems mail servers will provide a code and an explanation for why the message could not be accepted/delivered.

The easiest way to audit SMTP errors is to look at the first digit.

As you can tell from the table above, more problematic SMTP errors start with either 4.x.x or 5.x.x and the difference between the two is key: 4.x.x errors are temporary and the message still may be delivered whereas 5.x.x are permanent/fatal errors and the message has been returned to you.

4.x.x Errors

Tempfail, or temp errors, are generally issued by a mail server that is having technical issues or has technical reasons for delaying the message. The most frequent error we see at ExchangeDefender is “452 4.3.1 Insufficient system resources” which is issued by Microsoft Exchange mail servers when they run out of disk space or other resources. (if you get this make sure that the drive your mail store database is on has more than 10% free space, generally accomplished by clearing older logs).

This error is also used by mail server to slow down suspicious or fraudulent activity. When someone is running a massive SPAM campaign, we tend to issue 4.x.x errors to them forcing them to retry the message later.

5.x.x Errors

Permanent or fatal error is issued by the mail server when the message is not accepted by the recipients mail server due to a configuration or policy error. Unlike 4.x.x errors which make the sending server retry the message after a period of time, 5.x.x errors force the mail server to return the message to the sender immediately.

One of the biggest challenges in analyzing SMTP headers and error codes is identifying which server is reporting the error. If the error is encountered, the last server to successfully process your message will return the message along with the error that the target mail server issued. The name of the sending server is on the left, and the content of the error message is on the right, for example:

Each mail server has a different way of formatting, reporting, and indicating errors and at times it can be difficult to tell who is issuing the error and for what reason. If you ever need assistance please open up a ticket with the full SMTP rejection (entire message) and we’ll be happy to help.

The answer to that question depends on who is causing the issue.

If the issue is on the recipients mail server, contacting them via phone/social media or postmaster@ (if functional) is the best way to work through an email delivery issue.

In our experience, most of the rejections happen either by policy or by misconfiguration. For policy related issues (RBL, missing SPF, missing DKIM, misconfigured MX/etc) can only be addressed by the sender and sometimes even those changes will not result in immediate resolution as they tend to require propagation.

Most challenging issues are surrounding undocumented and unorthodox SPAM mitigation techniques, such as internal realtime blacklists and IP sender reputation scores. Because there are no standards governing these it is up to every mail administrator to devise policies to protect their clients from SPAM.