In an MX record, is a lower or higher priority number preferred?

Lower wins. The number in front of an MX hostname is a preference value, and a sending mail server tries the lowest one first. 'MX 10 mail1.example.com' is your primary; 'MX 20 mail2.example.com' is only tried if the primary refuses or times out. This trips people up because 'priority' in everyday speech means 'higher is more important,' but MX preference is the opposite — think of it as a ranking where #1 comes before #2. If you set your real mail server to 20 and a leftover host to 10, every message goes to the wrong box first.

What happens if two MX records have the same priority number?

They share the load. RFC 5321 §5.1 says that when several MX records carry the same preference value, the sender SHOULD pick among them in a roughly random order — so two hosts both at preference 10 will each receive about half your inbound mail over time. That's how you spread load across a pair of equal servers. It is also a quiet failure mode: if one of two equal-preference hosts is broken but still answers on port 25 with rejections, half your mail bounces and half gets through, with no pattern the sender can see. Equal preference means 'both of these are equally valid destinations,' so only list hosts there that can actually accept mail.

Can an MX record point to a CNAME or an IP address?

Neither. An MX target must be a hostname that has its own A or AAAA record — RFC 2181 §10.3 explicitly forbids pointing an MX at a CNAME alias, and the MX syntax has no room for a raw IP address at all. Both mistakes produce the same intermittent delivery: some sending servers tolerate the broken target, most reject it. If your mail host only has a CNAME (common when a provider hands you 'mail.theirservice.com' as an alias), publish the MX pointing at a name that resolves directly to an address, or use the exact hostname your provider tells you to.

MX Record Setup and Check: Priority and Failover

What You’re Setting Up

An MX (Mail eXchanger) record is the single line of DNS that tells every mail server on the internet where to deliver mail for your domain. Get it right once and it’s invisible for years. Get one number or one hostname wrong and mail fails in ways that look like anything except a DNS problem — intermittent bounces, messages that arrive for some senders but not others, delivery that worked yesterday and stopped after a migration. This is the guide for when you’re adding, changing, or double-checking an MX and want to confirm it’s actually correct before you walk away.

The Two Parts of an MX Record

Every MX record has exactly two fields, and both cause trouble:

example.com.   3600   IN   MX   10   mail.example.com.
                              │    │
                         preference  target hostname

Preference — a number where lower is preferred. The sender tries your lowest-numbered host first. This is the field people invert.
Target — a hostname that must resolve to an A or AAAA record. Not a CNAME, not an IP address, not a name that resolves to nothing.

The gap between “the record exists” and “the record works” lives entirely in those two fields.

Setting Preference: Primary and Backup

If you run a single mail server, you need one MX record and the preference number barely matters — 10 is the convention, but 5 or 50 behaves identically when there’s nothing to compare it to. The number only means something relative to other MX records.

Backups are where it gets interesting. A second MX at a higher number (say 20) is a fallback: when your primary is down, senders queue against the backup instead. But a backup MX is only useful if it actually knows how to hold and forward your mail to the primary once it’s back — and here’s the part most guides skip: a backup MX that doesn’t know your list of valid mailboxes is a liability, not a safety net. It accepts mail addressed to anyone, can’t deliver the invalid ones, and then generates bounces to forged senders — backscatter that gets your backup listed on blocklists. Spammers actively target backup MX hosts precisely because they tend to be less strict than the primary. Unless your backup does full recipient verification, you’re usually better off with no backup MX at all and letting sending servers do what SMTP already guarantees: queue and retry for days.

Equal preference is the other pattern. Two hosts both at 10 split incoming mail between them — genuine load sharing, and the right choice when you have two servers that are equally capable of accepting mail. Just don’t mix the ideas up: equal numbers mean “both are live,” not “one is a spare.”

The Split-MX Trap

The single most destructive MX mistake happens during a mail migration, and it’s almost never diagnosed as an MX problem. You’re moving from an old provider to a new one. You add the new provider’s MX. You forget to remove the old one. Now your domain publishes two MX records — old and new — and every sending server on the internet gets to choose which one to deliver to based on the preference numbers and its own retry logic.

The result is mail that splits, seemingly at random, between two systems. Some messages land in the new mailbox, some land in the old one nobody’s watching, and the pattern shifts as caches expire. Users swear mail is “disappearing.” It isn’t — it’s arriving, just at an inbox that was supposed to be dead. The fix is boring: during a migration, the old MX comes down the moment the new one is verified working, not “eventually.”

Diagnose with DechoNet

Email Check reads your domain’s MX records exactly the way a sending server does — showing every MX, its preference number, and whether the target hostname resolves — so you can spot a backwards preference, a leftover split-MX record, or a target that goes nowhere in one pass, alongside your SPF and DMARC status.
DNS Check lets you resolve an MX target on its own. When Email Check shows an MX but you want to confirm the host behind it is real, query that hostname’s A/AAAA record here — an empty result or a CNAME at that name is your problem.

Verification Checklist

Confirm the record is published and readable: dig MX example.com +short. You should see your preference number and target hostname, and nothing you didn’t add.
Check for leftovers. If more than one MX shows up and you only meant to have one, an old record is still live — that’s a split-MX waiting to lose mail.
Verify the target resolves to an address, not an alias: dig A mail.example.com +short must return an IP directly, never a CNAME.
Confirm the MX is on the exact name people mail. The record must sit on example.com if addresses are @example.com — an MX on mail.example.com does nothing for mail sent to the apex.
Sanity-check preference order: your real primary must have the lowest number. Lower is tried first.
Wait out the old record’s TTL before declaring victory. Until the previous answer’s TTL expires, sending servers may still hold the old MX in cache — retest after the TTL window, not immediately.

When It’s Not the MX

If dig MX shows the correct record, the target resolves to the right IP, the preference is sane, and mail still doesn’t arrive, DNS has done its job and the problem has moved downstream: nothing is listening on port 25 at that host, the mail server is rejecting connections, or a firewall is dropping inbound SMTP. That’s a mail-server or network question for whoever runs the receiving host — the MX record is only the signpost, not the mailbox.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.