Every other DNS record answers "where is this" for a website, a subdomain, or a name server. An MX record answers a narrower but more consequential question: which mail servers are allowed to accept email on this domain's behalf, and in what order should they be tried. Get it wrong, and mail doesn't error loudly — it just quietly stops arriving.
How MX Records Work
A domain publishes one or more MX (Mail Exchange) records, each pairing a mail server's hostname with a priority number. When another mail server has a message to deliver, it looks up the recipient domain's MX records, sorts them by priority — lower numbers are tried first — and attempts delivery to the first one. If that server doesn't answer, it falls through to the next-lowest priority as a fallback, and so on down the list. A domain with a single MX record has no fallback at all; a domain with several has a real safety net if its primary mail server is temporarily down.
Two records with the same priority number are treated as equally preferred — a sending server is free to pick between them, commonly used to spread inbound mail load across more than one server rather than expressing a strict order.
Reading an MX Lookup Result
- Priority — the order mail servers are tried in. Lower always wins; a record with priority 5 is attempted before one with priority 10, regardless of the order they happen to be listed in.
- Mail server hostname — the actual server responsible for accepting mail at that priority level. This is not the domain's own website server — a domain's mail can be (and very often is) hosted entirely separately from the site itself.
- Resolved IP address — where that hostname currently points. A mail server hostname with no A/AAAA record at all is a real misconfiguration: a sending server can't deliver mail to a name it can't resolve to an address.
- Provider — shown when the mail server's hostname matches a widely recognized email provider (Google Workspace, Microsoft 365, Zoho Mail, and others), so a bare hostname like
aspmx.l.google.comdoesn't have to be decoded by hand.
Null MX: When a Domain Explicitly Rejects Mail
A domain can publish a single MX record with an empty hostname and priority 0 — a "null MX", defined in RFC 7505. This is a deliberate declaration that the domain does not accept email at all, distinct from simply having no MX record configured. A sending server that encounters a null MX bounces the message back immediately instead of retrying delivery for days, which is exactly the point — it's meant for domains (or specific subdomains) that are only ever used for a website, an API, or infrastructure, and have no legitimate reason to receive mail. Seeing one isn't a misconfiguration to fix; it's the domain owner correctly saying "don't bother."
MX Records vs. Sender Authentication
An MX record only controls inbound mail — where messages sent to this domain get delivered. It says nothing about whether a message claiming to be sent from this domain can actually be trusted, which is a completely separate system: SPF lists which servers are authorized to send on the domain's behalf, DKIM cryptographically signs outgoing mail so it can't be altered in transit without detection, and DMARC tells receiving servers what to do with mail that fails those checks. A domain can have a perfectly healthy MX setup and still be trivially easy to spoof if none of those three are configured — the two halves of email trust are independent and both worth checking.
When to Use MX Lookup
- Confirming email actually points where it's supposed to after switching providers or migrating a domain.
- Diagnosing mail that isn't arriving — a missing, unresolvable, or misordered MX record is one of the most common causes, and it fails silently with no error shown to the sender.
- Verifying a DNS change has taken effect after updating MX records, especially before decommissioning an old mail provider.
- Identifying which provider actually hosts a domain's email, without needing to already know or guess.
Frequently Asked Questions
What does the priority number on an MX record actually mean?
Lower is preferred. A sending server always tries the lowest-priority MX record first and only falls back to a higher number if that server doesn't respond. It's a preference order, not a count or a version number.
A domain has no MX records at all — is that a problem?
It depends on intent. If the domain is only used for a website or an API and was never meant to receive email, no MX records is completely normal. If it's a domain people are expected to email, it's a real gap — without an MX record, there's nowhere for inbound mail to be delivered to at all.
What is a "null MX" record?
A single MX record with an empty hostname and priority 0, defined in RFC 7505, that explicitly tells other mail servers this domain does not accept email. It's different from having no MX record configured — it's a deliberate statement, not an oversight, usually published for a domain or subdomain that's only used for something other than email.
Does a healthy MX record mean this domain's outgoing mail is trustworthy?
No — MX only governs where mail sent to the domain is delivered. Whether mail claiming to be from the domain can be trusted is a separate system entirely: check SPF, DKIM, and DMARC for that half of the picture.
Why does the resolved IP address matter?
A mail server hostname is useless to a sending server if it can't be resolved to an actual address — delivery simply fails. Seeing "no A/AAAA record" next to a mail server hostname here is a genuine, worth-fixing misconfiguration, not a cosmetic detail.
Look up any domain's mail servers with the MX Lookup tool.