What is an MX record? (and why a wrong one loses mail)

The one-sentence version

An MX (mail exchanger) record tells every other mail server on the internet where to deliver email addressed to your domain. It is the inbound side of email: not who you are allowed to send as (that is SPF, DKIM, and DMARC), but where mail to you should land.

What an MX record looks like

An MX record has two parts: a preference number and an exchange hostname. The hostname is the server that accepts your mail; the preference number sets the order when you have more than one:

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

Lower preference means higher priority. Senders try the lowest number first (here, mail.example.com at 10), and fall back to the next one only if it cannot connect. When two records share the same preference, senders pick between them in random order, which is how mail gets spread across equally-ranked servers.

The rules that bite

MX looks simple, but three rules cause most of the real-world breakage, and all three fail quietly:

• The target must be a hostname, never an IP, and never a CNAME. The exchange field is a domain name that must resolve to an A or AAAA record. Putting a bare IP address there is invalid, and pointing it at a CNAME is forbidden by the DNS clarifications standard (RFC 2181). The cruel part is that a CNAME target sometimes appears to work, then breaks on stricter receivers, so the fault hides until some of your mail starts failing.
• No MX is not the same as a null MX. If a domain publishes no MX record at all, a sender falls back to the domain's own A or AAAA record and tries to deliver there. That “implicit MX” is a fallback, not a feature: it usually lands on a web server that cannot receive mail. If your domain genuinely sends and receives no email, publish a null MX instead, a single record with preference 0 and a . as the exchange, which tells senders to stop immediately rather than queue and retry:

  example.com.   3600   IN   MX   0   .

• Stale MX after switching providers. The most common modern failure is not a missing MX, it is an old one. Move your mailboxes to a new provider and forget to update MX, and mail keeps flowing to the old host, where nobody is reading it.

Wrong MX versus missing MX

It is worth being precise, because the two failures look different:

• A wrong MX (a typo, a hostname with no address record, a CNAME target, a stale provider) drops or misroutes your inbound mail.
• A missing MX may not drop mail at all. It silently falls back to your website's server, which almost never accepts mail, so messages bounce or vanish there instead.

Either way, the symptom is the same and it is the dangerous part: nothing on your side visibly fails. Unlike a down website, an inbound-mail fault produces no error you will see. You find out when a customer says “I emailed you last week and never heard back.”

MX is inbound only

A frequent mix-up: MX has nothing to do with whether your outbound mail is trusted. MX governs where mail to you is delivered. Whether mailbox providers accept mail from you is decided by SPF, DKIM, and DMARC, which are separate records doing a separate job. See what DMARC is for that side.

The one technical link is the SPF mx mechanism, which authorizes the IP addresses of your MX hosts to send for you. It is optional and increasingly discouraged, because it costs one of your ten allotted SPF DNS lookups and most domains do not send from their inbound mail servers anyway.

How to check yours

MX faults are invisible until they hurt, so verify rather than assume:

• Query it directly: dig MX example.com +short returns exactly the preference-and-hostname list other servers will use.
• Confirm each exchange hostname resolves: dig A mail.example.com +short should return an IP, not nothing and not a CNAME.
• Run a full domain audit to see your MX alongside the SPF, DKIM, and DMARC records that decide your outbound trust.

Common questions

Does my MX record affect SPF or DMARC?

Not directly. MX is inbound routing; SPF, DKIM, and DMARC are outbound authentication. The only overlap is the optional SPF mx mechanism, which references your MX hosts when authorizing senders.

Can an MX record point to a CNAME?

No. The exchange must be a hostname with its own A or AAAA address record. Pointing MX at a CNAME is prohibited by RFC 2181 and breaks on strict receivers, even when it seems to work at first.

What is a null MX record?

A single MX with preference 0 and . as the exchange. It declares that the domain accepts no mail, so senders fail fast instead of queuing. It is the right record for parked or send-only domains, and pairs well with a strict v=spf1 -all to harden a non-mailing domain against spoofing.