Before a single message reaches your inbox, the sending server has to ask one question: where does mail for this domain go? The answer lives in the domain’s MX records. Get them wrong — a typo in a hostname, a stale server that no longer resolves, a missing record entirely — and mail either bounces or vanishes into a black hole, usually with no obvious clue as to why. An MX lookup is the fastest way to see exactly what the rest of the internet sees when it tries to deliver to you.
What an MX record actually is
An MX (Mail eXchange) record is a DNS entry that names the hostname of a mail server responsible for accepting email for a domain. Crucially, it points to a name, not an IP — so example.com might have an MX of mail.example.com, and that hostname has its own A/AAAA records that resolve to the actual IPs. A domain can publish several MX records for redundancy, and each carries a priority value. The behaviour is spelled out in RFC 5321, the core SMTP specification.
Priority: lower is tried first
This is the part that trips people up, because it reads backwards. The lowest priority number is the most preferred server. So an MX at priority 10 is tried before one at priority 20. Equal priorities are load-balanced — a sender picks among them at random. A typical setup looks like this:
example.com. MX 10 aspmx.l.google.com. example.com. MX 20 alt1.aspmx.l.google.com. example.com. MX 30 alt2.aspmx.l.google.com.The priority 10 host handles delivery normally; the higher-numbered ones are fallbacks that queue mail if the primary is unreachable. This tool resolves every MX host to its IPs so you can confirm they all point somewhere real.
The failure modes worth catching
- No MX records at all. With no MX published, a sender may fall back to the domain’s A record and deliver to that IP instead — an implicit-MX behaviour that still works but is fragile and easy to overlook. Publishing explicit MX records is always the right move.
- Dangling MX. An MX host that no longer resolves to any IP. The record looks fine in DNS, but delivery fails because there’s nothing to connect to — classic after a provider migration where the old hostname was decommissioned.
- Null MX (RFC 7505). A single MX record of
0 .(priority zero, a lone dot) is a deliberate signal that the domain sends no mail and receives none. Defined in RFC 7505, it lets senders fail fast instead of timing out — the correct configuration for a parked or send-only domain. - Duplicate or accidental priorities. Two records sharing a priority isn’t wrong, but it’s often unintentional after an edit and worth a second look.
What the MX tells you about your mail stack
The MX hostnames usually give away the provider — aspmx.l.google.com means Google Workspace, *.mail.protection.outlook.com means Microsoft 365, *.pphosted.com means Proofpoint, and so on. That matters because your inbound provider is only half the story: the servers that receive your mail are frequently not the ones that send it. Once you’ve confirmed the MX, it’s worth pointing the SMTP server test at your top MX to check its banner and TLS, verifying the reverse DNS of your sending IP, and running a full Email Health Check to line MX up alongside DKIM, SPF and DMARC.
Frequently asked questions
- Which MX record is used first?
- The one with the lowest priority number — lower is more preferred. Priority 10 is tried before priority 20; equal priorities are load-balanced at random, and higher numbers act as fallbacks.
- What happens if a domain has no MX record?
- Senders may fall back to the domain’s A record (implicit MX). It usually works but is fragile — publish explicit MX records so delivery is predictable.
- What is a null MX record?
- A single MX of
0 .defined in RFC 7505. It declares the domain accepts no mail, so senders fail fast. Correct for parked or send-only domains. - Why does my MX host not resolve to an IP?
- That’s a dangling MX — the hostname has no A/AAAA record, usually left over after a migration. Delivery fails with nothing to connect to. Point the MX at your current provider’s hostname.