Three places where your email could get delayed when sending through SES

Email sending is one of those activities you may not pay much attention to when all goes well, but you really notice when it’s not working. In today’s fast moving world, the speed of information transfer is critical, so slow email delivery is a particularly painful problem. In this blog post, we will explore three places where your emails could be delayed before your recipients get a chance to read them.

The typical path of an email message delivered via Amazon SES is pretty simple: your application generates the email and then passes it to SES in one way or another. After a brief period spent inside the SES pipeline, SES attempts to contact the receiving ISP and deliver the message. The ISP, after successfully enqueuing the message, displays it to the intended recipient. Let’s see now what could go wrong at each of these steps, and how we can identify the source of the problem.

Scenario 1: Emails are delayed before arriving at SES

The first step in the process is for your application to contact SES to pass it the message. This is one place where problems could occur.

Remember that for each message it successfully enqueues, SES returns a message ID that you can log on your side. To verify that your calls are actually successful, you can track these message IDs. If SES never accepted your message, you can be sure it won’t be delivered! If you are able to log a message ID, it means that your email safely arrived in SES. You can then match the timestamp of when the message ID was logged with the timestamp of when the call was made inside your application. If the difference is too big, it means something happened between the moment your application wanted to send the email and until SES acknowledged its receipt.

Typical problems we’ve seen include custom software (such as Postfix) sitting between the customer’s application and SES, which were buffering or otherwise delaying messages. If you have such a setup, make sure you examine the logs of the software you’re using for evidence of any delays there.

In order to test that the problem lies between your application and SES, and not inside SES or between SES and the ISP, you can try to send a test email from the Amazon SES console to that specific ISP. If that test email arrives on time, it’s a pretty good indicator that the delay is occurring before your email even reaches SES.

Scenario 2: Emails are delayed inside SES

Once SES accepts the message, it will process it as quickly as possible, before handing it over to the ISP. We take latency very seriously, and, in the event of significant service delays, we will update the public status dashboard.

Soft bounces and Amazon SES

SES service delays are, however, not the only reason why emails might not be delivered to the receiving end. For various reasons, the ISP might be temporarily refusing your email. This is referred to as a soft bounce. Typical reasons why ISPs might soft bounce your email are if the destination address has a full inbox, the email is of a larger size than they support, or they have a service issue and cannot accept email. ISPs can also soft bounce emails as a form of throttling – if they see too many emails delivered too quickly they sometimes interpret that as a spammer trying to attack their customers.

When a soft bounce event happens, SES continuously retries to deliver your email for 14 hours before giving up. There is no limit of retries during this 12-hour interval, and, as long as the ISP recovers, your email will be delivered.

To verify whether soft bouncing is the issue, you can try sending to different ISPs. If you only see delays with one of them, that’s a pretty good indicator that that particular ISP has a problem receiving your email.

Scenario 3: Emails are delayed after leaving SES

One particularly thorny problem we sometimes encounter is when we successfully deliver the email to an ISP quickly and in the first attempt, only to have it take a very long time to appear in the recipient’s inbox. This can happen for a variety of reasons, for example the ISP is encountering a technical problem, or it is delaying making the email available to its users because it does not yet trust it.

To narrow down the problem, try sending to a different ISP (or to a different address in the same ISP), using an email with different content, different (or lack of) attachments, different “From” address, etc. and see if that makes a difference. Remember that as long as you haven’t received a bounce notification from Amazon SES, it means your message is either somewhere in the SES pipeline, with its delivery being continuously retried, or it has already been enqueued by the ISP, and it being processed on their end.

We hope this entry sheds a bit more light over email latencies and SES and will help you identify the source of the problem. Feel free to post any comments or questions for us in the AWS Forum.