MX Record

An MX (Mail Exchanger) record is the DNS record that tells a sending server which hosts accept mail for a domain, and in which order to try them. It is the first lookup in every delivery attempt: before a message can be sent to someone@example.com, the sending server has to ask what handles mail for example.com.

$ dig +short MX example.com
10 mx1.example.net.
20 mx2.example.net.

How is the priority interpreted?

The number is a preference, and lower wins. A sending server tries priority 10 first and falls back to 20 only if the first is unreachable. Equal priorities are used round-robin, which spreads load rather than providing fallback.

This is how email achieves redundancy without anycast: several independent, separately addressed mail transfer agents, with the sending server choosing between them and retrying on failure. The resilience lives in the protocol rather than in the routing table.

A secondary MX is only useful if it can actually deliver onward and knows which recipients exist. A backup that accepts everything and discovers later that the address is invalid becomes a backscatter source, which is why unmaintained secondary MX hosts are a favourite target for spammers.

What if a domain has no MX record?

The sending server falls back to the domain’s A or AAAA record and attempts delivery there. This implicit fallback still works, but relying on it is fragile: it couples your mail routing to wherever your website happens to be hosted.

If a domain should never receive mail, say so explicitly with a null MX (RFC 7505):

example.com.  3600  IN  MX  0 .

A single dot as the target, at priority 0, tells senders to reject immediately rather than queue and retry for five days. This belongs on every domain you own that only exists for redirects, or for brand protection.

What are the common MX mistakes?

Pointing an MX at a CNAME. Not permitted — the target of an MX record must be a hostname with an A or AAAA record. Some senders tolerate it, others do not, and the failures are intermittent and hard to trace.
Using an IP address as the target. Also invalid. The value must be a hostname.
A missing trailing dot in a zone file, turning mx1.example.net into mx1.example.net.example.com.
An MX host with no matching PTR record. Inbound delivery still works, but the same host sending outbound will fail the forward-confirmed reverse DNS check described under hostname.
Forgetting the secondary after a migration, leaving an old server listed that still accepts mail and silently drops it.

How do MX lookups show up in mail logs?

A failed MX lookup is one of the most common reasons a message sits in the queue:

(Host or domain name not found. Name service error for name=gsmail.com
type=MX: Host not found, try again)

That is a temporary DNS failure, so the message is deferred rather than bounced — the recipient domain may be misspelled, or its DNS may genuinely be down. If many unrelated destinations show this at once, the problem is your own resolver rather than theirs.

How do you check your MX setup?

$ dig +short MX example.com
10 mx1.example.net.

$ dig +short A mx1.example.net
192.0.2.25

$ dig -x 192.0.2.25 +short
mx1.example.net.

All three should agree: the MX names a host, the host resolves to an address, and the address resolves back to the same name. Then confirm the host actually answers on port 25 — an MX record pointing at a machine that no longer runs an SMTP service defers every message sent to the domain for five days before anyone finds out.

Manage Postfix mail server queues like a pro — where a failed MX lookup ends up, and how to inspect it.
Monitoring Postfix email queue and add push notifications — alerting on the queue growth a broken MX record causes.