MX Records and Email Deliverability, Explained

Every email address has two halves: the local part before the @, and the domain after it. When something tries to deliver a message to you@example.com, it doesn't magically know which server handles mail for example.com. It has to look that up in DNS — specifically, in the domain's MX records. If those records are missing or broken, mail has nowhere to go, and messages bounce before they ever reach an inbox.

This guide explains what MX records are, how mail routing through DNS actually works, how to check a domain's MX records yourself, and why MX is the single most important signal for deciding whether a domain can receive email at all.

What is an MX record?

MX stands for Mail Exchanger. An MX record is a DNS entry that names the mail server responsible for accepting email on behalf of a domain. It's how the sending side finds out where to deliver a message.

Each MX record has two parts:

• A priority (preference) number — a lower number means higher priority. Senders try the lowest-numbered host first.
• A hostname — the mail server that accepts messages, such as aspmx.l.google.com.

A domain can list several MX records. That's normal and healthy: the extra hosts act as fallbacks. If the primary server is unreachable, the sender moves on to the next-lowest priority and tries again.

A typical MX setup

A domain using Google Workspace might publish records that look roughly like this:

Priority	Mail host
1	aspmx.l.google.com
5	alt1.aspmx.l.google.com
10	alt2.aspmx.l.google.com

The sender tries priority 1 first. If that host is down, it falls back to priority 5, then 10. The domain owner controls all of this by editing DNS at their registrar or DNS provider.

How mail routing through DNS works

When a message is sent, the delivering server runs through a short sequence:

1. Split the address at the @ to isolate the domain.
2. Query DNS for that domain's MX records.
3. Sort the returned hosts by priority, lowest first.
4. Resolve the chosen host's IP address (its A or AAAA record) and open an SMTP connection.
5. Hand off the message. If a host refuses or times out, move to the next one.

There's one useful edge case worth knowing. If a domain has no MX record but does have an A record, the standard says senders may fall back to delivering mail to that address directly. In practice this is rare and unreliable — most legitimate mail-receiving domains publish explicit MX records, and treating a bare A record as mailable is a weak assumption.

How to check a domain's MX records

You don't need special tooling to inspect MX records — every operating system ships with a DNS lookup command.

From the command line

• dig (macOS, Linux): dig MX example.com +short
• host (macOS, Linux): host -t MX example.com
• nslookup (Windows): nslookup -type=MX example.com

Each returns the priority numbers and mail hosts. If the command returns nothing, the domain has no MX records — a strong sign it can't receive email.

In a browser

If you just want to eyeball one domain without a terminal, our MX record checker looks up a domain's mail servers and tells you at a glance whether they're present and resolvable.

What missing or misconfigured MX records mean

MX problems fall into a few recognizable buckets, and each has a different consequence for deliverability.

Situation	What it means
No MX records at all	The domain isn't set up to receive email. Mail to it will typically bounce.
MX host doesn't resolve	The record exists but points to a hostname with no valid IP — delivery fails.
Typo in the mail host	Mail is routed to the wrong (or nonexistent) server. A classic cause of silent delivery failures.
MX points to your own domain by mistake	Creates loops or refusals if that host isn't actually running a mail service.

A domain with healthy MX records isn't a guarantee that a specific mailbox exists — the address could still be a typo or a closed account. But the reverse is close to absolute: a domain with no working MX has almost no chance of accepting mail.

How MX fits into email verification

MX is one of several layers a good verifier checks. Syntax validation confirms an address is well-formed; MX and DNS checks confirm the domain can plausibly receive mail; further checks look at disposable domains, role accounts, catch-all behavior, and an SMTP mailbox probe that talks to the mail server without ever sending a message. That probe is not a paid tier: it runs wherever the receiving side allows it, and is skipped only when there is no mail server to talk to, when the provider refuses verification probes outright, or when that domain has been probed too often in the last minute.

Because MX is fast and cheap to check, it's an efficient first filter. A verification result carries a reason that surfaces exactly this: a domain with no mail server comes back with no_mx and lands on the undeliverable side of the score, while a domain with working mail servers proceeds to deeper checks. Working MX alone is deliberately not enough for a deliverable verdict — an unconfirmed mailbox stays risky with reason mailbox_unconfirmed, and only a live SMTP check that confirms the mailbox yields deliverable with mailbox_exists. Results resolve to deliverable, risky, undeliverable, or unknown, with a 0–100 score behind them.

MX tells you whether a domain can receive mail. The remaining checks tell you whether a specific address is worth trusting.

If you want to run these checks without wiring anything up, the free email verifier validates a single address in the browser, MX included. To automate it, the verification API returns the same signals — result, score, reason, and a per-check breakdown — in a single synchronous JSON response, so you can gate signups or clean records in your own code.

Putting it into practice

If you send email to a list, treat MX as your baseline gate. Verify addresses at the point of capture so domains with no mail server never enter your list, and re-check older lists periodically, since domains do get abandoned and their MX records removed. For anything beyond a handful of addresses, batch it: our bulk verification runs the full check set across a CSV and hands back a clean, deliverable-only export.

MX records are a small piece of DNS with an outsized effect on whether your mail arrives. Understanding them — and checking them before you hit send — is one of the cheapest deliverability wins available. For the bigger picture, see what email verification checks and the email verification API guide.