How to find MX records for any domain

// published 2026-04-17

MX records tell other mail servers where to deliver email for a domain. Finding them is a one-line DNS query, and reading them tells you a lot about how a company runs its email — including which provider, how redundancy is set up, and whether they have fallback routes.

What an MX record looks like

example.com. IN MX 10 mail1.example.com.
example.com. IN MX 20 mail2.example.com.

Two parts:

• Priority (10, 20, etc.) — lower is tried first. Sending servers attempt the lowest priority, fall back to higher numbers if that fails.
• Exchange (mail1.example.com.) — hostname to deliver to. Must resolve to an A/AAAA record (not a CNAME, per spec).

Run the MX Lookup on any domain to see priorities, hostnames, and resolved IPs.

Reading the provider from the MX

Most companies route email through a hosted service. You can identify the provider by the MX hostname:

• *.google.com / aspmx.l.google.com — Google Workspace
• *.mail.protection.outlook.com — Microsoft 365
• mx.zoho.com / *.zoho.eu — Zoho Mail
• *.mail.iphmx.com — Cisco IronPort / Email Security Appliance (usually fronting on-prem or another provider)
• *.pphosted.com — Proofpoint
• mx.yandex.ru / mx.yandex.net — Yandex 360
• *.mimecast.com — Mimecast
• *.fastmail.com / in*.smtp.messagingengine.com — Fastmail
• *.mailgun.org, *.mandrillapp.com — these are transactional, not full mail hosts

If you only see a domain's own hostnames (e.g. mail.yourcompany.com), they're self-hosting — on their own servers or a colocated setup.

Priorities and fallback

A typical Google Workspace MX setup:

aspmx.l.google.com.          1
alt1.aspmx.l.google.com.    5
alt2.aspmx.l.google.com.    5
alt3.aspmx.l.google.com.   10
alt4.aspmx.l.google.com.   10

One primary, four backups at varying priorities. Senders try priority 1 first; if unreachable, round-robin across 5s, then 10s. This is a redundancy pattern baked into the hosted service — you don't have to configure it yourself.

Self-hosted setups often publish just one or two MX records. That's fine, but means no automatic failover. Consider a second MX pointing at a backup mail server (or a "spam trap" MX that queues during outage).

Common MX mistakes

CNAME at the MX target

RFC 2181: MX exchange must point at a host with A/AAAA records, not a CNAME. Many senders will follow the CNAME anyway, but some strict implementations bounce. Fix: use a direct A record, or point MX at the apex of a zone that has A records.

Missing PTR

The IP your MX resolves to should have a matching PTR record pointing back at the MX host (or a host in the same domain). Missing reverse DNS is a top cause of outbound mail being scored as spam. Check with Reverse DNS.

Using "." to mean "no mail"

RFC 7505 specifies that MX 0 "." means the domain explicitly refuses email. Some tools misread this as malformed and bounce; some treat it as a destination. If you actually want to reject all mail for a domain, this is the documented way.

Quick check

Paste any domain into MX Lookup. You'll get priorities, IPs, and an auto-detected provider. Handy for quickly answering "who runs their email?" on a competitor, a lead, or your own production domain.