MX Record Checker

How to use this MX checker

Enter a domain name.
See its mail servers listed in priority order.
Lower priority numbers are tried first by sending mail servers.

Why would I check MX records?

MX records determine which mail servers accept email for a domain. Checking them helps confirm email is routed correctly after a provider migration, or diagnose why mail from a domain isn't being delivered.

What does it mean if a domain has no MX records?

It means the domain can't receive email at all — some sending servers will fall back to the domain's A record as a last resort, but a domain intended to receive mail should always have explicit MX records.

What's the point of having multiple MX records?

Redundancy — if the primary (lowest priority number) mail server is down, sending servers automatically try the next one in order, keeping mail delivery working.

Why lower priority numbers mean higher priority — the counterintuitive convention

MX priority works backwards from how "priority" usually reads intuitively: a lower number means a server is tried first, not a server that's less important. This comes directly from the original SMTP specification (RFC 5321), which defines MX priority as a preference value where sending mail servers must attempt delivery to the lowest-numbered server first, then work upward through higher numbers only if lower ones are unreachable. A domain's primary mail server typically has a priority like 10, with backup servers at 20, 30, and so on — the actual numbers themselves don't matter beyond their relative order, only which one is smallest.

MX priority isn't load balancing — it's failover, with one important exception

Multiple MX records with different priority numbers define a strict failover order: the sending server always tries the lowest number first and only moves to the next one if that attempt fails, meaning a backup server sits completely idle under normal conditions. The one case that does function as load balancing is when two or more MX records share the exact same priority number — in that specific situation, sending servers are expected to choose between the equal-priority options randomly (or via round-robin), genuinely distributing incoming mail load across those servers rather than treating one as a strict backup for the other. Mixing up these two configurations — assuming different priorities load-balance, or assuming equal priorities fail over predictably — leads to mail infrastructure that doesn't actually behave as intended.

Why an MX target must point to a hostname with its own A/AAAA record, never a CNAME

A specific, easy-to-violate DNS rule states that an MX record's target must resolve through a normal A or AAAA record, and is not allowed to point at a CNAME (an alias to another hostname). This isn't an arbitrary restriction — it exists because CNAME resolution can create ambiguity and extra lookup overhead in a context (mail delivery) where the original SMTP specification wanted a direct, unambiguous path to an IP address. Pointing an MX record at a CNAME is a real, surprisingly common misconfiguration that behaves unpredictably across different sending mail servers — some will still work by accident, others will simply fail to deliver — making it a classic, hard-to-diagnose cause of intermittent mail delivery problems.

Why correctly configured MX records don't guarantee mail actually gets delivered

MX records only answer one question: which server should a sending system attempt to hand a message off to. They say nothing about whether that message will actually be accepted once delivery is attempted, or whether it will land in an inbox rather than a spam folder. Authentication mechanisms like SPF, DKIM, and DMARC (which this site's separate SPF/DMARC Checker covers) determine whether a receiving server trusts that a message genuinely came from who it claims to, and even a domain with perfect MX and authentication records can still see mail flagged by spam filters based on sender reputation, content, or other criteria entirely outside MX record configuration. A correct MX setup is necessary for mail delivery to work at all, but it's only one piece of a larger deliverability picture.

Limitations of this tool

This tool checks whether MX records exist for a domain and shows their priority order — it doesn't actually attempt to connect to any of the listed mail servers to confirm they're accepting connections, doesn't check SPF, DKIM, or DMARC authentication records (this site's separate SPF/DMARC Checker handles that), and doesn't test actual mail deliverability or spam filtering behavior on the receiving end. Treat this as confirmation that a domain's mail routing configuration exists and is structured correctly, not as proof that email sent to that domain will actually be delivered and reach an inbox.