An MX record tells the rest of the internet which servers receive email for a domain. To check them, look up the domain’s MX records and read the priority on each one: the lowest number is the mail server that sending systems try first. The MX lookup tool does this in your browser, sorts the records by priority, and shows the TTL for each.
Here is how MX records work, how to read the priorities, and what it means when the lookup comes back empty.
What an MX record is
When a server has mail for [email protected], it does not guess where to deliver it. It looks up the MX records for example.com and gets back a list of mail servers. Each entry is a priority number and a hostname, for example:
10 mail.example.com
20 backup.example.comThe sending server resolves the chosen hostname to an address and connects there to hand over the message. MX records are the reason the part of your email address after the @ controls where mail goes, regardless of where the website lives.
Reading the priority
The number in front of each host is its preference, almost always called the priority. The rule is simple: lower wins.
- Sending servers sort the records and try the lowest number first.
- If that host does not answer, they fall back to the next number up.
- Records with the same number are treated as equals, and the load is spread across them.
So in the example above, mail goes to mail.example.com whenever it is reachable, and only falls to backup.example.com when the primary is down. The MX lookup sorts the records this way for you, so the server at the top of the table is the one that handles mail under normal conditions.
A common surprise: a higher priority number means a server is used less. The names feel backwards, but they match how the standard defines it. The value is a preference, and a lower preference is preferred.
What the hostnames tell you
The mail-server hostnames usually reveal the email provider, which is handy when you do not know how a domain is set up. Records pointing at aspmx.l.google.com mean Google Workspace; *.mail.protection.outlook.com means Microsoft 365; a host on the domain’s own name often means a self-run server. Reading the MX is the fastest way to confirm who handles a domain’s mail before you troubleshoot deliverability.
When the lookup is empty
If the lookup returns no MX records, the result shows the resolver status so you know why. A domain with no MX cannot reliably receive mail. Some senders will fall back to the domain’s A or AAAA record under the standard, but you should not count on it, and many will not. A blank MX result is expected for a domain that only hosts a website and was never set up for email.
If you expected mail to work and the MX is empty, that missing record is very likely the cause.
MX and SPF go together
Checking MX tells you where mail is received. It does not say which servers are allowed to send as the domain; that is what an SPF record covers. If you are auditing a domain’s email setup, look up the MX records here and then check the SPF record so you have both directions: who receives, and who is authorised to send.
Live, but cached
MX answers come from a public resolver over a secure connection, so they reflect what is published now, give or take caching. The TTL on each record is how long a resolver may keep serving it. Right after a provider switch you can see the old servers until that timer runs out, so give the records time to propagate before deciding something is misconfigured.
Open the MX lookup tool, enter a domain, and read the mail servers in priority order. For the full picture of a domain’s records, the DNS lookup covers every other type.