Long time Exchange Server Pro reader John asks:
“Do you have a guide for changing MX records? What are the gotchas?”
There are several scenarios where an MX record change is required. In general the scenarios revolve around cutting over the inbound email traffic for an organization from an old internet connection to a new one.
Because this is the kind of situation where a mistake can have a very big impact, let's take a look at a few ways that you might manage an MX record change.
A Look at MX Records
First let's cover the basics. If you don't know what an MX record is, or you're just not sure how they work, then I recommend you read this article before you go any further:
Next, go to MXToolbox, do an MX lookup for your domain, and take a look at your current MX records, which may look something like this.
So for a starting point it is likely that your MX record(s) point to one of two things:
- A hosted email security platform (eg Exchange Online Protection, Messagelabs, GFI)
- A server on your network (whether that be a separate email security server/appliance, or an Exchange server)
There may be some complexity to your MX records, such as multiple records of different costs. This is common for hosted email security platforms as they usually have multiple servers in different geographic locations for redundancy.
For example, here are the MX records for Qantas.
For an on-premise solution you may have multiple internet connections (eg a head office and a branch office) and have an MX record that points to both.
Testing Before You Make Changes
It should go without saying that you need to test the new destination you're planning to use for incoming email *before* you cutover to it.
MXToolbox has an SMTP diagnostics tool that you can use to test any server by hostname or IP address (it doesn't have to have an active MX record pointing at it).
I usually want to do more than what their diagnostics tool provides, so I always get onto an external connection (such as a 3G modem) and simply use Telnet to test SMTP connections to the new destination, making sure that the mail delivers to the intended recipient.
Once you are satisfied with the configuration on the new destination you can perform the actual cut over of inbound email.
Planning the Cut Over
Whichever way you are currently configured will determine the steps required to cut over your email traffic to a different destination. However my general rule of thumb is to make the change for the cut over at the point where there I have the most administrative control, and the least lag time between the change being made and the desired outcome being achieved.
In most cases there are 2-3 places where I have administrative control and can make a change that will impact where email traffic goes.
As I go through these I will stick with the overall scenario that the incoming email is being cut over from one Exchange organization to an entirely new Exchange organization, perhaps due to a merger/acquisition or some other need to migrate to new infrastructure.
Afterwards I will also cover the situation where email is simply being cut over to a new destination within the same organization, for example relocating the primary data center.
1. The External Hosted Email Security Provider
When you have an existing hosted email security provider, and you're only changing the destination that *they* deliver your email to, then you have the advantage that you often won't need to change your actual MX records. The MX records will continue pointing at the email security provider, and all you need to do is update the configuration in the admin control panel they provide you to point to the DNS name or IP address of the new destination.
However a downside to this is that sometimes these changes can take a little while to take effect, so you won't get an immediate cut over, and face another lag if you have to roll it back. I'll go over some strategies for dealing with that a little later in this article.
2. The MX Records
If you're changing to a new email security provider, or to a new on-premises destination when there is no email security provider involved, then you will need to change your MX records in the public DNS zone of your domain.
The key in this situation is the TTL (time to live) of the DNS records. In the earlier example of my domain name the TTL for the MX record, or rather for the DNS name that the MX record points to.
In the earlier example the MX record for one of my test lab domains points to maila.locklan.com.au, and has a 60 minute TTL.
This means that if I make changes in DNS to point the MX record to a new destination, it may take up to 60 minutes for other servers on the internet to expire the old record from their DNS cache and start sending to the new destination.
To mitigate that risk you can drop the TTL for your DNS record down to a very low value, for example 5 minutes. This shortens the lag time for your DNS change to take effect, but you will want to be sure to raise it again to a more reasonable value after the change has been proven successful.
As an additional word of advice, if you're cutting over to an entirely new DNS record, or even an entirely new domain name, establish those DNS records well in advance (at least 48 hours) of the change being made to the MX record to ensure that they will work world-wide when the change is made.
3. The On-Premise Server
This is my favorite place to handle the cut over of email traffic because it is usually the one where I have the most administrative control, as well as the least lag between making the change and it taking effect.
In this scenario you simply reconfigure your incoming email server, whether that is a dedicated server or appliance, or an Exchange server, to route the email to the new destination.
This option may not be available to you for any number of technical or political reasons, but if it is then it makes life a little easier as you can have the most control over the change.
Then once it is confirmed to be working you can go ahead and change the MX record or the external email security provider configuration to send email to the new destination, with fewer concerns about config lag or DNS TTLs because any email that continues hitting the old destination will simply route across anyway.
Cutting Over within the Same Organization
So far the examples have focused on cutting over email to an entirely new organization. But in some cases you'll still be using the same Exchange organization, just changing the primary inbound email route. For example, if you're moving most of your infrastructure to a new data center that has a new internet link.
The good news is that this simplifies matters quite a bit, assuming that the old infrastructure will still exist for a period of time.
After performing the same testing recommended earlier you can make your changes to MX records, or to the configuration of your hosted email security provider, and be far less concerned with any config lag or DNS TTLs because you essentially have two available inbound email routes anyway.
If both inbound routes are not going to be simultaneously available, for example if one internet link is being dropped as the other is brought online, then you would need to treat the scenario more like the earlier examples of cutting over to an entirely new organization.
Timing the Cut Over
The timing of these cut overs can be a sensitive issue. In an ideal world you would make the change at a time of day when the least email traffic is flowing through your servers in order to minimize the potential impact.
If you're not sure what time of day that is you can use Log Parser to work it out.
However, if the change involves multiple parties you may need to compromise on that timing so that all the required people are available for any urgent roll back or other issues that appear. It is no good making a change at midnight if the firewall administrator isn't going to be available.
It is difficult to cover every single possible scenario for an inbound email cut over, but I have tried to cover off the most common ones that I have encountered in the past.
The important thing is that you properly assess your specific scenario, each of the factors involved, and each of the configuration changes that will be required, and map out a change process to suit your situation.