MX record: how DNS routes email to the right server
MX record (Mail Exchange record) is a DNS record type that tells a sending server where to deliver mail for a given domain. When an MTA wants to send a message to user@example.com, it queries the MX records for example.com and gets back the hostname of the server that accepts inbound mail.
MX record structure
Each MX record has two fields: a priority number (called preference in the RFC) and a hostname. The priority is an unsigned integer from 0 to 65535. Lower numbers are tried first.
example.com. IN MX 10 mail1.example.com.
example.com. IN MX 20 mail2.example.com.
example.com. IN MX 30 mail3.backup.com.
In this example, the sending MTA tries mail1.example.com first (priority 10). If that server is unreachable, it falls back to mail2.example.com (20), then to the backup at mail3.backup.com (30).
Equal priorities and load distribution
When two MX records share the same priority, the sending MTA picks between them at random. That gives a rough 50/50 split:
example.com. IN MX 10 mail1.example.com.
example.com. IN MX 10 mail2.example.com.
This is not round-robin DNS, so the distribution is not exact. For most mail volumes it works well enough without any special configuration on the receiving side.
MX, A records, and delivery
An MX record points to a hostname, not an IP address. Each hostname in an MX record must have a corresponding A record (or AAAA for IPv6) that resolves it to an IP.
If a domain has no MX records at all, RFC 5321 allows the sending MTA to fall back to the domain's A record and attempt delivery there directly. In practice this is unreliable: not all MTAs implement the fallback, and many domains have a web server at their A record with no mail daemon listening on port 25.
Null MX
If a domain does not accept email at all, the correct way to say so is a null MX record, defined in RFC 7505:
example.com. IN MX 0 .
The dot instead of a hostname means “this domain accepts no mail.” An MTA that supports RFC 7505 returns a permanent error to the sender immediately, skipping any delivery attempt. That is cleaner than publishing no MX records: the intent is explicit, and compliant senders stop retrying right away.
Common misconfigurations
- MX points to a CNAME. RFC 2181 prohibits this. An MX record must reference an A record directly, not an alias. Some servers handle it anyway, but the behavior is not guaranteed.
- MX contains an IP address. The hostname field must be a domain name, not an IP. A record like “MX 10 192.168.1.1” is invalid.
- No A record for the MX hostname. MX points to mail.example.com, but no A record exists for that name. Mail cannot be delivered.
- Backup MX with no mail server behind it. A lower-priority MX is listed, but the host at that address has not been configured to accept mail for the domain. When the primary server goes down, inbound messages get accepted and then silently dropped.
MX records in email validation
Checking MX records is one of the first steps in email address validation. If a domain has no MX records and no usable A record fallback, delivery is impossible. Any address on that domain is guaranteed invalid.
Beyond presence, a validator also checks whether the named host resolves to an IP and whether it responds on port 25. This filters out domains with “dead” MX records: technically present in DNS but pointing at servers that no longer exist or no longer accept mail.
For bulk lists, the MX check saves real resources. There is no point opening an SMTP connection to a domain whose mail infrastructure was never configured or has been decommissioned.
uChecker checks MX records for every domain in your list. Missing MX, an unreachable server, null MX — all of it is detected automatically before any SMTP verification attempt.