In this tutorial, we will cover the basics of the internet mail system and go on to cover MX records in more detail.
The MX in MX records stands for Mail eXchange and describes what machines/computers/servers are responsible for receiving emails for a domain. It also sets the priority for a domain that has multiple mail servers.
A mail server is any system running an SMTP service that listens publicly on port 25 for incoming messages. The core of the mail system is extremely simple hence the S in SMTP. Simple Mail Transport Protocol. When you send an email to email@example.com a DNS lookup is performed on domain.com to get a list of MX records. The DNS server will return a list something like this:
The sender's mail server will then pick the MX records with the highest priority and do a DNS lookup on that hostname in this case mail1.domain.com. The DNS server will return the IP address of that hostname 10.20.10.20 for example. The sender's mail server will connect to that IP address on port 25 and attempt to send the email. If the connection fails it will repeat the process but use the next priority down in our example this would be mail2.domain.com. If it fails at this it would queue the email and retry later. The lower the number the higher the priority. So in this case 10 is a higher priority than 20.
This is the basics of the SMTP mail system. However, there are some things you need to know about when configuring your mail servers and MX records.
Let’s get a little more complicated
When you connect to a mail server to retrieve email using IMAP4, POP3 or webmail you may not be connecting to the same server as the one that is configured to receive the email. For instance, you may connect to imap.domain.com to download your email, and the mx record may point to smtp.domain.com. There may be multiple mail servers with the same priority. There may even be multiple mail servers with hostnames on multiple domains. Here is a more complex example.
In this case, there are 2 servers with a priority of 10 and 2 servers with a priority of 20. The 2 servers with a priority of 10 will be tried in a round robin fashion balancing the load between the two servers. If those two servers are unreachable then the 2 servers with a priority of 20 will be tried in a round robin fashion to balance the load. This is load balancing with resilience. To make it clear how this would be useful let’s use some IP’s.
The servers on the 10.20.20.x network are located in a Washington data center and they are on the same network and may even be on top of each other in the data centers rack. One server on its own is not powerful enough to handle the load so 2 servers are given the same priority to balance the load. However, if this data center has a catastrophic failure or the network fails then the backup server with a priority of 20 will take over. These are located in the Dallas data center.
Backup MX Servers
In our previous example, we showed a redundant and resilient network of servers. However what wasn’t explained is that the smtp3 and smtp4 servers are not full mail servers. They are back up MX servers only. They can receive emails for a domain but they won’t deliver them. They will hold on to them until the primary network is restored. This ensures that no emails are lost during outages and that heavy strain is not put on the primary servers when they come back up. There are implications if you do this however as some spammers target back up MX servers and you won’t have your full suite of anti-spam resources available on the backup server unless you specifically configure this.
Hosting email outside your domain
The MX record itself doesn’t have to point to your own domains mail servers or even share a hostname based on your own domain. For instance, if you wanted to use googles webmail service you could use something like this. domain.com 10 smtp1.google.com domain.com 10 smtp2.google.com Don’t use these examples as I made the hostnames up for the purpose of this example. However, as you can see, the sender's mail server would do an MX record lookup and receive smtp1.google.com. It would then do a DNS lookup on smtp1.google.com to get the IP address of googles mail server. The sender would not know they were sending to google without looking at the DNS zone for your domain name.
You can also configure emails to go to subdomains and have each subdomain use a different mail server. For example, say you were running a subdomain based WordPress network. Let’s use planespotting.com as the example. Bill, Andy, and Terry are members of the plainspotting.com blog network and have the following hostnames on that network.
The owner of the network has his own email address such as firstname.lastname@example.org and has the primary domains MX record pointing to his main server. However, he wants to allow people to have their own email address attached to their subdomains providing that they host their own mail services. He doesn’t want the hassle of offering or maintaining a full-blown mail service. Here is how his DNS zone looks in respect to his emails.
You can see from this example that email sent to anything at the domain *@planespotting.com will go to the owner's mail server. However, email@example.com will go to google.
Now that you know how it is possible to configure for quite a few scenarios, let’s look at the most basic one that most people starting up will want, which is a simple server such as a VPS or dedicated server that run their web and mail services. A complete zone file for this would look like this.
You don’t really need much more than this. The mail.domain.com hostname would be used for both incoming and outgoing email (on different ports). There is no need for separate hostnames. You could even point the MX record to the www. hostname if you wish.
Remember to replace the 10.x.x.x addresses in this tutorial with your actual IP addresses.