What Is a DNS MX Record and How Mail Routing Works

When you send an email, your mail server has to answer one question first: which machine accepts mail for the recipient's domain? The MX record is the DNS entry that answers it. It maps a domain to the mail servers responsible for receiving its email, and it sets the order those servers should be tried.

This section starts with the basics and then goes deeper. It covers what an MX record is, how mail-server priority decides delivery order, how it differs from an A record, how to read the syntax, what happens when a domain has no MX record or publishes a null MX, the misconfigurations that break mail or expose a domain, and how security teams read MX data. For the broader picture of how DNS works, start with the earlier sections of this guide.

What Is a DNS MX Record?

An MX (Mail Exchange) record is a DNS resource record that names the mail server or servers that accept email for a domain, along with a preference value that ranks them. When a sending server has mail for [email protected], it queries DNS for the MX records of example.com, then connects to the listed mail server with the lowest preference number first. Without an MX record, a domain has no dedicated mail exchanger, and email delivery to it becomes unreliable.

MX Record History

The MX record replaced an earlier, clumsier scheme. Original DNS used two separate record types, MD and MF, to mark a "closer" and a "less close" mail destination, which cached badly and was hard to reason about. The redesign folded both into a single MX type with a numeric preference value, defined in RFC 1035 in 1987.

The routing rules that use those records now live in the SMTP standard, RFC 5321. It states that a sending server usually finds the receiving host through the DNS mail exchange mechanism rather than any hard-coded route, which is why a domain can move its mail service by editing a DNS record instead of changing anything on the sender's side.

How MX Records Work

Mail delivery is driven by the preference value on each MX record. Per RFC 1035, preference is a 16-bit integer, and lower values are preferred. A record at preference 10 is tried before one at preference 20. The number itself has no unit and no meaning beyond ranking; 10 and 20 work exactly like 5 and 50.

A message transfer agent (MTA) runs the sequence: query the domain's MX records, sort them by preference, resolve the lowest-numbered host to an address, open an SMTP connection, and hand over the message. If that host does not answer, the MTA moves to the next one in the list.

MX Record Priority and Failover

Multiple MX records give a domain redundancy. A common setup lists a primary at preference 10 and a backup MX at preference 20, so mail flows to the primary until it becomes unreachable, then falls back to the secondary.

Records that share the same preference are treated as equals. RFC 5321 says a sender should randomize among equal-preference hosts to spread load across them, which is how operators balance incoming mail without extra hardware. One point to be clear about: MX priority is not a load balancer and does not run health checks. It only sets the order in which sending servers try each mail host, and the sole load-spreading effect comes from randomizing across equal-preference records. Many operators space their values in tens to leave room to insert a server later.

One nuance to expect in practice: the SMTP standard is not strict about which failures trigger a jump to a higher-preference (more distant) server. Some MTAs move to the next MX only when a host is unreachable, while others also retry elsewhere after certain temporary errors. Both behaviors are valid, so a backup MX may see traffic in more situations than a newcomer expects.

When a Domain Has No MX Record

A domain is not required to publish an MX record, and older behavior still applies when one is absent. RFC 5321 section 5.1 says that if the MX lookup returns an empty list, the sender treats the domain itself as an implicit MX at preference 0 and attempts delivery to the domain's A or AAAA address. This kept mail working for hosts that predated MX records.

Although SMTP defines this fall back to the domain's A or AAAA record, relying on it is discouraged because implementations and operational policies vary. The domain's A record also usually points at a web server that is not set up to receive mail. A domain that should accept email needs at least one real MX record; a domain that should not is better served by the null MX described below.

MX Record vs A Record

An A record and an MX record answer different questions and mixing them up is a common source of mail problems. An A record maps a hostname to an IP address. An MX record does not point to an IP address at all: it names the mail servers that receive a domain's email and ranks them by preference, and each of those mail servers is itself a hostname backed by an A or AAAA record.

For how address records work in detail, see the A record section of this guide.

MX Record Format and Syntax

An MX record in a zone file carries the owner name, TTL, class, record type, the preference value, and the target hostname (the "exchange"). The target is a domain name that must resolve to an address record, not an IP address written directly into the MX record. The MX record example below shows two mail servers for one domain, ranked by preference.

example.com.    3600    IN    MX    10    mail1.example.com.
example.com.    3600    IN    MX    20    mail2.example.com.

Reading left to right: example.com. is the domain receiving mail, 3600 is the TTL in seconds, IN is the Internet class, MX is the record type, 10 and 20 are the preference values, and mail1/mail2 are the mail hosts. TTL behaves the same way it does for other records, so lowering it ahead of a change and raising it afterward works exactly as it does for an A record.

Before switching mail providers, it helps to lower the TTL on your MX records a day or two ahead, for example from 3600 to 300 seconds. Sending servers then pick up the new records quickly once you cut over, which shortens the window where mail could go to the old host. Raise the TTL again after the move settles to reduce lookup load.

What Real MX Records Look Like

Two common managed providers show the pattern. The two examples below are for different domains, not one domain that uses both.

A domain on Google Workspace publishes a single MX record pointing to smtp.google.com at preference 1, per Google's Workspace setup guide. Accounts created before 2023 may still use the older five-record set that begins with aspmx, which Google continues to support.

example.com.    3600    IN    MX    1    smtp.google.com.

A separate domain on Microsoft 365 uses a tenant-specific target in the form yourdomain-com.mail.protection.outlook.com at preference 0, per Microsoft's external DNS reference.

yourcompany.com.    3600    IN    MX    0    yourcompany-com.mail.protection.outlook.com.

These values are current as of July 2026. Microsoft's target is specific to each tenant, so confirm the exact record in your provider's admin console rather than copying it, since providers change these values over time.

Why an MX Target Cannot Be a CNAME

The exchange hostname must point to an A or AAAA record, never to a CNAME alias. RFC 2181 states the rule directly: the value of an MX record must not be an alias, and it must have one or more address records. That prohibition is the reason to follow, on its own.

The mechanism behind it explains why aliases are a poor choice anyway. An MX lookup triggers additional-section processing, where the resolver returns the target's address record alongside the MX answer to save a round trip, a behavior defined in RFC 1035. An alias carries no address, so that step returns nothing useful and the sender has to make extra queries, which can break delivery on stricter mail servers. Always target a hostname that resolves straight to an address.

Null MX: Declaring That a Domain Accepts No Mail

Some domains are never meant to receive email, such as a domain used only for a website. RFC 7505 defines a "null MX" for exactly this case: a single MX record with preference 0 and a target of . (a lone dot).

example.com.    3600    IN    MX    0    .

A null MX tells sending servers to stop immediately instead of falling back to the domain's A or AAAA record and retrying for days. Under RFC 7505, a receiver rejecting mail for a null-MX recipient should return a 556 reply with enhanced status code 5.1.10, and a sender that publishes a null MX on its own from-domain risks a 550 with status 5.7.27. Operators often pair a null MX with an SPF "-all" policy to make the "sends and receives no mail" statement explicit. A null MX is an ordinary MX record, so it can be signed with DNSSEC like any other.

How to Check DNS MX Records

You can read any domain's MX records with a lookup tool or the command line.

The WhoisFreaks DNS Lookup tool returns parsed MX records, in priority order, in JSON, XML, or raw format. For automated or bulk checks across many domains, the WhoisFreaks DNS API returns the same data programmatically.

From a terminal, use dig:

dig example.com MX +short

Or nslookup, which is preinstalled on Windows, macOS, and most Linux systems:

nslookup -type=MX example.com

Both list each mail host with its preference value. If a lookup returns a single MX with a target of ., the domain publishes a null MX and accepts no mail.

Common MX Misconfigurations and Risks

Reading MX records is easy; the value is in spotting when they are wrong. A few patterns account for most broken or unsafe mail setups.

The most frequent is an MX that targets a CNAME or a raw IP address instead of a hostname with an A or AAAA record, which can silently fail on stricter senders. Close behind is a domain with no MX at all, where mail either bounces or leaks to a web server through the implicit-MX fallback. Priority inversion is subtler: if a backup consistently receives more mail than the intended primary, the preference values are usually ordered wrong.

The security case is the dangling MX. When an MX still points to a hostname whose address record was removed, or to a third-party mail service the domain no longer controls, an attacker who can claim that hostname or service may be able to receive mail meant for the domain. That turns a stale DNS entry into a mail-interception or account-recovery risk, which is why abandoned MX targets deserve the same cleanup attention as any other dangling DNS record.

MX Records in Threat Intelligence and Domain Analysis

For security teams, MX records are a signal, not just a config setting. Because they expose which providers handle a domain's mail, analysts read them to map a domain's email infrastructure and to spot patterns across groups of related domains.

Three uses come up often. MX data helps classify a domain's mail setup during phishing and spoofing investigations, since lookalike domains often reveal a mismatched or throwaway mail provider. Monitoring MX changes can flag mail redirection, a step that sometimes precedes email interception or account compromise. And comparing current records against historical MX records shows when a domain switched mail providers, which adds context to an investigation.

From the WhoisFreaks DNS and historical DNS datasets, MX records can be queried at scale across large sets of domains, which is what turns a single lookup into an infrastructure view. Kept brief here on purpose: the point is that MX records carry investigative value beyond email setup.