SMTP Monitoring: What is a Failed Message & How to Monitor Email Delivery Errors
Today we’re going to talk about SMTP Monitoring — specifically monitoring your message failures.
And this is important:
SMTP is the standard for sending email and it’s one of the most effective ways to send transactional email like password resets, shipping notifications, etc.
But just using SMTP isn’t enough. There’s a lot that can go wrong in the process of transmitting email.
When it comes to SMTP monitoring, you need to keep an eye on a wide range of things ranging from DNS changes to application availability. For the purpose of this article, we’re going to focus solely on message failures.
Well, there are a lot of reasons why an SMTP transmission can fail.
And better yet, each failure is a learning opportunity that can help you correct any issues — so you can ultimately improve your deliverability.
Ready? Let’s get started.
What Is a Failed Message? (Synchronous Vs Asynchronous Failures)
A failed message simply means that the message did not reach the intended recipient.
There are two types of email delivery failures that you may encounter when sending outbound email. They are synchronous and asynchronous failures.
Synchronous failures happen when the remote mail server rejects the message. This happens during the initial conversation between the SMTP server and the receiving mail server.
An asynchronous failure occurs when the remote mail server accepts the message and then later returns it by sending an NDR (Non Delivery Report) to the return path of the message. Since the receiving mail server initially accepted the message, it’s easy to believe that the message was successfully delivered. It is not until we later receive a failure notification from the remote server that we know that the outbound message has failed. This is known as an email bounce, which can be either hard or soft.
Many people make the mistake of assuming that all failures are bounces. Technically speaking, synchronous failures are not bounces.
Now let’s dive deeper into SMTP failures by taking a look at three common delivery error messages and what they are telling you about a failed SMTP transmission.
3 Delivery Error Messages and What They Mean:
When it comes to SMTP monitoring and delivery errors, it can be hard to identify the meaning of each delivery error. This is because there are a lot of them. And to make things more challenging, each email service provider maintains their own set of error codes, many of which require additional research to understand their meaning — here’s a list of 21 Common SMTP Error Codes.
With that said, we’ll define three common delivery error messages that you may encounter as a result of a message failure.
A permanent error, or permanent failure is exactly how it sounds — the message was returned by the recipient mail server and no further attempt will be made to deliver the message.
The most common reason for a permanent error is because the domain does not exist, or because the recipient is unknown. This is referred to as a hard bounce.
Below are some standard error messages that indicate that a domain or account does not exist:
- 554 delivery error: This user doesn’t have an account
- 550 5.1.1 Mailbox
does not exist
- 500 No such user
- 553 5.3.0
… Addressee unknown
- 550 Requested action not taken: mailbox unavailable
- Name service error for baddomain.com Type=A: Host not found (This error means that the DNS server returned an error specifically saying that the domain does not exist).
A temporary delivery error means that the message was not accepted by the receiving mailbox, but the message will remain in queue to be retried at a later time.
There are many reasons why an SMTP transmission could fail due to a temporary error.
As we already discussed, one reason for a temporary error is because the recipient’s mailbox is full, which will produce a soft bounce.
In addition, a temporary delivery error could also occur if the MTA is unable to connect to the MX records for the receiving domain. In this situation, you’ll see an error that looks like this:
Could not connect after trying all mx records. type=mx
Another common reason why your messages may fail could be due to a Greylisting.
What is greylisting?
Greylisting is a temporary rejection of a message that forces the sender to attempt to send the message again in the near future. This prevents bots and spammers from flooding an inbox with unwanted mail because legitimate senders will attempt to resend the message, while spammers and bots will not make a second attempt. For this reason, a greylisting most commonly occurs on new IP addresses, mail systems that send low volume, and for senders that have a low sender reputation.
How to Monitor Failures?
How do you know when messages are failing?
Well, monitoring and reporting upon message failures is a complex task, especially for asynchronous failures. This is because the SMTP protocol requires asynchronous failures to be sent to the return path of the message as an NDR (Non Delivery Report), rather than the original sending server. After this happens, a complex process needs to run to gather, parse, and analyze NDRs.
If you’re sending transactional email from a custom built or open source SMTP server, then you would need to build a very complicated system to capture and process failures. However, many email services like SocketLabs will automatically do this for you.
One of the major benefits of using an SMTP Relay Service like Socketlabs is that we provide a central location where you can quickly see the status of your messages, including those that failed delivery.
You can then dig deeper into a Failed Message Report to see exactly why specific messages failed along with a “reason” for the failure.
How to Monitor Failures to Improve Deliverability?
The problem with failures, especially an asynchronous hard bounce email, is that constant and repeated attempts to deliver hard bounces will damage your sender reputation, which will negatively impact your ability to reach the inbox.
For this reason, you’ll want to quickly identify and isolate hard failures from your list, so you don’t continue to send to them in the future.
An SMTP relay service like SocketLabs will give you the ability to get failure messages and pull out the hard failures. Next, the hard failure addresses are automatically added to a Suppression List, which blocks further messages from being sent to these addresses. Stopping further failed message attempts will improve your reputation as a sender.
Additional Things to Consider When Monitoring SMTP Performance & Deliverability
In this article, we only discussed message failures — just one element of SMTP monitoring and deliverability.
Here are some additional things to consider when monitoring your SMTP performance:
- Complaints: Many email services provide feedback loops that report back if someone marked your message as spam. You’ll want to remove spam complaints from your system, so you don’t continue to contact these people in the future.
- Review & Monitor DNS: Regularly review and monitor DNS records. It’s possible that even a correct DNS configuration can get screwed up. A mistake with SPF, DKIM, or a DMARC configuration in your DNS could cause emails to fail to be delivered.
- Monitor IP Address Blacklists: If your sending IP address ends up on a reputable blacklist, then this could cause delivery issues. You can monitor your IP Address using tools like Gmail Postmaster Tools and MX ToolBox Blacklist Monitoring.
- Application Availability/Network Outages: Network outages and application failures could cause synchronous failures — which will impact the deliverability of your mail. For this reason, you should use an SMTP service that has redundant, geographically separate data centers so you can continue to send email, if you experience a network outage.
- Monitor Your Systems: Traditional server monitoring only verifies that the servers are listening. But just because a server is listening, does not mean that it is doing its job properly. At SocketLabs, we developed a 360 Degree Email Monitoring System that works by emulating a user outside of our network who is sending outbound email through our systems. Each message the monitor sends is tracked throughout our entire infrastructure until it is delivered to the inbox. The monitoring system tells us exactly how long it takes to deliver each message, and if it detects any issues, it sounds alarms that point us to the piece of infrastructure that needs attention, so we can remedy the problem right away.
We’ll cover the above points in more depth in the future. When thinking about SMTP monitoring, there’s not one single thing to focus on. Email deliverability is both an art and a science. That’s why you should take a holistic approach and focus on every factor that could impact your deliverability.