One of the most frequent questions we get through YippieMove relates to email routing. We touched briefly on this topic in the article Email 101 – An introduction to email under the hood. Yet, I feel the need to elaborate on this a bit more. In this article we'll put IMAP and POP3 aside, as those are protocols for retrieving email, and has nothing to do with the routing of your email (which is a common misconception).

There is only one thing that affects the routing of your email, and that is the MX-record. Each domain (and sub-domain) need to have an MX-record in order to receive email. For instance example.com and foo.example.com can have two different MX-records. An MX-record is simply a DNS-entry that tells the sending server (SMTP-server) where to deliver the email. A typical MX-record would look something like this:

example.com. 3600 IN MX 0 mail.example.com.

This means that all emails for example.com (i.e. [email protected]) should be delivered to 'mail.example.com'. This requires that 'mail.example.com' exists (either as a CNAME or a A-record). Please note that 'mail.example.com' may or may not be your IMAP/POP3 server too. However, that just means that your SMTP-server resides on the same host as your IMAP/POP3 server. For hosted environments, this is usually not the case, but fairly common if you're running your own server.
There are two numeric values in the above record too. The first one is 3600, which is the TTL (Time to Live). This record tells other DNS-servers (and clients) that it is OK to cache the above record for up to 3600 seconds (or one hour). The second numerical value is '0' and is the MX-record priority. In this example, it doesn't matter, as we only have one record, but if we were to have multiple records, it would determine the priority order of the servers. If the first one fails, the second one will be used, and so on.
Now let's move on to a bit more complicated setup. Let's use Google Apps as the example for this. Here's a typical setup for Google Apps:

example.com. 14400 IN MX 20 ALT1.ASPMX.L.GOOGLE.COM.
example.com. 14400 IN MX 30 ASPMX4.GOOGLEMAIL.COM.
example.com. 14400 IN MX 30 ASPMX5.GOOGLEMAIL.COM.
example.com. 14400 IN MX 30 ASPMX2.GOOGLEMAIL.COM.
example.com. 14400 IN MX 30 ASPMX3.GOOGLEMAIL.COM.
example.com. 14400 IN MX 20 ALT2.ASPMX.L.GOOGLE.COM.
example.com. 14400 IN MX 10 ASPMX.L.GOOGLE.COM.

As you can see, there are multiple servers listed for the same domain (example.com). They all have the same TTL, namely 14400 (four hours). The interesting part here is the priority order. The sending server would try to deliver emails to the servers in the order from lowest priority value to highest until it finds one server who accepts the connection:

  1. ASPMX.L.GOOGLE.COM

  2. ALT2.ASPMX.L.GOOGLE.COM

  3. ALT1.ASPMX.L.GOOGLE.COM

  4. ASPMX4.GOOGLEMAIL.COM

  5. ASPMX5.GOOGLEMAIL.COM

  6. ASPMX2.GOOGLEMAIL.COM

  7. ASPMX3.GOOGLEMAIL.COM


When working with DNS-configurations, there is a very handy command-line tool called 'dig' that is frequently used. To retrieve the MX-records for the domain example.com, you would simply run:

$ dig example.com mx

If you're not comfortable working with the command line, you can perform the same task by using a web-based tool, such as MX Toolbox.
I hope this article helped you get a better understanding on how email routing works. If you have any questions, please leave a comment below. Also, don't forget to visit YippieMove when you migrate email between systems.
Want to learn more about email and email systems? Learn more in The Email School.