The Mail Exchanger (MX) record is part of the Domain Name Server (DNS) system designed to translate human readable domain names into IP addresses. Much like how Web browsers determine the IP address of web servers via DNS, the MX entry directs incoming mails towards the email server for the associated domain. On this front, administrators with a more technical interest will want to check out the exhaustive details of the MX record is defined under RFC 1035.
So how does the MX record concern the mail administrator? Similar to how DNS can be used to implement advanced solutions such as load-balancing or failover hardware, the MX record can also be used to bolster the capability and robustness of your email server. Obviously, deployment scenarios vary greatly depending on actual requirements and needs; I’ve briefly summarized a list of possible ways that tweaking the inbound MX record can help you better manage your Exchange Server deployment.
- Third party anti-malware or anti-spam filtering
This is probably the most common reason of modifying a domain’s MX record these days. Businesses can quickly and easily offload the hassle (and computational resources required) of filtering spam and other malware by redirecting incoming emails to the service provider of their choice. This vendor will then perform the necessary filtering before forwarding the “cleaned” e-mails back to the correct email server – sparing businesses the need for new hardware purchases or software licensing.
Indeed, by specializing in malware or spam detection and with the ability to refine their techniques across all its customers, these cloud-based providers typically achieve much better detection rates versus stand-alone appliances. And yes, you can easily switch to another provider by simply “throwing the switch” and modifying the MX record accordingly.
- Transition to new servers
While upgrading a new mail server is not a situation frequently encountered by administrators, the occasion does arise at times where it simply cannot be avoided. An example that came to mind would be when Microsoft made the decision to release Exchange 2007 – and Exchange 2010 subsequently – only in 64-bit editions. Organisations with incompatible hardware had no choice but to acquire new hardware in order to use Exchange Server 2007 or Exchange Server 2010.
The option for transitioning between two versions of Exchange is clearly no longer an option, leaving a time-consuming migration as the only way to move the old data over to the newer machine. You can read all about the related intricate here. The key point here though, is that companies can ensure that no emails are lost (or bounce) in the interim by tweaking their MX records to point to the new server before taking the old Exchange Server offline.
- Load Balancing
Larger organizations who are concerned about their Exchange infrastructure being overwhelmed by a deluge of emails can also use their MX record to load balance between multiple Exchange Servers deployed Edge Transport Server role. In fact, this is the recommended way of doing it, as noted by Microsoft TechNet here: “You can load-balance SMTP traffic to your organization between Edge Transport servers by defining more than one mail exchange (MX) resource record with the same priority in the Domain Name System (DNS) database for your mail domain.”
Note that configuring the same priority for both servers is critical for any form of load balancing to take place. Moving ahead, consistency between multiple Edge Transport servers can be achieved via the use of cloned configuration scripts.
- Business Continuity
The idea behind a secondary MX record is simple; the secondary server is contacted to receive incoming emails should the primary server be too busy. For businesses with only one Exchange server, the secondary MX entry can be set up as a relay server to store new emails in the event of an outage with the former. Once the email server has been restored, new emails cached by the relay server are forwarded.
The advantages are simple; no nasty error messages are generated should your Exchange Server go down (or while it is rebooting after installing a patch), and incoming messages are not unnecessarily delayed courtesy of the increasing wait times between each mail delivery attempt. As you can see, businesses can make use of this method to increase their Exchange Server uptime at minimum cost to themselves.
I’ve merely gone through some of the more common and more useful methods of modifying the MX record today. As you can imagine, the above techniques work not only for Microsoft Exchange, but can also be useful for other email servers. One thing for sure, the MX record is an extremely powerful way to manage the “flow” of incoming emails.