Helping people with computers... one answer at a time.

The email system is built to tolerate delivery delays of several days. That shouldn't happen often these days, so I'll look at what you can find out.

Why does some of my email arrive late? For example, on Saturday afternoon I received about 10 emails, some spam, others legitimate, but dated Thursday. I have my own website hosted by 1&1 UK and this includes my email account. Single emails, for example if I send my send myself a test email, arrive immediately. It seems that bulk mailings are being held up. For example, your own newsletter, currency updates, PayPal notifications. A friend with a Telefonica (Spain) email account has had the same problem, but his mail is sometimes up to a week late. What's happening?

It's hard to know for sure exactly what's happening, as there are many possible causes.

I'll review some of those causes, and then also show you how to examine your email headers to perhaps determine where the problem might be happening so you or your email provider can investigate further.

Email Was Never Meant To Be Instant

One thing that's important to realize is that email was never meant to be a means of communicating instantly. While most email is delivered within minutes or even seconds, the entire email system is built on the assumption that something could go wrong.

As a result the email system has built into it tolerances for delays of up to several days ... exactly what you're seeing.

"Short of changing to a different email provider there's little you can do to actually 'solve' any of these."

The trick is understanding where those delays are coming from.

Possible Delays

The causes of delays can be many.

  • Sometimes people forget to hit "Send". (It happens.)

  • Email servers along the way can be misconfigured. (This happens more than it should.)

  • Email servers along the way can be overloaded. (Usually with spam)

  • Email servers along the way can be down completely.

  • Various networking issues can cause an email server to appear down, with the same result.

  • Certain spam-fighting techniques can intentionally introduce delays (that cause many spam bots to fail).

  • There's probably more...

All of these are outside of your control, of course. Short of changing to a different email provider there's little you can do to actually "solve" any of these.

As email travels from one server to the next if "the next" is unable to receive sending server will keep trying periodically ... for days if necessary.

The reason email to yourself appears to go so quickly is that it avoids 90% of the problems listed above: you send to the same server you receive on, hence there's no opportunity for all these inter-server problems to arise.

Email Headers and Time

As I've alluded to, email may be passed through several servers on its way to you. The good news is that each server is supposed to add information to the headers you don't normally see in your email, providing a trace of the path that the email took to reach you.

Including timestamps.

Here are the relevant portions of the email header of message set from my Hotmail account to my regular email account:

Received: by with SMTP id n8cs463327faj;
  Sun, 2 Jan 2011 12:37:52 -0800 (PST)
Received: by with SMTP id br1mr4793172icb.457.1294000671056;
  Sun, 02 Jan 2011 12:37:51 -0800 (PST)
Received: from ( [])
  by with ESMTPS id i1si48453061icb.28.2011.
  Sun, 02 Jan 2011 12:37:51 -0800 (PST)
Received: from ([]:59131)
  by with esmtp (Exim 4.69)
  for; Sun, 02 Jan 2011 12:37:50 -0800
Received: from SNT116-W4 ([]) by
  Sun, 2 Jan 2011 12:37:47 -0800
From: Leo Notenboom <*******>
To: <>

Email headers are read from the bottom up. (And I've replaced my email address with "bogus" to avoid spam harvesters.)

Each "Received:" line is added by a mail server along the path that this email took. Let's walk that path, bottom up, in chronological order:

Received: from SNT116-W4 ([]) by
  Sun, 2 Jan 2011 12:37:47 -0800

The server listed as "by" - - is the first Hotmail server that the message is sent to when I hit send after composing the message. The time it received it is Sun, 2 Jan 2011 12:37:47, and the time zone the server resides in is "-0800" - US Pacific Time.

Time zones become important since email can, of course, traverse servers all over the planet. So when tracing it's best to convert the times to UTC (Universal Time, Coordinated - often referred to as GMT or Greenwich Mean Time though technically they're different) by adding the negative offset - meaning in this case we would add 8 hours to 12:37:47 to get a UTC of 20:37:47.

Received: from ([]:59131)
  by with esmtp (Exim 4.69)
  for; Sun, 02 Jan 2011 12:37:50 -0800

This is one of my mail servers receiving the message from Hotmail. The format it logs is slightly different, but the information is the same. Converting the time zone, this server received the email message at 20:37:50 UTC, or about 3 seconds after the first Hotmail server got it.

Received: by with SMTP id br1mr4793172icb.457.1294000671056;
  Sun, 02 Jan 2011 12:37:51 -0800 (PST)

While there's no name associated with that IP address, that's one of Google's mail servers receiving the email from my server - I route my email through Google for spam filtering. Once again converting the time to UTC, this was received at 20:37:51 UTC, or one second after my mail server received it.

Received: by with SMTP id n8cs463327faj;
  Sun, 2 Jan 2011 12:37:52 -0800 (PST)

This is another Google mail server, and illustrates that even within an organization mail can travel from server to server. This was received at 20:37:52, or one second after the first Google mail server got it.

That's where the mail sat until I downloaded it. Total time from pressing send: 5 seconds.

The biggest delay was the 5 minutes it sat on Google's mail server waiting for me to hit "download" in my email program.

Where's the Delay?

The example above has no significant delays. 5 seconds is pretty darned good.

Let's make up an example:

Received: from mailserver1
  by mailserver2
  Sun, 02 Jan 2011 12:34:43 -0800
Received: from somewhere
  by mailserver1
  Sun, 02 Jan 2011 13:34:22 -0500

Remember to read from the bottom up to see the progression of mail servers in the order that they were visited.

Remember also to apply the time zones - this email looks like it was received before it was sent, (sent 13:34:22, received 12:34:43?) until you apply the time zone offsets to turn everything into UTC. Then you can see that the message arrived on mailserver1 at 18:34:22 UTC, and then arrived at mailserver2 at 20:34:43 UTC.

In other words it took two hours to get from mailserver1 to mailserver2.

We don't know what the problem is. All this tells is where the delay occurred - somewhere between mailserver1 and mailserver2.

It could be a processing delay on mailserver1. It could be a reception problem at mailserver2. It could be anti-spam tools on mailserver2. It could be a networking problem connecting the two.

It could be many, many things.

There's simply no way to know what, but we do know now that the problem somehow involved mailserver1, mailserver2 and getting mail between the two.

And that's the best you can do. Maybe with enough examples you'll see a pattern, but in general the solution is still out of your hands.

But perhaps by providing this information to your email service provider you'll be able to help them to some kind of resolution.

Article C4699 - January 2, 2011 « »

Share this article with your friends:

Share this article on Facebook Tweet this article Email a link to this article
Leo Leo A. Notenboom has been playing with computers since he was required to take a programming class in 1976. An 18 year career as a programmer at Microsoft soon followed. After "retiring" in 2001, Leo started Ask Leo! in 2003 as a place for answers to common computer and technical questions. More about Leo.

Not what you needed?

January 4, 2011 8:26 AM

One of the most cogent explanations for reading headers that I have seen. Good work Leo!

Doug Shilson
January 4, 2011 9:01 AM

Hello, I have over 1000 emails saved, is that too much for my PC and does it slow my PC down at all? Hate to lose most of them! Please let me know. I injoy your articles. Thanks, Dug!

Saved email in and of itself won't slow your computer down. Make sure you're backed up - what happens if your hard disk dies? All that saved email is gone.

January 4, 2011 4:25 PM

Thank you. This explains much. I realize that email was never meant to be "instant", but I always thought of it as fast, meaning within an hour or two (as opposed to snail mail). I, too, have experienced delays of even a few days before receiving an email. (I know because the sender has called me a couple days earlier to find out why I hadn't responded.) Fortunately, for me anyway, such occurrences are sporadic, last only a day or two, and quite rare. Bottom line is, it's good to know that it's nothing that the sender did wrong or I did wrong (or necessarily our ISP's), and most of the time, it's beyond control of either end.

Sandy Smith
January 4, 2011 7:37 PM

(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256

I have found reading headers very difficult. Does the above mean it was sent with TLS/SSL and at some point the server that it passed through did not have the capability and it failed?

Comments on this entry are closed.

If you have a question, start by using the search box up at the top of the page - there's a very good chance that your question has already been answered on Ask Leo!.

If you don't find your answer, head out to to ask your question.