What is an MX record?

A DNS record that tells the world which mail servers accept email for your domain, and in what priority order. Every mail-receiving domain needs at least one.

How does MX priority work?

The number before the hostname is the preference. Lower numbers are tried first. So MX 10 mx1 and MX 20 mx2 means senders try mx1 first and fall back to mx2 only if mx1 is unreachable.

An MX record of the form '0 .' (priority zero, target of a single dot) that explicitly declares 'this domain does not receive mail.' It's defined in RFC 7505 and lets senders reject mail addressed to non-mail domains immediately instead of retrying for days.

Can I use an A record instead of MX?

Yes — RFC 5321 allows a fallback to the domain's A/AAAA record if no MX exists. But this is fragile and it prevents you from using different hosts for HTTP and mail. Always publish an explicit MX.

Should MX targets be A records or CNAMEs?

A records. RFC 2181 forbids MX targets from pointing at CNAMEs. Most mail servers will fail closed on a CNAME'd MX target. Point MX at a hostname that resolves directly to A/AAAA records.

How many MX records should I have?

At minimum two, ideally in different network locations. Most cloud email providers (Google Workspace, Microsoft 365) publish four or five for redundancy. You inherit their MX set when you configure their service.

MX Records Explained: How Email Actually Finds Your Server

Every time someone anywhere in the world types you@yourdomain.com and hits send, their mail server does one thing before doing anything else: it asks DNS "which servers accept mail for yourdomain.com?" The answer comes back as a set of MX (Mail Exchanger) records — an ordered list of hostnames with priorities. Get MX right and your mail arrives. Get it wrong and thousands of legitimate messages queue up on senders' retry timers for days before finally bouncing.

What an MX record looks like

yourdomain.com.  IN  MX  10  aspmx.l.google.com.
yourdomain.com.  IN  MX  20  alt1.aspmx.l.google.com.
yourdomain.com.  IN  MX  20  alt2.aspmx.l.google.com.
yourdomain.com.  IN  MX  30  alt3.aspmx.l.google.com.
yourdomain.com.  IN  MX  30  alt4.aspmx.l.google.com.

Two things to read from that. First, the number is the preference. Lower is tried first — think of it as a nice-value, not a rank. Second, when two records share a preference (both 20), the sender load-balances across them, typically at random.

The sending algorithm

An RFC-compliant sending MTA does roughly this when delivering to yourdomain.com:

Query MX for yourdomain.com.
Sort the results by preference ascending.
Within each preference group, randomize order.
Try to open SMTP on port 25 to the first host. If it accepts and delivers, done.
On temporary failure (4xx SMTP or TCP refused), queue and retry later per the sender's schedule — often for 3-5 days.
On MX list exhaustion with only temporary failures, keep retrying with backoff.
On permanent failure (5xx), bounce to the original sender.

The important nuance: fallback happens when a higher-priority MX is unreachable, not when it merely refuses a specific message. If mx1 answers on port 25 and returns "550 recipient unknown," the sender bounces immediately. It will not try mx2.

Priority patterns real teams use

All-equal (cloud pattern). Google Workspace and Microsoft 365 publish MX sets where the equal-priority group covers geographically distributed servers. The sender's random load-balance produces even distribution.
Primary + backup. On-prem: MX 10 mail.yourdomain.com for the main server, MX 20 backup.yourdomain.com for a queue-only host that spools mail during outages. Backup MXes have gone out of fashion because they're a phishing/spam vector unless carefully configured.
Gateway pattern. A cloud filtering service (Proofpoint, Mimecast, Cisco Ironport) is listed as your only MX; it filters and then delivers to your real mailboxes via a private handoff. Your real mail servers should not appear in MX at all.

The null MX — a small record with a big job

If your domain does not receive mail at all — an API-only subdomain, a personal apex you use only for HTTPS redirects — publish a null MX per RFC 7505:

api.yourdomain.com.  IN  MX  0  .

That single dot is the null target. Senders read it as "this domain has affirmatively said it doesn't take mail" and reject immediately with a 5xx bounce. Without a null MX, mail addressed to non-existent domains queues on senders for days, and any typo like you@api.yourdomain.com silently generates a mailer-daemon reply five days later.

Common misconfigurations

MX pointing at a CNAME. RFC 2181 forbids this. Most MTAs will fail closed. Always point MX at a name with A/AAAA records.
MX pointing at an IP literal. RFC 5321 forbids this. Use a hostname.
MX pointing at your website. The MX target must be a mail server that speaks SMTP. Your web CDN does not.
No MX at all. Senders will fall back to your A record per RFC 5321. That works, but it couples your web and mail hosting together and makes filtering-service migrations painful.
Trailing dots. In zone files, MX targets need a trailing dot: mail.yourdomain.com. Without it, some management UIs will append the zone origin — turning mail.yourdomain.com into mail.yourdomain.com.yourdomain.com. Always verify with dig after editing.

MX and your email deliverability posture

MX gets inbound mail to the right place. It doesn't do anything for outbound authentication — that's SPF, DKIM, and DMARC (see our SPF, DKIM, and DMARC guides). But your MX targets do factor into deliverability indirectly: some receivers penalize senders whose PTR (reverse DNS) doesn't match the HELO name, and the HELO name is usually derived from the MX target. Consistent forward-and-reverse DNS on your mail servers is one of the oldest and still-relevant deliverability signals.

Testing your MX

# Show the full MX set with priorities
dig +short MX yourdomain.com

# Verify each target resolves to an IP
dig +short aspmx.l.google.com

# End-to-end delivery test — telnet to port 25
telnet aspmx.l.google.com 25
# Expect: 220 mx.google.com ESMTP

For a friendlier view, our MX Lookup shows priorities, resolves each target to IPs, and flags common misconfigurations. The Email Provider Detector tells you at a glance whether a domain is on Google, Microsoft, Zoho, Fastmail, or self-hosted.

Related tools: MX Lookup · Email Provider Detector · IP Blacklist Checker

MX records — how email finds your servers