Infrastructure

MX RecordMail Exchanger Record

Definition

An MX record (Mail Exchanger record) is the DNS entry that tells other servers which mail servers accept email for your domain, and in what order to try them. Each record pairs a preference number with a server hostname, and the lowest number wins. Defined in RFC 5321, it is the record a sending server looks up first, before any SMTP connection is made.

  • Points a domain to the mail servers that accept its incoming email
  • Lower preference numbers are tried first; they are higher priority
  • It must point to a hostname with an A or AAAA record, never a CNAME
  • Multiple records give you failover across backup mail servers
At a glance
Record type DNS MX (Mail Exchanger)
Defined in RFC 5321 (2008)
Format preference hostname
Priority rule Lowest number is tried first
Target A hostname with an A/AAAA record
Must not be An IP address or a CNAME

How MX records route mail

When a server has mail for you@example.com, the first thing it does is look up the MX records for example.com. The answer is one or more lines, each with a preference value and a mail-server hostname. The sending server sorts them by preference, lowest first, and opens an SMTP connection to that host. If it cannot connect, it falls through to the next-lowest preference, which is exactly how backup mail servers work.

The preference number trips people up because it runs backwards from intuition: a record with preference 10 is tried before one with preference 20. Lower means higher priority. If two records share the same preference, the sender picks between them at random, spreading load across equal servers.

A primary mail server at preference 10, with a backup at 20 
example.com.   3600   IN   MX   10 mail.example.com.
example.com.   3600   IN   MX   20 backup.example.com.

The rule that breaks mail: no CNAME, no IP

An MX record must point to a hostname that has its own A or AAAA record. Two things it must not point to:

  • An IP address. MX 10 203.0.113.10 is invalid. The target is always a name, never a raw IP.
  • A CNAME alias. RFC 5321 requires the MX target to resolve directly to address records, and the DNS specs forbid aiming it at a CNAME. Strict receivers will reject mail when you do.

This is one of the most common quiet misconfigurations: the domain looks fine, mail mostly flows, then one strict receiver bounces everything because the MX points at a CNAME. Always target a real hostname with an A or AAAA record, and confirm it with an MX lookup.

MX records and deliverability

MX records govern inbound mail, the messages other people send to you, so they are not part of your outbound authentication. But they matter for reputation in two ways. First, a domain with no MX record (or one pointing at a dead host) cannot receive replies, bounces, or the verification mail that many sign-up and feedback systems send, which makes the domain look abandoned. Second, some receivers and anti-spam systems treat a sending domain that has no working MX as a weak signal, since a legitimate domain almost always accepts mail back.

The practical takeaway: keep your MX records pointed at live, correctly configured servers, list a backup if you can, and verify them whenever you change mail providers. A broken MX is invisible until someone tries to reply to you.

How a server uses your MX records

A sender has mail for you@example.com
It looks up the MX records for example.com
It sorts them by preference, lowest number first
MX 10 mail.example.com MX 20 backup.example.com
It resolves the chosen hostname’s A/AAAA record to an IP
It opens an SMTP connection and delivers, falling back to the backup if needed

Valid vs invalid MX targets

Valid Invalid
Target A hostname with an A/AAAA record A raw IP address or a CNAME
Example 10 mail.example.com. 10 203.0.113.10
Spec Meets RFC 5321 Breaks RFC 5321 / RFC 2181
Result Mail is accepted Strict receivers reject mail

By the numbers

Lowest
The preference value that is tried first. Lower number means higher priority.
RFC 5321
The current SMTP specification that defines how MX records are looked up and used.
0
The number of CNAMEs an MX record may legally point to; the target must be a real host.

Common mistakes

Reading the priority backwards
Lower preference numbers are tried first, not last. An MX at 10 is the primary; 20 is the backup. Setting your main server to a high number quietly demotes it.
Pointing the MX at a CNAME
RFC 5321 requires the target to resolve directly to A or AAAA records. Aiming the MX at a CNAME alias is invalid and breaks delivery on strict receivers.
Pointing the MX at an IP address
The MX value is always a hostname, never a raw IP. To use a specific server you publish its hostname and give that hostname its own A or AAAA record.
No backup MX, then the primary goes down
With a single MX, an outage on that host means senders keep retrying until they give up. A second record at a higher preference catches mail while the primary recovers.

Frequently asked questions

What does a lower MX number mean?
A lower preference number means higher priority. Senders try the lowest-numbered MX record first, and only fall through to higher numbers if it cannot connect. So MX 10 is your primary server and MX 20 is a backup.
Can an MX record point to an IP address?
No. An MX record must point to a hostname, and that hostname must have its own A or AAAA record. Pointing it at a raw IP address or a CNAME alias is invalid under RFC 5321 and causes delivery failures on strict receivers.
Do I need an MX record to send email?
MX records control incoming mail, so they are not strictly required to send. But a domain with no working MX cannot receive replies or bounces, and some receivers treat a sending domain with no MX as a weak trust signal. Keeping a valid MX is good practice for any sending domain.
How do I check my MX records?
Run a DNS query for the MX type, or use our MX lookup tool, which lists every mail server for a domain along with its preference value so you can confirm the order and targets are correct.
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← Back to glossary