MX Record: syntax, examples, and troubleshooting

What does an MX record do?

MX is record type 15, defined in RFC 1035 and refined by RFC 5321 and RFC 7505. It exists because the host that receives your mail is usually not the host that serves your website. When an MTA has a message for [email protected], it queries example.com for MX, gets back a list of hostnames with preference numbers, resolves those hostnames to addresses, and opens an SMTP connection.

If no MX records exist, RFC 5321 says the sender falls back to the domain's A or AAAA records — the "implicit MX" rule. That fallback is why a domain with a web server and no MX records will have connection attempts on port 25 hitting the web server, and why mail sometimes appears to "half work" after a bad DNS change.

MX syntax and fields

How preference actually works

The sending MTA sorts all MX records by preference ascending and attempts them in that order, moving to the next only when the current one fails to accept the message — connection refused, timeout, or a 4xx temporary rejection. A 5xx permanent rejection ends the delivery attempt; it does not cause a fallthrough to the next MX.

• Lower number = higher priority. 10 is tried before 20. This inversion catches people constantly.
• Equal preference means load sharing. Records with the same value are tried in random order, spreading load across a pool. Five servers all at preference 10 is a normal, healthy configuration.
• The absolute values are meaningless. 1, 5, 10 behaves identically to 10, 20, 30. Only relative ordering matters. Conventional spacing by tens just leaves room to insert a server later.
• A backup MX must be able to deliver onward. A "backup" that accepts mail and cannot relay it to the primary is a mail black hole, and one that accepts for unknown recipients turns into a backscatter source. Modern practice at most shops is to skip backup MX entirely — sending MTAs already queue and retry for days.

For a fuller treatment including multi-provider setups, see MX priority explained.

Null MX: saying "this domain sends no mail"

RFC 7505 defines a null MX: a single MX record with preference 0 and an exchange of . (the root). It is an explicit statement that the domain accepts no mail. A sender that sees it can reject immediately with a permanent error instead of queueing and retrying for days.

; Zone file
example.com.    IN  MX  0 .

; What dig shows
example.com.    162  IN  MX  0 .

Publish a null MX on parked domains, on domains used only for outbound transactional sending, and on subdomains that should never receive mail. Two rules: it must be the only MX record in the set, and it should be paired with an SPF record of v=spf1 -all and a DMARC record at _dmarc with p=reject so the domain is fully locked down for both directions. The DMARC generator and SPF generator will build those.

MX targets must be hostnames

The exchange field is a domain name, and RFC 2181 is explicit that it must not be an alias. Two hard rules follow:

• Never an IP address. MX 10 203.0.113.25 is invalid. Some provider UIs accept it and produce a record that resolves to 203.0.113.25.example.com, which is NXDOMAIN. Create a hostname like mail.example.com with an A record and point the MX at that.
• Never a CNAME. If mail.example.com is a CNAME, some senders will chase it and others will treat the MX as broken. The result is mail that arrives from some sources and not others — one of the worst failure modes to diagnose.
• The target needs address records. An MX pointing at a hostname with no A or AAAA record is a lookup that succeeds and a delivery that cannot happen.
• Use a name in a zone you control or your provider's own name. Pointing MX at a third party's hostname you have no relationship with does not make them accept your mail.

TTL guidance

MX records are among the safest to give a long TTL — 3600 to 14400 is common, and a long TTL means that if your DNS provider has a partial outage, senders keep using cached MX data rather than queueing. Drop to 300 for 24–48 hours before a mail platform migration, complete the cutover, verify inbound delivery from an external address, then raise it back. Because senders queue and retry for days, an MX misconfiguration is usually recoverable — but only if you notice it before the retry windows expire.

Mistakes engineers make with MX

• Inverting the priority. Putting the primary at 20 and the backup at 10 sends all mail to the backup. It often still "works", which is why it survives for months.
• Leaving the old provider's MX in place during a migration. Two providers at different preferences means mail splits across both mailstores. Delete the old records in the same change, not later.
• Adding MX records to `www`. Mail is addressed to [email protected], so the MX belongs at the apex. An MX at www.example.com only matters for mail to [email protected].
• Trailing-dot errors. In a raw zone file, smtp.google.com without the dot becomes smtp.google.com.example.com..
• Assuming MX changes fix authentication. MX governs inbound mail. Outbound reputation is SPF, DKIM, DMARC, and PTR. Changing MX does nothing for a 550 5.7.x rejection — see mail bouncing after a DNS change.
• Forgetting subdomains. example.com having MX records does not give sub.example.com mail service. Each mail-receiving name needs its own MX (or a null MX to say it receives none).

Check it with dig

# Preference and exchange for a domain
dig +short google.com MX

# Full answer with TTL
dig +noall +answer github.com MX

# Confirm the exchange actually has address records
dig +short smtp.google.com A
dig +short smtp.google.com AAAA

# Make sure the exchange is NOT a CNAME (should be empty)
dig +short smtp.google.com CNAME

# Ask the authoritative servers directly
dig +noall +answer @ns1.google.com google.com MX

# A null MX looks like this
dig +short example.com MX

Once MX is correct, confirm the server is actually reachable with the SMTP connection test, check reverse DNS on the sending IP with the reverse DNS lookup, and run the full deliverability test for SPF, DKIM, and DMARC together.