It’s usually quick, right?
We’re all so used to email being almost instantaneous that we notice delays.
Delays can happen for many reasons, and counting on email to be nearly instant turns out to be a bad idea. You can’t always rely on the timestamp to be accurate, either.
Let’s look at exactly why an email takes a little longer than expected.
Become a Patron of Ask Leo! and go ad-free!
Why does email take so long?
Email was never designed to be instant, and was built with tolerance for lengthy delays. The email infrastructure has improved to the point that it’s almost always very fast, but delays can still happen. Delays are most commonly caused by Server issues and floods of spam.
Server to server
While it seems email goes directly from your outbox to your recipient’s inbox, in reality, it travels across multiple servers. The sender’s email server, and yours, of course; but it’s possible that several intermediate servers may also be involved, each one receiving and then passing the email on to the next server along the route.
Surprisingly, there’s no requirement that those servers operate quickly, or in any timely fashion. In fact, if they’re overloaded with mail, spam, or other tasks, they could take a while, and that’s quite OK according to email protocols.
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 often, that’s due to a flood of spam. Naturally, there are other potential causes for delays, including how often you check your mail.1 Delays may be minutes, hours, or, in worst-case scenarios, even days.
And all those delays are OK, at least as far as the servers are concerned.
Delays versus bounces
A full mailbox is typically not a reason for a delay.
If your mailbox is full, most email services return a message to the sender — called a “bounce” — indicating your message could not be delivered. On rare occasions, it might 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 making things very confusing 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 their date and time set wrong, that wrong date and time shows up on the email they send.
If you’ve ever seen email (particularly spam) “from the future”, that’s probably what’s happened. The clock on the computer sending the email was set incorrectly.
If you examine the mail headers of a message,2 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 ([220.127.116.11]: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 [18.104.22.168]) 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 internet, and was designed at a time when computers were not always connected.
As a result, email services, servers, and protocols all have a high degree of resiliency built in. Depending on the type of failure a mail server encounters when attempting to deliver an 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 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. Check the recipient’s spam folder. If you don’t find it, then consider sending it again, using a different provider or a more immediate tool for the job, like instant messaging.
Subscribe to Confident Computing! Less frustration and more confidence, solutions, answers, and tips in your inbox every week.
I'll see you there!
Footnotes & References
1: It’s less common than it once was, but the act of checking for email frequently could impact the server, preventing it from actually processing email.
2: Unfortunately, exactly how you do this varies based on what email program or interface you’re using. When displaying a single message, look for options referencing headers, message source, or original.