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.
Summary
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.
Hi Paul, kindly help the below scenario
1- we have exchange 2019
DAG mailbox server roles
EX0-1 172.16.1.10
EX0-2 172.16.1.10
https access NAT (spacename email.domain.com/owa )
facing protocol TCP 443 on public IP 95.33.xx.5)
========================
2- DMZ inside 192.168.4.20 ( mail gateway)
mail gateway IMSVA delivered method (routing) and facing protocol TCP 25 on public IP 95.33.xx.4 (ISP PTR record mail1) mail1.domain.com
========================
the problem is that we cant able to access OWA form outside
Incoming /outgoing emails NOT working.
kindly tell me correct MX records in the public DNS and internal DNS zone
your support is highly appreciated
hi Paul,
i would like to ask you, about undelivered report after unistall an old exchange server and change the domain name. I unistalled my old exchange and moved to office 365 but when someone send a mail to my old domain, no undelivered report sending to him as an answer. What have to do, all the senders ( to old domain) receive an undelivered report when they send message to old domain?
Hi Pual, we have actually one exchange server, our company is going to change the ISP so I should go and point the new public IP to my mx record or I should assign the new IP and wait for 24 or 48 hours to update then assign the new public IP to exchange server. Thanks a lot.
Quick correction…I plan to have Microsoft 365 manage DNS for me (not GoDaddy).
Hi Paul,
This great and informative blog post is greatly appreciated!
I know it’s been a while, but I am hoping you, might have a minute for what I think is a quick question (well, a question that likely has a quick answer).
My domain is registered with GoDaddy but “hosted” (no web site), along with email, by a local provider (Name servers in GoDaddy are configured as the local provider’s servers). I am cutting all ties with the local provider and wish to move my email to Exchange Online.
Without any support from the local provider, is it possible for me to simply change the DNS servers to the default in GoDaddy and create a new MX record (in GoDaddy) to point to Exchange Online?
I have familiarized myself with the process. I plan to do it when email traffic is nil and will have all the accounts (very few) created in EO and all emails migrated (both from the local provider and Outlook pst files).
Just a quick yes or no to the aforementioned question is all I ask. 🙂
Sincerely,
Kent
SW developer in Missoula, MT
The Real Person!
The Real Person!
Yes, you can point your name servers at another DNS provider, and then configure any DNS records you need in your DNS zone hosted by that new DNS provider. It may take 24-48 hours for everyone else on the internet to start querying your new DNS provider for your domain, so don’t cancel your old service immediately, give it a couple of days. You can use a service like whatsmydns.com to check propagation of your name server change.
Hi Paul,
I have a question.
We have actually two exchange server, one in Brasil and another in Argentina, Argentina is hosting the Forest Root, and Brasil is a domain in this forest, but remotelly. We had created trusted relationship between two domains. But now, we need to route inbound Argentina mails trhorugh Brasil. Question is: We only need to change MX records to point to Brasil IP and Exchange Server automatically will route through AD sites and services to Argentina? and what happens to outblound traffic ? if we decide route outbound emails from Argentina Exchange Server, we only need to modify Brasil SPF´s to add autorized Argentina IP´s? and another question. What we need to create to route Argentina outbound emails traffic to Brasil (MPLS connected) ?. Thanks a lot.
Paul,
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.
Thanks.
Thank you Paul..
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
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.
Maria
The Real Person!
The Real Person!
You need to set up MX records.
https://www.practical365.com/mx-record/
Pingback: spoof http referer autosurf
Hi Paul,
I have some matters to ask regarding the mx records. Currently, our exchange server allow multiple domains to send and receive email thru our exchange server. For inbound and outbound email, we are using messagelabs for the email spam filter, so our MX records are pointing to the messagelabs.
however, now we would like to remove one of domain out from the our exchange as it be will be using other external mail server to send and receive email. Currently for this domain the TTL is 2 hours. Which scenario from your example above I should follow?
Should I just change the TTL to lower value first and then point the MX records to new external mail server? I am worry abt the TTL and loss of email.
Thanks for your attention.
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.
The Real Person!
The Real Person!
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:
https://www.practical365.com/exchange-2010-free-training-videos/
(it applies to both Exchange 2007 and 2010)
Obviously DNS, firewalls etc also play a part in this.
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!