TL;DR — An MX record is the DNS entry that tells the world which server accepts mail for your domain. It has a priority number (lower wins) and points at a hostname (never an IP, never a URL). Most domains need one or two. The classic failures are leftover records after a provider switch (split delivery), pointing MX at an IP, and confusing MX with the completely separate job of authorizing senders (SPF/DKIM/DMARC). Here's the whole thing.
What an MX record does
When anyone — a person, a bank, another mail server — sends mail to you@yourdomain.com, their server does one lookup: it asks DNS for your domain's MX records and connects to whatever hostname it finds. That's the entire job. MX is the sign on the door that says "deliver mail here."
yourdomain.com. IN MX 10 mx.yourprovider.com.
Three parts:
| Part | Meaning |
|---|---|
10 |
Priority — lower is preferred. Senders try the lowest number first. |
mx.yourprovider.com. |
Hostname of the receiving server. Must be a name, and that name must have its own A/AAAA record. |
| (the record's name) | The domain the mail is for — yourdomain.com, or a subdomain. |
Priorities and fallbacks
The number is only meaningful relative to your other MX records. These two:
yourdomain.com. MX 10 mx1.provider.com.
yourdomain.com. MX 20 mx2.provider.com.
mean "try mx1 first; if it's unreachable, try mx2." The specific values (10/20, or 1/2, or 5/10) don't matter — only their order does. Equal numbers mean "load-balance between these." For a typical hosted mailbox you'll have one or two records your provider gives you; you rarely invent the numbers yourself.
A subtlety worth knowing: the fallback is for your provider's redundancy, not yours. Pointing a low-priority MX at Provider A and a high-priority one at Provider B ("if A is down, B catches it") is a classic mistake — B then receives mail A knows nothing about, and you've built split delivery, not a backup. One provider, one or two of their MX hosts.
The rules that trip people up
MX points at a name, never an IP or a URL
WRONG yourdomain.com. MX 10 203.0.113.25 (an IP — invalid)
WRONG yourdomain.com. MX 10 https://mail.host.com (a URL — invalid)
RIGHT yourdomain.com. MX 10 mx.host.com. (a hostname — correct)
The MX target must be a hostname with its own A/AAAA record, and that name should not itself be a CNAME (the mail RFCs forbid it, and strict senders reject it). If your provider gives you an IP, you create an A record for a hostname pointing at it, then MX at the hostname — but hosted providers hand you a ready hostname; you almost never touch IPs.
Leftover MX records split your delivery
The single most common MX incident: you switch mail providers, add the new MX records, and forget to delete the old ones. Now your domain advertises both, senders are free to pick either, and roughly half your mail lands at the provider you thought you'd left — often an account you're about to close. After any MX change, confirm the record set contains only the new provider's hosts.
No MX? Mail tries the A record
If a domain has no MX record at all, senders fall back to its A record (the web-server IP) and try to deliver mail there — which usually fails or, worse, half-works. A domain that receives mail needs explicit MX records; never rely on the A-record fallback.
MX has nothing to do with sending
MX controls receiving. Whether your outbound mail is trusted is a completely separate question answered by SPF, DKIM and DMARC. Plenty of "my email is broken" reports are a receiving problem (MX) misdiagnosed as a sending one, or vice versa — knowing which record governs which direction saves hours.
The "no mail here" case
A domain you don't want receiving mail (a redirect-only domain, a parked one) can say so explicitly with a null MX:
yourdomain.com. IN MX 0 .
A single dot at priority 0 means "this domain accepts no mail" — senders stop immediately instead of timing out. Pair it with v=spf1 -all and a p=reject DMARC record and the domain is inert to both inbound mail and outbound forgery.
Checking your work
Any DNS lookup tool (or dig MX yourdomain.com / nslookup -type=mx yourdomain.com) shows your live MX set — check that it lists only your current provider's hosts, at sane priorities, as hostnames. Then send a message to the domain from an outside account; arrival in the right mailbox is the real confirmation. DNS changes propagate within minutes to hours depending on the record's TTL, so lower the TTL a day before a planned switch.
A typical setup
Most domains on a hosted provider need exactly what the provider hands you — usually one or two lines:
yourdomain.com. MX 10 mx1.yourprovider.com.
yourdomain.com. MX 20 mx2.yourprovider.com.
That's it. MX is the simplest of the mail records; it just has to be the only set pointing where you mean.
The rest of the series: SPF explained · DKIM explained · DMARC explained · the full picture in Email on Your Own Domain: The Complete 2026 Guide. On MailHow the MX (and every other) record is generated per domain and applied in one click through a connected registrar.