MX Records Explained: Priority, Multiple Records and Common Mistakes

MX records tell the internet which mail servers accept email for your domain. They look simple, but a surprising number of deliverability issues start with an MX record that’s misconfigured, incomplete, or pointing at something that no longer exists.

What an MX record contains

yourdomain.com.   MX   10   mail1.yourdomain.com.
yourdomain.com.   MX   20   mail2.yourdomain.com.

Two parts matter: the priority (lower number = higher priority) and the hostname of the mail server. Sending servers always try the lowest-priority host first, falling back to higher-priority numbers only if the preferred host is unreachable.

Multiple MX records: why and how

Having a second (or third) MX record as a fallback is standard practice — if your primary mail server is down for maintenance or has an outage, mail queues at the sending server and retries the backup instead of bouncing immediately. Priorities don’t need to be sequential; 10 and 20 is just convention, leaving room to insert records later.

A common and valid pattern is multiple records at the same priority for load balancing — mail servers will pick between them, typically at random or round-robin.

Common MX mistakes

Pointing MX at an IP address

MX records must point to a hostname, never a bare IP address. This is invalid per the DNS spec and many mail servers will reject sending to it entirely.

The target hostname has no A/AAAA record

An MX record is only useful if the hostname it points to actually resolves. If mail1.yourdomain.com has an MX entry but no matching A record, mail delivery fails even though the MX record itself “looks” correct.

Only one MX record, no fallback

Fine for small setups, but any downtime on that single server means bounced mail with no retry path. Even a low-cost secondary MX pointed at a backup or relay service meaningfully reduces lost mail during outages.

Leftover MX records from a migrated provider

After switching email providers, old MX records sometimes linger — either still pointing at the previous provider (causing split delivery) or pointing nowhere. Audit MX records as a required step in any provider migration, not an afterthought.

Mismatched MX and SPF

If you use mx as a mechanism in your SPF record, every host listed in MX is implicitly authorized to send mail. Stale or incorrect MX records then leak into your SPF trust boundary too.

Checking your MX setup

dig MX yourdomain.com

Confirm every returned hostname also resolves (dig A hostname), confirm priorities make sense, and confirm you’re not accidentally missing a fallback. MXCorrect runs this exact check automatically, along with hostname resolvability, as part of a full domain scan.