We’re all so used to email being almost instantaneous that delays are noticeable.
Email delivery can be delayed for many reasons, and counting on it to be nearly instant is just a bad idea.
Couple that with the fact that the timestamps on email often lie, and it can be really difficult to understand exactly what happens when email takes a little longer than expected.
Server to server
Email may travel across multiple servers. The sender’s email server, and yours, of course; but it’s also possible that several intermediate servers may also be involved, each one receiving and then passing the email on to the next along the route.
Surprisingly, there’s no requirement those servers operate quickly, or in any timely fashion. In fact, if they’re overloaded with mail, spam, or other tasks, they could simply be slow – and technically, that’s quite ok.
In fact, I would guess that in most cases, delayed email is due to one of the mail servers along the way being overloaded and running slowly – most frequently due to a flood of spam. Naturally, there are other potential causes for delays, including how often you check your mail1. Delays may be minutes, hours, or, in worst-case scenarios, even days.
Delays versus bounces
A full mailbox is typically not a reason for a delay.
If your mailbox is full, most email services return the message to the sender – called a “bounce” – indicating it could not be delivered. On rare occasions, it might also simply be discarded.
On getting the bounce notification, the sender could try again, and if you’d made room in your mailbox since the first attempt, the mail might be delivered as expected. Depending on how long all that took, it could look like a delay, but it definitely wasn’t automatic. The sender had to take steps to re-send the mail.
One thing that can make things very confusing to you as the recipient of email is that the date and time displayed on the email are usually the date and time the email was sent, as displayed from the sender’s computer. If they have that date and time wrong, it’s still that date and time that shows up on the email they send.
If you’ve ever seem email (particularly spam) “from the future”, that’s probably what’s happened. The clock on the computer sending the email is set wrong, either accidentally or on purpose.
If you examine the mail headers of a message2, you can see the date and time that each mail server along the way acted on the message. The header will have a series of lines that look similar to this:
Received: from cuda03.sourcedns.com ([188.8.131.52]:56405 helo=barracuda.sourcedns.com) by lw6.pugetsoundsoftware.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) ...; Thu, 16 Mar 2017 08:16:22 -0700 Received: from smtp-coi-g10-027.aweber.com (bmx02.sourcedns.com [184.108.40.206]) by barracuda.sourcedns.com with ESMTP id 8njXs1vAjrlP3xsh (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) ...>; Thu, 16 Mar 2017 08:15:11 -0700 (PDT)
Starting at the bottom and working upwards, you can see the email message make its way from my email service provider (aweber.com) to a spam-filtering service, and then on to my server (lw6.pugetsoundsoftware.com). Each “hop”, as they’re called, includes the timestamp the message was received, which I’ve highlighted in bold above. Note that each timestamp is in 24-hour notation, and also includes its time zone designation. In that last entry, for example, “08:15:11 -0700” indicates 8:15 am in the time zone 7 hours behind UTC (Universal Time Coordinated, or less correctly, GMT, Greenwich Mean Time).
In theory, once you account for time zones, you can relatively accurately trace how long the mail spent on each server along the way, and thus identify any potential bottlenecks. In the example above, the message spent over a full minute on the spam filtering service’s server before being passed to my server.
However, this has one interesting flaw: it still assumes everyone’s clock is set correctly – including all the mail servers. In most cases, they are fairly accurate, at least to within a few seconds, but it’s definitely not foolproof.
Resiliency versus speed
Email is one of the oldest services on the modern internet, and was designed at a time when computers were not continuously connected.
The result is that email services, servers, and protocols all have a high degree of resiliency built into them. Depending on the type of failure a mail server encounters when attempting to deliver email, it may elect to reject and return a bounce message, or it may decide to hold on to the message and try again later. In the latter case, it can keep trying for multiple days before finally giving up.
If something you’ve sent, or are expecting, hasn’t arrived in what you’d consider a reasonable amount of time, check to make sure the message was sent properly. Then consider sending it again, sending it again using a different provider, or using a different, more immediate tool for the job, like instant messaging.