What Is an MX Record?
A beginner-friendly explanation of Mail Exchange records and how they route email to the correct server.
If you have ever wondered how an email sent from one side of the world lands in the right inbox on the other, the Mail Exchange — or MX — record is a big part of the answer. It is a small entry in the Domain Name System (DNS), but it does one of the most important jobs on the internet: it tells sending servers exactly where to deliver mail for a domain.
The Job of an MX Record
An MX record maps a domain name to the hostname of the mail server that accepts messages for it. When someone sends a message to you@example.com, their outgoing server queries DNS for the MX records of example.com. The response is a hostname — something like mail.example.com — which the sending server then connects to over SMTP to hand off the message.
Without an MX record, a sending server has no authoritative way to know where to deliver mail. The domain might still send email, but it cannot reliably receive any. That is why MX records are among the first things configured when a business sets up email on a custom domain.
Two Parts: Priority and Hostname
Every MX record carries two pieces of information:
- Priority — a number, usually between 0 and 100, that sets the order in which servers should be tried. Lower numbers are tried first.
- Hostname — the fully qualified domain name of the mail server, which itself must have an A or AAAA record so it can be reached.
A domain almost always publishes more than one MX record. The combination of multiple hosts with different priorities gives mail servers a fallback: if the primary host is unreachable, the sender tries the next one in order. This is how providers build redundancy into email delivery.
Examples: Google Workspace and Microsoft 365
Provider-hosted email uses predictable MX patterns, which is why MX records are also the fastest way to identify a domain's provider. Here is what the records look like for the two most common business suites.
Google Workspace
A domain on Google Workspace typically publishes five MX records, all pointing at google.com mail hosts with ascending priority values:
aspmx.l.google.com— priority 1alt1.aspmx.l.google.com— priority 5alt2.aspmx.l.google.com— priority 5aspmx2.googlemail.com— priority 10aspmx3.googlemail.com— priority 10
The exact set can vary slightly, but the aspmx.l.google.com primary and the google.com / googlemail.com hostnames are a reliable fingerprint.
Microsoft 365
Microsoft 365 uses a single, consistent protection endpoint for inbound mail:
<tenant>.mail.protection.outlook.com— priority 0
The <tenant> portion is unique to each organisation, but the mail.protection.outlook.com suffix is constant. Spotting it in an MX response is the quickest way to confirm Microsoft 365, a pattern we explore further in our Google Workspace vs Microsoft 365 comparison.
What Happens When There Are No MX Records
If a domain has no MX records, the sending server will, as a fallback, try to deliver mail to the domain's bare A or AAAA record. In practice this almost never works for modern hosted email, because the web server is not a mail server. A domain with no MX records is effectively saying “I do not receive mail here.”
This is a legitimate state. Some domains exist only for websites or branding and intentionally have no MX records. Others have had their records misconfigured or accidentally deleted during a migration. If you are troubleshooting delivery failures, an empty MX response is one of the first things to check.
How to Check MX Records Yourself
You do not need any special software. Two commands cover the vast majority of systems.
Using dig (macOS and Linux)
Run the following in a terminal:
dig MX example.com
The answer section lists each MX record with its priority and hostname. Add +short for a compact view.
Using nslookup (Windows and cross-platform)
Open a command prompt and run:
nslookup -type=MX example.com
The output shows the same priority-and-hostname pairs, plus the DNS resolver that answered.
For a guided, no-terminal experience, the MX Record Checker performs the same lookup in your browser and formats the results. To understand the broader context of how these queries resolve, see how email domain lookup works.
A Few Practical Notes
- Priority is preference, not load. Lower numbers are preferred. Backup servers receive mail only when the higher-priority host is unavailable, not on a round-robin basis.
- MX points to a hostname, never an IP. The hostname must then resolve to an A or AAAA record. Pointing MX directly at an IP is invalid and will be ignored.
- TTL controls caching. Each record has a time-to-live that tells resolvers how long to cache it. Changes to MX records propagate only after the old TTL expires, so plan migrations accordingly — a topic we cover in understanding MX records for business email.
Why MX Records Matter
MX records are the single most authoritative signal for where a domain receives its mail. They drive delivery, enable redundancy, and — because each provider uses recognisable hostnames — let anyone identify the email provider behind a domain in seconds. Once you can read them, you have the foundation for everything from deliverability troubleshooting to sales intelligence. The Email Provider Filter puts that same lookup behind a button, so you can apply it to one domain or a thousand.