Webmaster & Network·3 min read

Reading MX Records: Where a Domain's Email Really Goes

Every email you send starts with a question your mail server asks in the background: where does this domain want its mail delivered? The answer lives in the domain's MX records. They are short, easy to overlook and responsible for a surprising share of lost email, from moves between providers that were never finished to domains that quietly stopped accepting mail years ago. Here is how to read them and what to look for.

Open the free MX Lookup All insights

What an MX record tells a sending server

Mail routing in one line.

An MX record names a mail server and gives it a priority number. When a message is addressed to someone at example.com, the sending server looks up example.com's MX records, sorts them by priority and tries the lowest number first. If that server does not answer, it moves to the next. Records with the same number share the load.

The target has to be a host name with its own address records, not an IP address and not an alias. If a domain has no MX records at all, senders fall back to its A record, which rarely runs a mail server, so the message usually bounces after retrying for a while. A domain that should never receive mail can say so explicitly with a null MX: one record with priority 0 and a lone dot as the target.

Running an MX lookup

Domain or full address.

Type a domain, or paste a whole email address, into MX Lookup and press the button. The tool lists every MX record in priority order with its TTL, then resolves each mail server to its IPv4 and IPv6 addresses, adds the reverse DNS name and the network that owns the address, and names the provider when the host names give it away. It also reads the domain's SPF and DMARC records, because a domain that receives mail almost always sends it too.

A checks list sums it up: whether MX records exist, whether every server resolves, whether any target is an alias or an IP address, whether reverse DNS is set, and whether SPF and DMARC are published. The table copies or downloads as CSV for a ticket.

A worked example: finishing an email move

Two providers at once.

Suppose a company moved from its web host's mail to Google Workspace last month. An MX lookup shows smtp.google.com at priority 1, and also mail.oldhost.example at priority 10. The provider card lists both. Nothing looks broken, and most mail arrives in Google.

The second record is the problem. Whenever Google's server is slow to answer a particular sender, or a spam gateway retries, some messages land on the old host, in mailboxes nobody checks any more. The fix is to delete the old record so Google's is the only one. A quick propagation check with smtp.google.com in the expected field confirms when every resolver has caught up.

Spotting the provider behind a domain

The host names give it away.

MX host names follow recognisable patterns. Google Workspace uses smtp.google.com or the older aspmx.l.google.com set. Microsoft 365 uses a name built from your domain ending in mail.protection.outlook.com. Zoho, Proton Mail, Fastmail and Cloudflare Email Routing each have their own. MX Lookup recognises around thirty such patterns and shows the provider on a card.

Security gateways are the exception. When the records point to Mimecast, Proofpoint or Barracuda, mail passes through that filter first and is then handed to the real mailbox provider, which stays hidden. That is normal for larger organisations and not a sign of a problem.

MX mistakes that bounce mail

These are the errors the checks list catches most often:

Leftover records from a previous provider, as in the example above, which split mail between two systems.
An MX target that no longer resolves, often a server name at an old host that has since been removed.
An MX record that points straight at an IP address, which the standard does not allow.
A target that is a CNAME alias. Many servers cope, but some refuse, and the standard says not to.
No MX records at all on a domain that people write to, which leaves delivery to the unreliable A-record fallback.
A mail server IP with no reverse DNS name, which matters when the same server also sends your outgoing mail.

Where MX Lookup fits with the other email tools

Routing, then authentication.

MX records only decide where incoming mail goes. Whether your outgoing mail is trusted depends on SPF, DKIM and DMARC. When the MX checks pass, run SPF Record Checker to count your DNS lookups and test a sending IP, and DMARC Checker to read your policy and find your DKIM keys.

For a single contact's address, Email Validator combines a format check with the same MX test, and flags disposable and role addresses. And when you change MX records, DNS Propagation Checker shows when the world has caught up, so you know when it is safe to close the old mailboxes.