Fix External and Internal Email Server DNS Conflicts

This might be an old trick, but it’s never been one I  have been able to easily remedy. I’ve worked and done a lot of jobs at a lot of places where this has been a problem, especially on Windows networks. With Linux-based DNS servers, this isn’t such a huge trick.

When you set up a Windows domain for a company, let’s call it “Widget Core”, and they host their own email, let’s call it “widgetcore.com” you generally do this. Their local Windows domain is usually called something like “widgetcore.local” and their website and email domain is widgetcore.com. So when you set up an Exchange server you point their MX records with their domain registrar something like this:

widgetcore.com
widgetcore.com MX preference = 0, mail exchanger = mail.widgetcore.com

Internally they might look like this:
internalmailserver.widgetcore.local MX preference = 0, mail exchanger = internalmailserver.widgetcore.local

Note: I modified this from an NSLOOKUP. Your registrar might call the preference “priority” or “weight”.

The problem is that if you set up someone’s company email on their phone, they won’t get company email over the company wireless. That is unless maybe the Exchange server is in a DMZ or you’ve got something else elaborate going on. If you named the internal domain “widgetcore.com” you couldn’t get to the company website inside the Windows domain and all sorts of other problems would crop up.

There is however a simple but non-obvious fix. Just add another forward lookup zone in Windows DNS.

Resolving Different External and Internal Server Names In A Windows Network

Step 1: Open your DNS Manager. I like to install the Administration Tools on my workstation so I don’t have to remote into a server. You can just connect to a DNS server this way. Here’s a link for the Windows 7 version.  Here’s the Windows 8.1 Version.  Here’s the Windows 10 Version (Technical Preview). 

Step 2: On one of your DNS Servers, drill down to the “Forward Lookup Zones” and right-click directly on “Forward Lookup Zones” and click “New Zone”. A wizard will come up. Leave everything default until you come to the “Zone Name” screen. Name the zone EXACTLY what the name of your email server is on the internet. In the case of Widget Core, it would be mail.widgetcore.com.

DNS Zone Name

On the next screen in the wizard, leave it on the default “Only allow dynamic updates”. You can set it to something else if you want, I can’t see how it would matter, but you’d probably have to update every single DNS server in your domain if you want to add something here.

Finish the Wizard.

Step 3: Right click on the new Forward Lookup Zone you just created and select New, then click “New Host (A or AAA)”. Leave the name blank, and just put the internal IP address of your mail server in the IP address field. Click OK. You should see the record you just created. The name field should say “Same as parent folder” and the IP address or “Data” field should have the IP of your mail server in it.

A Record Setting

Step 4: Ping the internet address of your mail server and see if it doesn’t resolve to the internal IP address if your e-mail server. If so it’s a success.

Now, both your internal and external host names should resolve to the same IP address on your local network. This should resolve your problem of cell phones connected to your email server not being able to connect while on the company Wi-Fi network. There are other ways to fix it, but this is the simplest I’ve seen and doesn’t need a lot of messing around with the network or doing anything weird with your registrar/web host. This also is the first step in fixing a really annoying Outlook problem that can occur with certificates.

Leave a Reply