Configure MX Records for Incoming

SMTP E-Mail Traffic

by Daniel Petri - January 7, 2009

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

There are several new features included within Exchange Server 2007, which some of my
articles touch on briefly. However, if you are looking for training that takes you from
installation to integration with Outlook and management of Exchange Server 2007 then
you need Train Signal's training videos. The Exchange Server 2007 training videos are
taught by Microsoft MVP and MCSE, David Shackelford, who teaches with a "Hands-
on" approach.

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:

The Domain name system (DNS) implements a distributed, hierarchical, and redundant
database for information associated with Internet domain names and addresses. This List
of DNS record types provides an overview of types of resource records (database
records) stored in the zone files of the DNS.

[edit] Resource Records

Defining
Code Number Description Function
RFC
Returns a 32-bit IPv4 address,
most commonly used to map
address hostnames to an IP address of
A 1 RFC 1035
record the host, but also used for
DNSBLs, storing subnet
masks in RFC 1101, etc.
Returns a 128-bit IPv6
IPv6 address address, most commonly used
AAAA 28 RFC 3596
record to map hostnames to an IP
address of the host.
 Location of database servers of
an AFS cell. This record is
commonly used by AFS
AFS
clients to contact AFS cells
AFSDB 18 RFC 1183 database
outside their local domain. A
record
subtype of this record is used
by the obsolete DCE/DFS file
system.
Certificate
CERT 37 RFC 4398 Stores PKIX, SPKI, PGP, etc.
record
Alias of one name to another:
Canonical the DNS lookup will continue
CNAME 5 RFC 1035
name record by retrying the lookup with the
new name.
DHCP Used in conjunction with the
DHCID 49 RFC 4701
identifier FQDN option to DHCP
For publishing DNSSEC trust
DNSSEC anchors outside of the DNS
Lookaside delegation chain. Uses the
DLV 32769 RFC 4431
Validation same format as the DS record.
record RFC 5074 describes a way of
using these records.
DNAME will delegate an
entire portion of the DNS tree
under a new name. In contrast,
the CNAME record creates an
delegation
DNAME 39 RFC 2672 alias of a single name. Like the
name
CNAME record, the DNS
lookup will continue by
retrying the lookup with the
new name.
The key record used in
DNS Key
DNSKEY 48 RFC 4034 DNSSEC. Uses the same
record
format as the KEY record.
The record used to identify the
Delegation
DS 43 RFC 4034 DNSSEC signing key of a
signer
delegated zone
Method of separating the end-
Host Identity
HIP 55 RFC 5205 point identifier and locator
Protocol
roles of IP addresses.
Key record that can be used
IPSECKEY 45 RFC 4025 IPSEC Key
with IPSEC
KEY 25 RFC 4034 Key record Used only for TKEY (RFC
2930). Before RFC 3755 was
published, this was also used
 for DNSSEC, but DNSSEC
now uses DNSKEY.
Specifies a geographical
Location
LOC 29 RFC 1876 location associated with a
record
domain name
mail Maps a domain name to a list
MX 15 RFC 1035 exchange of mail exchange servers for
record that domain
Allows regular expression
Naming based rewriting of domain
NAPTR 35 RFC 3403 Authority names which can then be used
Pointer as URIs, further domain names
to lookups, etc.
Delegates a DNS zone to use
name server
NS 2 RFC 1035 the given authoritative name
record
servers
Part of DNSSEC—used to
Next-Secure prove a name does not exist.
NSEC 47 RFC 4034
record Uses the same format as the
(obsolete) NXT record.
An extension to DNSSEC that
NSEC record allows proof of nonexistence
NSEC3 50 RFC 5155
version 3 for a name without permitting
zonewalking
NSEC3 Parameter record for use with
NSEC3PARAM 51 RFC 5155
parameters NSEC3
Pointer to a canonical name.
Unlike a CNAME, DNS
processing does NOT proceed,
pointer just the name is returned. The
PTR 12 RFC 1035
record most common use is for
implementing reverse DNS
lookups, but other uses include
such things as DNS-SD.
Signature for a DNSSEC-
DNSSEC
RRSIG 46 RFC 4034 secured record set. Uses the
signature
same format as the SIG record.
Signature record used in
SIG(0) (RFC 2931). Until
RFC 3755 was published, the
SIG 24 RFC 2535 Signature
SIG record was part of
DNSSEC; now RRSIG is used
for that.
SOA 6 RFC 1035 start of Specifies authoritative
authority information about a DNS
 zone, including the primary
name server, the email of the
domain administrator, the
record
domain serial number, and
several timers relating to
refreshing the zone.
Specified as part of the SPF
protocol, as an alternative to
SPF 99 RFC 4408 SPF record storing SPF data in TXT
records. Uses the same format
as the TXT record.
Generalized service location
record, used for newer
Service
SRV 33 RFC 2782 protocols instead of creating
locator
protocol-specific records such
as MX.
Resource record for publishing
SSH public host key
SSH Public
fingerprints in the DNS
SSHFP 44 RFC 4255 Key
System, in order to aid in
Fingerprint
verifying the authenticity of
the host.
Part of a deployment proposal
for DNSSEC without a signed
DNSSEC
DNS root. See the IANA
TA 32768 None Trust
database and Weiler Spec] for
Authorities
details. Uses the same format
as the DS record.
Originally for arbitrary
human-readable text in a DNS
record. Since the early 1990s,
however, this record more
often carries machine-readable
TXT 16 RFC 1035 Text record
data, such as specified by RFC
1464, opportunistic
encryption, Sender Policy
Framework (deprecated),
DomainKeys, DNS-SD, etc.

[edit] Other types and Pseudo Resource Records

Other types of records simply provide some types of information (for example, an
HINFO record gives a description of the type of computer/OS a host uses), or others
return data used in experimental features. The "type" field is also used in the protocol for
various operations.
 Defining
Code Number Description Function
RFC
Returns all records of all types known
to the name server. If the name server
does not have any information on the
name, the request will be forwarded
All cached on. The records returned may not be
* 255 RFC 1035
records complete. For example, if there is both
an A and an MX for a name, but the
name server has only the A record
cached, only the A record will be
returned.
Transfer entire zone file from the
Full Zone
AXFR 252 RFC 1035 master name server to secondary name
Transfer
servers.
Requests a zone transfer of the given
zone but only differences from a
previous serial number. This request
Incremental
may be ignored and a full (AXFR) sent
IXFR 251 RFC 1995 Zone
in response if the authoritative server
Transfer
is unable to fulfill the request due to
configuration or lack of required
deltas.
This is a "pseudo DNS record type"
OPT 41 RFC 2671 Option
needed to support EDNS
Transaction One way of providing a key to be used
TKEY 249 RFC 2930
Key with TSIG
Record that supports one set of
security mechanisms for DNS. Used to
secure communication between DNS
Transaction
TSIG 250 RFC 2845 resolvers and Name servers, in
Signature
contrast to DNSSEC, which secures
the actual DNS records from the
authoritative name server.