MX Record Lookup

What Is an MX Record?

An MX (Mail Exchange) record is a DNS entry that tells the rest of the internet which mail servers are responsible for accepting email on behalf of a domain. Defined in RFC 1035 §3.3.9 and clarified for SMTP routing in RFC 5321 §5.1, MX records are the first thing every sending mail server consults before delivering a message — without them, your domain cannot receive email at all.

Each MX record contains two fields: a numeric preference (also called priority) and a hostname pointing to the mail server. Domains typically publish two or more MX records to provide redundancy. This tool queries MX records directly via Cloudflare's DNS-over-HTTPS resolver — no signup, no logs, no ads, and results return in under 100 milliseconds.

How MX Priority Works

The preference value determines the order in which sending servers try to deliver mail. Lower numbers are tried first. A common pattern looks like this:

If two MX records share the same preference, the sending server picks one at random for load balancing — this is how providers like Google Workspace distribute inbound traffic across multiple regions. The value itself has no meaning beyond ordering: 5 and 50 behave identically as long as no other MX record has a lower preference.

How to Read MX Lookup Results

A typical MX lookup for a Google Workspace domain returns a single record:

Three things to verify in any MX result:

• The hostname resolves. An MX target that returns no A or AAAA record is a dangling MX — every message bounces.
• The hostname is not a CNAME. Per RFC 2181 §10.3, "the domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias." Some receivers reject mail that violates this rule.
• TTL is reasonable. Production MX records typically use TTLs between 300 (5 min) and 86400 (24 h). A 60-second TTL is a sign of an active migration; 604800 (one week) suggests a forgotten record.

Common MX Configuration Errors

MX misconfigurations are one of the most common reasons legitimate email bounces. The patterns below cover the majority of real-world failures:

• Missing MX record. The domain has no MX entry at all. Receivers fall back to the A record per RFC 5321 §5.1 (the "implicit MX" rule), which usually points at a web server with no SMTP daemon. Result: every inbound message bounces with "451 Connection refused" or "550 No such user."
• CNAME at the MX target. The MX value points to a name that is itself a CNAME instead of an A/AAAA record. RFC 2181 §10.3 forbids this. Strict receivers (including some large providers) reject mail; permissive receivers chase the CNAME but slow delivery measurably.
• IP literal as MX target. The MX value is a raw IP address rather than a hostname. RFC 1035 requires a domain name; IP literals are invalid and rejected.
• Wrong priority order. The backup mail server sits at a lower preference than the primary, so all mail flows to the backup instead of the primary. Common after copy-paste from documentation.
• Stale or duplicate records. Two providers, two MX record sets, no cleanup. Mail splits unpredictably between the old and new platforms.
• Typos in hostnames. aspmx.l.google.com becomes aspmx.l.googel.com; the hostname does not resolve; every message bounces.

MX vs A vs CNAME

MX records exist alongside two related DNS record types. Knowing when to use which prevents the most common mail-routing bugs:

Command-Line MX Lookup

If you prefer the terminal, every operating system ships at least one tool that returns the same data this lookup does:

• dig (Linux, macOS): dig MX example.com +short
• nslookup (Windows, macOS, Linux): nslookup -type=mx example.com
• host (Linux, macOS): host -t mx example.com
• PowerShell (Windows): Resolve-DnsName -Type MX example.com

For DNSSEC-validated results from a public DoH endpoint, use: curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=MX'. This tool is the browser equivalent of that request.

How MX Records Affect Email Deliverability

MX records control where inbound mail goes; SPF, DKIM, and DMARC control whether outbound mail is trusted. The two surfaces are independent — your MX records can be perfect while your authentication is broken, and vice versa.

That said, MX records do feed into authentication in two ways:

• SPF mx mechanism. An SPF record that uses mx authorizes every host listed in the domain's MX records to send mail for the domain. If you change MX hosts without updating the SPF mechanism's expectations, SPF can break silently. Use the SPF checker and SPF flattener to verify.
• MTA-STS and DANE. Both protocols (MTA-STS, DANE) protect SMTP delivery to your MX hosts. They cannot be enforced if your MX targets resolve to invalid names or to CNAMEs.

For a full inbound + outbound audit, run our Domain Health Check. It combines MX, SPF, DKIM, DMARC, MTA-STS, and TLS-RPT into a single report.

FAQ

What is MX lookup used for?

An MX lookup retrieves the mail server hostnames responsible for a domain's inbound email. System administrators use it to verify that a domain is configured to receive mail, debug bounce messages, identify which provider hosts a domain's mailbox (Google Workspace, Microsoft 365, Zoho, custom), and confirm that DNS changes have propagated.

How do I look up an MX record?

Enter the domain name in the field above and click "Lookup." This tool queries Cloudflare's DoH resolver and returns every MX record together with its preference, exchange hostname, and TTL. From the command line, use dig MX example.com +short on Linux/macOS or nslookup -type=mx example.com on Windows.

What is the difference between MX lookup and DNS lookup?

A DNS lookup is the general operation of asking a resolver for any DNS record type — A, AAAA, CNAME, TXT, MX, NS, SOA, and so on. An MX lookup is a DNS lookup that asks specifically for the MX record type. This page runs an MX-only query by default; switch tabs to query other record types, or use our DNS lookup tool for the all-records view.

What does MX stand for?

MX stands for Mail Exchange (or Mail Exchanger). The term predates the modern internet and refers to any server that accepts and routes email between systems. In DNS, the MX record type names the mail exchange servers responsible for a given domain.

Can a domain have more than one MX record?

Yes — most production domains publish at least two MX records. Multiple records with different preference values create a primary/backup arrangement; multiple records with the same preference create a load-balanced pool. Both patterns are common and valid per RFC 5321.

Why does my MX lookup return no results when my email works?

Three usual causes: (1) you queried a subdomain that has no MX record of its own and inherits from the parent zone, (2) your registrar's DNS is still propagating, or (3) DNSSEC validation failed and the resolver returned an empty response. Try the lookup at the apex domain, wait the full TTL, and check that DNSKEY records exist if the domain claims to be DNSSEC-signed.