MX Records - Your Linux Mail Server and the Domain Name System

Your Linux mail server, indeed any mail server, is very reliant on DNS to function correctly. You cannot simply build a mail server and wait for your emails to arrive, it doesnt quite work that way. The world must be made aware of your mail server through the DNS records for your domain. Your mail server must also have access to a reliable name server so that it can route mail to the recipients of the emails you are going to send. Becoming at least passably familiar with DNS and more specifically MX records could be considered a prerequisite if you intend to understand how your mail server works. If some one else is in charge of your DNS then you might simply need to tell them the IP address of your Linux mail server and leave the rest to them, they will create the MX records for you. If, on the other hand you are managing your own DNS and you dont understand the fundamentals please consider reading our tutorials on The BIND Linux DNS server.

We shall not delve too deeply into DNS and its relationship to your Linux mail server other than a quick look at the MX records in the example below. We can see that the example.com domain has two mail servers, the host mail.example.com can be considered the primary mail server. The primary mail server is the final destination of emails to the example.com domain, where they are accummulated to be collected by the example.com email users from their individual email accounts. The primary mail server has the lowest weight of all of the mail servers for this domain, in this example it has a weight of 10 and a mail transport agent attempting to deliver mail to an example.com user will attempt to send mail to this host first. Example.com also has a secondary mail server, mx2.example.com. In our example it has a weight of 20 and it will be the second mail server that other mail transport agents will attempt to deliver example.com mail to. If mail.example.com does not respond to an attempt to deliver mail to it, say it is unavailable for some reason such as an outage then it will attempt to deliver it to mx2.example.com instead. @ IN MX 10 mail.example.com. @ IN MX 20 mx2.example.com. The configuration of mx2.example.com and mail.example.com is quite different, with mx2.example.com having an entry in the relay-domains file for the example.com domain. Mail.example.com is configured for each individual email account as it is the primary mail server for the domain, where the emails will be delivered and eventually collected by the end users. You can even send emails from one mail server and collect them from another, the mail server you use to send emails need not have an MX record associated with it, though if it also acts as one of your secondary mail servers it should. When one of your secondary mail servers receives an email for a domain that is specified in its relay-domains file as one that it secondary mail server for, it will consult the MX records for your domain via DNS to determine where it should deliver the mail to. It will attempt to deliver the mail to a mail server for the domain which has a lower weight than it does. It should do this completely by itself but in some instances it may be necessary to control this behaviour using the SmartHost directive in sendmail.cf, which allows you to specify explicitly the primary mail server.

You may have more than two mail servers with corresponding MX records if you wish though secondary mail servers are really only required as a transitory storage point for emails that cannot be delivered to the primary mail server because it is unavailable or refusing connections such as in the instance of a high load average. There is a point of diminishing returns and it is unlikely that you will require more than three mail servers unless you are operating a very large business or an Internet Service Provider.