Configure MX Records for Incoming SMTP E-Mail Traffic

How do I configure and test the MX Record for my Internet Domain name?

When you want to run your own mail server, and it does not matter what version and make of mail server you’re using – as long as the mail server is using SMTP as the e-mail transfer mechanism – you’ll need to configure the MX Records for your domain.

MX is an acronym for Mail eXchange. MX is defined in RFC 1035. It specifies the name and relative preference of mail servers for the zone. MX is a DNS record used to define the host(s) willing to accept mail for a given domain. I.e. an MX record indicates which computer is responsible for handling the mail for a particular domain.

Without proper MX Records for your domain, only internal e-mail will be delivered to your users. External e-mail from other mail servers in the world will not be able to reach your server simply because these foreign servers cannot tell to which server they need to “talk” (or open a connection to) in order to send the mail destined for that domain.

You can have multiple MX records for a single domain name, ranked in preference order. If a host has three MX records, a mailer will try to deliver to all three before queuing the mail.

MX Records must be in the following format:

domain.com. IN MX 10 mail.domain.com.

The Preference field is relative to any other MX Record for the zone and can be on any value between 0 and 65535. Low values are more preferred. The preferred value is usually 10 but this is just a convention, not a thumb rule. Any number of MX Records may be defined. If the host is in the domain it requires an A Record. MX Records do not need to point to a host in the same zone, i.e. an MX Record can. point to an A Record that is listed in any zone on that DNS or any other DNS server.

External and Internet-connected networks

When connecting your mail server to the Internet (or to another ex-organizational mailing system that uses SMTP) you must always make sure that the rest of the world can successfully resolve your domain’s MX Record. Failing to do so will cause e-mail traffic not to be delivered to you.

In order to properly configure your domain’s MX Record you should contact your ISP (Internet Service Provider) or the party responsible for hosting your DNS Domain name. They will ask you for your FQDN (Fully Qualified Domain Name) and IP address of your mail server. Make sure you know them.

When your mail server is connected directly to the Internet

In cases where no NAT (Network Address Translation) is being used and where your mail server is directly connected to the Internet, you will need to provide them with the FQDN and IP address of your mail server.

Note: This is, by far, the least secure method for connecting a mail server to the Internet.

Let’s say you have the following LAN configuration:

In the above example you need to give the mail server’s IP address as your MX Record.

Domain name: dpetri.net

Record FQDN

Record Type

Record Value

MX Pref

mail.dpetri.net

A

212.143.143.130

dpetri.net

MX

mail.dpetri.net

10

You should make sure the ISP has had all the necessary routing tables updated in order to provide Internet availability to your internal IP network range.

Note: It doesn’t matter if the real host name of the mail server is NOT “mail”. Internet hosts don’t mind that, they just need to know what’s the name of the mail server, and what’s the IP address for that name.

When NAT is being used

In cases where NAT (Network Address Translation) is being used you will need to provide them with the IP address of your external NAT interface, and configure your NAT device with Static Mapping for TCP Port 25, and have all TCP Port 25 traffic forwarded to the internal IP address of your mail server.

Let’s say you have the following LAN configuration:

In the above example you need to give the NAT’s IP address as your MX Record.

Domain name: dpetri.net

Record FQDN

Record Type

Record Value

MX Pref

mail.dpetri.net

A

192.90.1.1

dpetri.net

MX

mail.dpetri.net

10

Note: Make sure you properly configure the NAT device to forward all TCP Port 25 traffic to 192.168.0.10.

When a Mail Relay is being used

In cases where you have a DMZ (Demilitarized Zone) with a Mail Relay host (i.e. Linux, Windows 2000/2003 + IIS and SMTP, a dedicated appliance and so on) you will need to provide the FQDN and IP address of your Mail Relay machine, and configure the Firewall to only allow TCP Port 25 traffic to be sent to the Mail Relay’s IP address, not to your real mail server.

You should then configure the Mail Relay to forward the incoming e-mail traffic to the real mail server (after scanning it for spam, viruses and so on).

Let’s say you have the following LAN configuration:

In the above example you need to give the Mail Relay’s IP address as your MX Record.

Domain name: dpetri.net

Record FQDN

Record Type

Record Value

MX Pref

mail.dpetri.net

A

192.90.1.17

dpetri.net

MX

mail.dpetri.net

10

Note: Make sure you properly configure the Firewall device to forward all TCP Port 25 traffic to 192.90.1.17, and to allow 192.90.1.17 to send TCP Port 25 traffic to your internal mail server at 192.168.0.10. Also, make sure you let the internal mail server communicate only with the Mail Relay device and that you set up an SMTP Connector on the mail server and configure it to relay all external mail to the Mail Relay.

Note: Some networks might use the Internet Router as their NAT device, and let the Firewall do just that. In those cases, the scenario is a mixture between option #2 (NAT) and this one.

Internal networks

As stated above, there is usually no need to configure MX Records for internal use, simply because internal (i.e. inter-organization) e-mail and replication traffic is usually controlled via Active Directory-store information. However there are some cases where you will want to configure internal MX Records.

While these MX Records will generally not cause any harm even if you configure them without actually needing them, you must pay close attention to various configuration issues, especially when Mail-Relays and Smart-Hosts are involved. Therefore I cannot say for sure if configuring non-necessary MX Records will cause any problems to your local network. If you do not know for sure (and this might be the case since you’ve bothered to read this article in the first place) I suggest you consult a network specialist before doing any changes.

Fault Tolerance

In case your mail server fails you’d like to still be able to receive incoming e-mail messages. Most small to medium sized companies will pay their ISPs some monthly fee and that will buy them storage space on the ISPs mail servers. For that to happen, a new MX Record will be added to their DNS information, pointing to the ISPs mail server with a higher priority. For example:

Record FQDN

Record Type

Record Value

MX Pref

mail.dpetri.net

A

192.90.1.17

mail.isp.com

A

212.143.25.1

dpetri.net

MX

mail.dpetri.net

10

dpetri.net

MX

mail.isp.com

100

Load Balancing

Medium to large sized companies will want to configure some load balancing features for their incoming mail servers. For that to happen, the company must set up a number of mail servers, each one with a different IP address (actually, one can use Network Load Balancing – NLB, or even clustering but that’s a topic for a different article). Then new MX Records will be added to their DNS information, pointing to the mail servers, all with the same priority. For example:

Record FQDN

Record Type

Record Value

MX Pref

maila.dpetri.net

A

192.90.1.17

mailb.dpetri.net

A

192.90.1.18

mailc.dpetri.net

A

192.90.1.19

mail.isp.com

A

212.143.25.1

dpetri.net

MX

maila.dpetri.net

10

dpetri.net

MX

mailb.dpetri.net

10

dpetri.net

MX

mailc.dpetri.net

10

dpetri.net

MX

mail.isp.com

100

Testing the MX Record configuration

Testing the MX Record configuration is critical especially when configuring it for the first time with a new ISP you don’t know that well and so on. Use NSLOOKUP or DIG or any other DNS querying tool to make sure your records are set straight.

MEMBER LOGIN:

BECOME A PETRI MEMBER:

About the Contributor

Daniel Petri is a world-known IT professional, technical trainer and creator of one of the world’s largest IT knowledge bases – www.petri.com. Daniel consults to leading global Fortune 1000 companies in Microsoft IT Infrastructure and Engineering strategies.

For his contribution to the IT Pro community Daniel has received the Microsoft Most Valuable Professional (MVP) award for the 14th time. Daniel’s professional certifications include Microsoft Certified Technology Specialist, Microsoft Certified Systems Engineer, Microsoft Certified System Administrator and Microsoft Certified Trainer.

While working for Microsoft, Daniel serves as a Senior Premier Field Engineer (PFE) specializing in Windows Server OS and Active Directory.
Daniel now works for ObserveIT, makers of the Insider Threat Detection software, where he holds the role of Senior Solutions Architect, where he manages large deployment projects and partner and customer training programs.

In his spare time, Daniel rides a 1200cc 2015 model Ducati Multistrada 1200S bike and manages the Israeli Bikers forum.