12.4.4 MX

Understanding MX Records

In this chapter you will focus on MX records, which are a specific DNS record type used for email delivery. Other DNS record types are handled in their own chapters, so here we only look at what is unique about MX records and how they are used.

What an MX Record Represents

An MX (Mail Exchanger) record tells the world which mail servers are responsible for receiving email for a domain. When someone sends an email to user@example.com, the sending mail server asks DNS: “Where should I deliver mail for example.com?” The DNS answer is a list of MX records.

Each MX record points to a hostname, not directly to an IP address. That hostname must itself resolve, usually with an A or AAAA record, to one or more IP addresses where the mail server actually runs.

For example, the domain example.com might have these MX records:

The MX records do not carry IP addresses themselves. They only point at hostnames which are then resolved separately.

Priority and Selection of Mail Servers

Something unique about MX records is that they contain a numeric priority value. In many DNS outputs this field is called preference, priority, or distance, but the meaning is the same. It is an integer where lower values indicate higher priority.

For a given domain, multiple MX records can exist. The sending mail server uses the priority values to choose which target mail server to contact first.

Consider this set of MX records for example.org:

The selection rules that common mail servers follow are:

1. Group MX records by their priority value.
2. Start with the lowest priority number (highest priority group).
3. If there are multiple MX records with the same priority in that group, select between them in a round robin or random fashion.
4. If all servers in that group are unreachable, move to the next higher priority number and try that group.

This system allows a domain to define a primary mail server and one or more secondary or backup mail servers. It also allows some basic load distribution at the same priority level.

MX Records and Hostname Resolution

Each MX record must point to a hostname that can be resolved to an IP address. A mail server follows this basic process:

1. Look up MX records for the recipient domain, for example example.com.
2. Sort the MX records by priority.
3. For the selected MX hostname, for example mail1.example.com, look up its A or AAAA record in DNS.
4. Connect to that IP address on the email service port, typically TCP port 25 for SMTP.

If the MX hostname does not have a valid A or AAAA record, or if DNS is misconfigured, mail delivery will fail or be delayed.

This separation gives flexibility. You can change the IP address of mail1.example.com without touching the MX record itself. Mail servers will automatically find the new IP when they resolve the hostname.

Default MX Behavior When No MX Exists

An interesting special case exists when a domain has no MX records at all. In that situation, many mail servers fall back to using the A or AAAA record of the domain name itself as an implicit mail server.

For instance, if example.net has:

and no MX records, then some sending mail servers will attempt to deliver mail directly to example.net at the IP 203.0.113.5.

However, modern best practice is to always configure explicit MX records for domains that should receive mail. Relying on implicit behavior makes troubleshooting and configuration less clear.

MX Records for Hosted Email Services

MX records are often used to direct email to external providers. If you use a cloud email service, the provider gives you specific MX records to configure.

For example, a provider might say:

Configure your MX records like this:

You keep control of your domain through DNS, but you delegate the actual handling of email to the provider’s mail servers. All email for @yourdomain.com will be delivered to the provider’s infrastructure that matches the MX hostnames.

This separation between the domain owner and the mail host is one of the strengths of MX records. You can change providers by changing MX records without changing user email addresses.

Redundancy and Failover with MX

MX records are a simple and common way to provide redundancy for email delivery. By publishing multiple MX records with different priorities, you describe how other mail servers should attempt delivery if something goes wrong.

A typical pattern is:

In normal conditions, sending mail servers will use mail.primary.com because it has the lower priority number. If that server is down or unreachable, senders will try mail.backup.com instead.

Some organizations also use the same priority for several MX servers to spread load evenly under normal operation:

Sending mail servers will typically rotate between mail1 and mail2 for regular traffic, and use mail-backup only if both primaries fail.

Basic Anatomy of an MX Record

An MX record has a specific structure. A simple representation in zone file format looks like:

example.com. 3600 IN MX 10 mail.example.com.

The parts are:

From an administrator’s perspective, you typically set the domain name, the priority values, and the mail server hostnames. TTL controls how long other DNS resolvers can cache this information.

How Mail Servers Use MX Information

Putting the pieces together, a sending mail server generally follows this algorithm when delivering mail to user@example.com:

1. Extract the domain part: example.com.
2. Query DNS for MX records of example.com.
3. If MX records exist, sort them by ascending priority.
4. Within the lowest priority group, pick one hostname and look up its A or AAAA record.
5. Attempt an SMTP connection to that IP address on the standard email port.
6. If the connection fails, try another MX in the same priority group, or move to the group with the next higher priority value.
7. If no MX records exist, some servers fall back to the A or AAAA record of example.com as a last resort.

This process shows how MX records guide the path that email takes across the network as it moves from sender to recipient.

Misconfigurations and Their Effects

Because MX records are central to receiving email, errors in MX configuration can cause visible problems. Common issues include:

Pointing MX records to hostnames that do not exist. In that case, when other mail servers try to resolve the hostname, they fail. As a result, messages bounce back to senders.

Using an IP address directly as the MX target. Many DNS tools will reject this. Even if accepted, other mail servers may refuse to use such records or behave inconsistently.

Forgetting to configure A or AAAA records for the MX target hostnames. The MX records would appear valid but delivery would still fail because the target hostnames cannot be resolved.

Setting only one MX record with no backup. If the single mail server or its network goes down, all incoming mail will be delayed or rejected. Some sending servers will queue mail for a period, but if the outage is long, mail can bounce.

Using a very short TTL for MX records without need. This can increase DNS query load and slow down delivery, while not providing clear benefits.

Understanding how MX records are supposed to work helps with diagnosing such problems. If email is not arriving, checking the MX records and the hostnames they reference is often an early troubleshooting step.

How MX Fits with Other DNS Records

MX records exist alongside other DNS record types. For email delivery, the relationship is:

The domain has MX records that identify hostnames for mail.

The hostnames used in MX targets have A or AAAA records to map to IP addresses.

Additional specialized records for email security and policy are defined elsewhere, but they often refer to the same domains and hostnames.

MX records themselves are focused purely on routing inbound mail to the right mail servers. They do not define how users send outgoing mail to their provider, and they do not directly express security policies. Their role is to connect the recipient domain name to the appropriate mail servers through DNS.