MX Records Explained: How Email Finds Your Domain

An MX record publishes the mail servers that are authorized to receive email for a domain. It maps a domain name to one or more mail exchange hostnames, each with a numeric preference value.

When a sending mail server has a message for anyone@example.com, it queries DNS for the MX records of example.com, picks a server based on preference, and opens an SMTP connection to deliver the message. Without a published MX record, other servers have no instructions for where to send your domain's mail.

MX records govern inbound mail only. Your outbound sending, and whether your mail is accepted by recipients, depend on other settings — see the authentication section below.

A single MX record has these parts:

• Name — the domain the mail is addressed to, e.g. example.com. (At the zone root this is often shown as @.)
• Type — always MX.
• Preference / priority — an unsigned 16-bit integer (0–65535). A lower number means a higher preference, so it is tried first.
• Exchange (mail server hostname) — the fully qualified hostname of a server that accepts mail, e.g. mail.example.com. This must resolve to an IP via an A or AAAA record.
• TTL — how long resolvers may cache the record. See TTL and propagation.

In a zone file a record looks like this (note the trailing dot, which marks a fully qualified name):

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

The preference number sets the order in which sending servers try your mail hosts. The rule is the opposite of what people often expect: the lower the number, the higher the priority. A server with preference 10 is tried before one with preference 20.

Lower-priority records act as backups. A sender only moves on to the next-higher number if the more-preferred server fails to accept the connection (it's down, refuses, or times out).

When two or more MX records share the same preference, the sending server treats them as equals and chooses among them in a balanced or random order. That is how you spread incoming mail across multiple servers — give them identical preference values so traffic is distributed (effectively round-robin) rather than ranked.

Say example.com publishes two MX records:

Preference	Mail server (exchange)	Role
10	mx1.example.com	Primary — tried first
20	mx2.example.com	Backup — tried only if the primary fails

In a zone file:

example.com. 3600 IN MX 10 mx1.example.com.
example.com. 3600 IN MX 20 mx2.example.com.

Every sending server will attempt mx1.example.com first. Only if that host can't accept the message will the sender fall back to mx2.example.com. If you instead gave both records preference 10, incoming mail would be balanced across the two servers.

Here is what happens end to end when mail is sent to your domain:

1. The sender's mail server takes the address you@example.com and queries DNS for the MX records of example.com.
2. It sorts the results by preference and selects the lowest-numbered (most preferred) exchange — say mx1.example.com.
3. It resolves that hostname's A/AAAA record to an IP address.
4. It opens an SMTP connection to that IP on port 25 and attempts to deliver the message.
5. If that server is unreachable or refuses the connection, the sender falls back to the next preference (e.g. mx2.example.com) and tries again.
6. If every listed exchange fails, the sending server queues the message and retries later; after enough failures over time it returns a bounce to the original sender.

Port 25 is the standard port for server-to-server SMTP. (The submission ports 587 and 465 are for mail clients sending outbound, and are not what MX-directed delivery uses.)

This is the gotcha that breaks the most setups. The MX exchange field must contain a hostname that resolves through an A or AAAA record.

• Never an IP literal. MX 10 198.51.100.25 is invalid. The value must be a domain name like mail.example.com that itself has an A/AAAA record pointing at 198.51.100.25.
• Never a CNAME. Per RFC 2181, the hostname an MX record points to must not be an alias (CNAME). Many sending servers will reject or mishandle a CNAME target, causing intermittent delivery failures. Always point MX at a name that has a direct A/AAAA record.

If your mail provider hands you a hostname to use, that hostname will already have proper A/AAAA records on their side — you just publish it as your MX target.

If a domain publishes no MX records at all, sending servers may fall back to the domain's own A or AAAA record and attempt delivery directly to that address. This behavior is called the implicit MX rule.

It can make mail "work" without an explicit MX, but it is not recommended: it removes your ability to set priorities or backup servers, ties mail delivery to whatever IP your website happens to use, and is easy to break accidentally. Always publish explicit MX records for any domain that should receive email.

A frequent misconception is that MX records control deliverability or block spoofing. They don't. MX only says where mail goes. Whether your outgoing mail is trusted — and whether it lands in the inbox instead of spam — is determined by three authentication mechanisms, all published as TXT records, separate from MX:

• SPF — a TXT record listing which servers are allowed to send mail for your domain.
• DKIM — a cryptographic signature on each message, with the public key published as a TXT record.
• DMARC — a TXT policy that tells receivers what to do when SPF/DKIM checks fail, and where to send reports.

You need correct MX records to receive mail and correct SPF/DKIM/DMARC to be trusted when you send. See SPF, DKIM & DMARC explained for how to set those up.

Most domains use a hosted email service rather than running their own mail servers. In that model you don't choose the hostnames or priorities yourself — the provider gives you the exact MX values to publish, and you add them in your DNS host's control panel.

A typical setup might look like a single primary plus a backup, for example:

example.com. 3600 IN MX 10 mx1.example.com.
example.com. 3600 IN MX 20 mx2.example.com.

Enter the provider's values exactly — the hostnames, the preference numbers, and (where your host requires it) the trailing dot. Then layer on the SPF, DKIM, and DMARC TXT records the provider supplies so your outbound mail authenticates correctly.

When inbound mail misbehaves, it's usually one of these:

• Pointing MX at a CNAME. The exchange must be a real hostname with an A/AAAA record, never an alias.
• Using an IP address as the exchange. MX values are hostnames; the hostname is what carries the IP.
• Trailing-dot errors. In raw zone files a missing trailing dot can make mail.example.com become mail.example.com.example.com. Most hosted DNS panels add the dot for you — but check how yours behaves.
• Backwards priority. Remember lower = preferred. Putting 10 on the server you meant as a backup sends primary traffic to the wrong host.
• Missing records entirely. No MX (and no usable implicit A/AAAA) means senders have nowhere to deliver and mail bounces.
• Leftover MX from an old provider. After switching email hosts, delete the previous MX records so mail isn't routed to a service you no longer use.

You can see the live MX records for any domain with the who.is DNS lookup tool. Enter the domain and look at the MX section: it lists each exchange hostname alongside its preference value, so you can confirm the priorities are right, the targets are real hostnames (not IPs or CNAMEs), and no stale records remain.

It's also worth checking the related WHOIS and nameserver data to confirm you're editing DNS at the provider that's actually authoritative for the domain — otherwise your MX changes won't take effect.