MX Record Lookup

Look up the MX records for any domain and see exactly which mail servers receive its email. Enter a domain and this tool queries live DNS, parses each mail exchanger, sorts them by priority (the order senders try them), and shows the TTLs. MX records are the first thing to check when email bounces or a new mailbox provider is not receiving mail.

How to use the MX Record Lookup

Enter a domain (the bare domain, not an email address) and press Look up MX records. The tool reports:

• Each mail server the domain publishes, with its priority shown in a badge.
• The list sorted lowest-priority-first, which is the order sending servers actually try.
• The TTL of the records, so you know how long resolvers cache them.

If you paste [email protected] or a full URL, only the domain part is queried. A domain with no MX record is flagged, because that usually means mail will bounce (or fall back to the domain's A record, per the email RFCs).

What MX records are and how priority works

An MX (Mail eXchanger) record tells the world which servers accept email for a domain. When someone sends mail to [email protected], their server does not guess where to deliver it — it looks up the MX records for example.com and connects to the host named there. Without an MX record, there is nowhere for inbound mail to go, which is why a missing or wrong MX is the single most common cause of "we stopped receiving email".

Each MX record carries a priority (also called preference), a number where lower means higher priority. A sending server sorts the MX records and tries the lowest number first; if that host is unreachable it falls back to the next. So a setup like:

• 10 aspmx.l.google.com — tried first (primary)
• 20 alt1.aspmx.l.google.com — tried only if the primary is down (backup)

routes all normal mail to the priority-10 host and uses the priority-20 host as a fallback. When two records share the same priority, senders pick between them at random, which spreads inbound load evenly. The actual numbers are arbitrary — only their relative order matters, which is why providers commonly use 1, 5, 10 or 10, 20, 30.

MX records point at hostnames, not IP addresses, and the RFCs forbid an MX target from being a CNAME — it must resolve directly via an A or AAAA record. After changing your MX (for example migrating from one email provider to another) the old records linger in resolver caches until their TTL expires, so mail can keep arriving at the old host for a while. Checking the live MX is the way to confirm a migration has actually taken effect.

Common use cases

• Diagnosing bounced mail — confirm the domain actually publishes a mail server and that it is the one you expect.
• Verifying an email migration — check that MX now points at the new provider (Google Workspace, Microsoft 365, Fastmail) after a cutover.
• Setting up a new domain — confirm the MX records you added have propagated and are correct.
• Checking a vendor or partner — see who hosts a company's email before sending bulk or sensitive mail.
• Auditing backup MX — verify a secondary mail server is in place with the right priority.

Common MX problems and fixes

• No MX record at all. Inbound mail bounces, or RFC-compliant senders fall back to the domain's A record (rarely what you want). Add an MX pointing at your mail host.
• MX points at a CNAME. Not allowed by the standard and rejected by strict senders. Point the MX at a hostname that has its own A/AAAA record.
• Priorities reversed. If the backup has a lower number than the primary, mail goes to the wrong server first. Remember lower equals more preferred.
• Old provider still listed after migration. Resolver caches hold the old MX until the TTL expires. Lower the TTL before migrating so the switch is fast, then re-check here.
• MX host has no PTR / FCrDNS. The mail server itself should have matching forward and reverse DNS or receivers may reject it — that is about the server's IP, not the MX record, but it is worth checking alongside.

MX answers the "where does mail go" question. To inspect the matching anti-spoofing records, pair this with the TXT record lookup (for SPF), the DMARC checker and the DKIM checker.