Configure MX Records for Incoming SMTP E-Mail Traffic

[LEFT][CODE]http://www.petri.co.il/configure_mx_records_for_incoming_smtp_email_traffic.htm[/CODE]
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 [URL="http://www.faqs.org/rfcs/rfc1035.html"] RFC 1035[/URL]. 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:
[I] domain.com. IN MX 10 mail.domain.com.[/I]
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.
[B]External and Internet-connected networks[/B]

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.
[B]When [/B] [B]your mail server is connected directly to the Internet[/B]
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.
[B]Note:[/B] 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:
[IMG]http://www.petri.co.il/wp-content/uploads/configure-mx-records-for-incoming-smtp-e-mail-traffic_1239681178729.png[/IMG]
In the above example you need to give the mail server's IP address as your MX Record.
[B]Domain name: dpetri.net[/B]
[IMG]http://i49.tinypic.com/iqdgxz.jpg[/IMG]
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.
[B]Note:[/B] 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.
[B]When NAT is being used[/B]
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:
[IMG]http://www.petri.co.il/wp-content/uploads/configure-mx-records-for-incoming-smtp-e-mail-traffic_1239681205487.png[/IMG]
In the above example you need to give the NAT's IP address as your MX Record.
[B]Domain name: dpetri.net[/B]
[IMG]http://i49.tinypic.com/243l2sx.jpg[/IMG]
[B]When a Mail Relay is being used[/B]
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:
[IMG]http://www.petri.co.il/wp-content/uploads/configure-mx-records-for-incoming-smtp-e-mail-traffic_1239681227852.png[/IMG]
[IMG]http://i47.tinypic.com/2h3mm2p.jpg[/IMG]


[B]Internal networks[/B]

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.
[B]Fault Tolerance[/B]

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:
[IMG]http://i45.tinypic.com/wkwpi.jpg[/IMG]
[B]Load Balancing[/B]

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:
[IMG]http://i50.tinypic.com/34z0q5l.jpg[/IMG]
[B]Testing the MX Record configuration[/B]

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.
Sample screenshot is of an NSLOOKUP test to Microsoft's MX Records:
[IMG]http://www.petri.co.il/images/test_mx.gif[/IMG]

Also, make sure you can connect to the mail server by using the MX Record information. You can do so by using Telnet, as described in the [URL="http://www.petri.co.il/smtp_pop3_and_telnet.htm"]SMTP, POP3 and Telnet in Exchange 2000/2003[/URL] and [URL="http://www.petri.co.il/test_smtp_service.htm"]Test SMTP Service in IIS and Exchange[/URL] articles
[/LEFT]