How Does Email Delivery Work?

Below is some information regarding how email is delivered and reasons it could be delayed.  This may help you better understand what happens when you press Send and why there can be delays in the delivery of email messages.

This is not intended to provide an all inclusive look at the details and terms regarding email delivery, but rather the basics as they apply to typical email deliveries.
There are two fundamental parts to an email message, the header and the body.
1. The header includes information relating to the delivery of the message, such as:
  • The address to reply to (Reply-To) (most often your own email address)
  • The Sender (your own email address)
  • Who it’s going to (To; CC; BCC)
  • The Subject
  • The Date
  • Any flags, priorities, confirmations, etc.
  • Sending server
  • Message-ID
The body includes the content of a message and any attachments, links and text. 
2. There are a few key elements necessary to facilitate the creation and delivery of email, they are:
  • A client used to compose an email message (the client could be on the web (Gmail, Hotmail, Yahoo!, etc), on a computer (Outlook, Thunderbird, etc.) or on a device (Andriod, i-Phone, Windows Mobile phone, etc.)). 
  • Sending email server (your work connection, Gmail, Hotmail, Yahoo!, etc.)
  • A network connection
  • Receiving email server
  • Receiving email client (work connection, Gmail, Hotmail, Yahoo!, etc.)
Ok, we now have the basics.  Now I will walk through the steps of email creation and delivery.  I will group the steps by "points of failure" to illustrate where delays and/or failures can happen.  So let's create and follow the life-cycle of an email message. 


First a message has to be created on a client, the client could be on the web (Gmail, Hotmail, Yahoo!, etc), on a computer (Outlook, Notes, Thunderbird, etc.) or on a device (Andriod, i-Phone, Windows Mobile phone, etc.).  Oftentimes, these email messages can be created without being actively connected to the sending server (your email server).  What this means is that you can create your message (let's say in Outlook) and when you click Send, it sits in your Outbox until your server (the sending server), becomes available again.  Your own sending server may not be immediately available due to a number of reasons such as:
  • a misconfiguration on your client
  • a problem with your network connection to the sending server
  • the sending server itself could be down
  • your connection may require you to make a manual connection to send the email (pressing Send/Receive)
It is important to understand that because you are able to compose a message and click Send, it does not mean that your sending server is available.  In any case, the inability to transfer the message from your client to your server represents the first potential point of failure.


So your message has made it to your sending server, that server will now look at your header information to find out to what server your message should be sent.  To do this it looks at the domain name of the email address you used, so let's say you were sending the message to a Hotmail address, your server is going to look for's email servers and their server addresses.  It does this by performing a lookup in a DNS database which simply identifies to an IP address.  If this DNS lookup fails because there is no internet connection, the DNS cache has not been updated, the DNS server information is misconfigured or down, the email can't be immediately delivered and remains in queue.  Your email server will hold your message in queue until it has been able to resolve the recipient server information, or it will return the message to you.  To summarize, the second potential point of failure is that the sending server is unable to complete the DNS resolution or the sending server does not have an active outbound network connection.


So now the sending server has a connection with the internet and the DNS resolved ok.  Now the sending server sends the header information to the receiving server's address and waits for a response from the receiving server.  If the receiving server is offline, the message can't be processed any further and either remains in queue on the sending server (for a period determined by the sending server) or it is returned to you with a message stating that it was unable to deliver the message.  In some cases, you will get an informational message back stating that message delivery has been delayed, but that your server will continue to retry the message for a period of time.  Here we have the third point of failure being that the receiving server is not available to receive the message.


Now we have a receiving server which is online and ready to receive your message.  Your server re-tries sending the message header (only the header at this point, not the body of the message); the receiving server now reviews the header information to determine whether or not it will accept the rest of the message.  This determination is made based on details like, does the name of the recipient exist on the receiving server, the name and reputation of your sending server (for example, is your sending domain on a white list, local black list, or is it known to send out spam (typically identified with a DNSBL (DNS Blacklist))).  These basic checks represent the fourth potential point of failure because failure to be accepted by the receiving server results in your message being returned to you by your sending server with a message detailing (often in an unclear way) why the message was not accepted by the receiving server.


The receiving server has reviewed your header and decided to accept your message and the sending server has delivered it. The sending server is now done with the process and takes no other action as a sending server.  The receiving server now looks over the content of your message to look for keywords which are often related to spam, or are not allowed because of rules.  It also reviews the links in your message to see if they are related to a site which is known for undesirable activity.  It may also look at your attachments to see if they exceed an acceptable size, if they are disallowed for security reasons or if they contain a virus.  The receiving server now makes some decisions; A number of things can happen here.  The message could be:
  • placed in a quarantine for review by a human
  • delivered to the recipient with content or attachments stripped out
  • delivered to the recipients junk email folder
  • marked as a junk or marketing message and delivered
  • delivered to an alternate recipient for review
  • put in a hold queue for future delivery
  • returned to the sender with notification of delivery failure and cause
  • delivered to the recipient unaltered
This verification process is the final step before your message is accepted or rejected.  Passing this fifth potential point of failure is the last step before delivery to the end client.


The last point of failure is the recipients client.  This client must have access to the server, it must make a request to receive the message (in some cases) and it must be configured properly.  Presuming that all these items are in check, the recipient will receive your email message.
While this whole process from send to receive often takes just a couple seconds, the reality is that there are multiple places in the delivery process which can cause delays (in some cases of up to 24 hours or more) for a message to reach its destination.  Email is very reliable, but with anything which may be time sensitive, a follow up is always a best practice.