How long should email take to be delivered?

Computers are fast, and the internet is fast, so it's no real surprise that most of the time email is fast. It's not uncommon for email to be delivered and ready for a recipient to read or download in mere seconds of the sender having hit "Send".

A few minutes is probably much more common.

A few hours is quite possible.

A few days is also possible, and in fact, from the mail transport point of view, quite acceptable behavior.

So there you go: your email could take seconds or it could take days to get from you to your recipient, or something in between. Fortunately, most of the time delivery is much closer to seconds than it is to days, and as a result we're typically fairly happy with the rate at which email gets from point A to point B.

So, what might tip the scales? What might cause an email to take hours or days to reach a recipient?

• SPAM (#1): there are spam prevention mechanisms in place that will cause email delays. For example, the first time someone emails me directly my mail server says, in effect, "I'm too busy for you now, come back later". Many spambots will not. Legitimate mailers will wait "a while" and try again, at which point the email is accepted. The "a while" varies quite a bit based on the sending server; I've seen it be a few minutes, and I've seen it be a few hours. (This technique, which is implemented on mail servers, is called "greylisting" for those interested.)

• SPAM (#2): I've seen mail servers brought to their knees by a sudden incoming flood of spam. The server itself simply can't keep up, and legitimate email being sent to or through it can be delayed. As we know, the spam problem is huge, and I have to believe that this is a fairly common occurrence - I see it often with the big services and with mailing list providers. Fortunately, the email protocols allow for delays and retries and the like, so email typically makes it through eventually, but with an added delay.

• Failures: Machines fail. Networks fail. Then they get repaired. As I mentioned in the previous point, the mail protocol is extremely robust and tolerant of failure. Mail servers are designed to, if at all possible, note that an error is "temporary", and as a result will keep trying for "a while" in case the error gets resolved. In this case "a while" is typically something like 5 days. You may occasionally have seen a bounce message that says "I've tried for 5 days and couldn't get through, I'm giving up."

• Load: Somewhat like SPAM #2 above, sometimes mail servers are simply overloaded with legitimate email as well. This happens from time to time particularly with mailing list services.

• User error or behavior: I have to include this for completeness. Occasionally, we might compose a message offline and then not connect for a day or two, at which point it gets sent. That looks like a delay. Similarly if someone only checks their mail every three days, then you might see what looks like a three day delay.

So there's lots of reasons that mail might be delayed. The good news is that if it can be delivered it typically will, eventually. The even better news is that "most of the time" it's pretty quick.

You just might not be able to count on it.

As to your other, more technical questions:the mailer-daemon (mail server software) is typically processing mail extremely quickly, so decisions on the validity of email, the state of a mailbox or what have you - anything that can simply be determined by it looking - is extremely fast. Probably measured in milliseconds internally, but would appear as seconds to the naked eye.

How long a mail host will keep trying to deliver an otherwise legitimate email depends on the specific problem that's preventing delivery, and in all honesty, the decisions made by the author of the server software and the administrator of the service. Typically, failure will either be immediate, or if retrying is called for, then it will try for several days.

Sadly, and again due to spam, failure - be it immediate or after several days - may, or may not, generate a bounce or error message in return. In other words, it's frequently the case that errors happen and you'll never know.