Home » Exchange Server » Managing Changes to MX Records and Incoming Email Traffic

Managing Changes to MX Records and Incoming Email Traffic

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:

  1. A hosted email security platform (eg Exchange Online Protection, Messagelabs, GFI)
  2. 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.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server


  1. Kcliew says:

    Paul, can I just point the mx record directly to my exchange server 2007 so that all the incoming mails will come directly to my server. Currently I’m using pop3 to download mails for web mail.

    • I don’t know enough about your environment to say yes for sure.

      Yes, pointing the MX record directly to your Exchange server is how you get mail to deliver directly to Exchange.

      However, by default the Exchange 2007 and 2010 Hub Transport server role do not accept incoming internet/anonymous email. You need to adjust the Receive Connector settings first.

      There’s a demonstration of this in the “Configuring incoming email” video on this page:

      (it applies to both Exchange 2007 and 2010)

      Obviously DNS, firewalls etc also play a part in this.

      • Mk says:

        Hi Paul,
        I have same situation but mine is Exchange 2016. Currently I’m using POP3 to download mails from web mail to Exchange server. Now I want to change domain MX record to directly pointing to Exchange server, so that all the incoming mails will come directly to my server.

        Pls help!

  2. mmartin says:

    Hi Paul,

    Am a new exchange administrator. Kindly help me on the following issue.

    We have on-premise exchange. We will be transitioning to a new domain name, example – from oldpublic.com (old)- to newpublic.ca (new). (1) I added newpublic.ca to mailflow-accepted domain; (2) I updated the mail flow-email address policies to include email@newpublic.ca. Internally, this is working, user will receive email using the address user@oldpublic.com & user@newpublic.ca. However, external email is not coming in. What other tasks should I do so that our customers (public) can send email to us using both the old email add (user@oldpublic.om) and the new domain (user@newpublic.ca).

    Thank you looking forward to your advise.


  3. Bill says:

    Hi Paul,

    Was hoping of cutting over our mx from the current mail1.contoso.com to mail.contoso.com we have exchange 2007 on premises and have a dns provider which we want to move away from. What process would you recommend taking on the transtransitining of this, first time doing so, please pardon the ignorance

  4. Bdubs says:

    This is a great article, as are many other’s I have seen from you. You have a great way of breaking down exchange/technical concepts for us less technical admins. I am a newer exchange admin for a small organization with only one active site. I have a scenario that I think this might be helpful for and would love your advise.
    I have a remote site for disaster recovery with identical servers mothballed, that I plan to use as a lab environment. I am also trying to work out a way to use this site as a failover for extended electrical outages we have in our main office. I do not want to have these servers active normally except for these rare occasions where we have a maintenance window of more than 1 or 2 hours once every year or two. I am planning to use backup appliance devices that have instant recovery options for virtual servers. My question is how do I cut over the mail flow and connections on command without having active remote servers and load balancers.
    Can I use lower preferenced dns/mx records, and simply enable the NAT on the remote site firewall once I have powered off the main site and want mail flow changed over? I’m worried about what emails I would lose while waiting for the change to propagate. Of course I would have to change it back again once the maintenance is complete.

Leave a Reply

Your email address will not be published. Required fields are marked *