MX Record Lookup

MX (Mail Exchanger) records tell sending mail servers where to deliver messages for a domain. Each record has an exchange hostname and a priority number. Lower priority numbers are tried first, so a record with priority 10 is preferred over a record with priority 20. This tool runs a live MX-type DNS query through a public resolver and returns every record the domain publishes, sorted by priority.

Run an MX lookup when moving email providers, setting up Google Workspace or Microsoft 365, troubleshooting bounced mail, confirming a domain can receive email, or verifying that a recent DNS change has actually propagated. The result should exactly match the hostnames and priorities from your mail provider's setup documentation. For the bigger picture of how a message finds your servers, see the guide on MX records and email routing.

A normal setup has one or more MX records, each pointing to a hostname (not a raw IP). Priority is shown as a small integer — lower wins. If multiple records share the same priority, senders pick between them at random for basic load distribution. If there are no MX records at all, some senders fall back to the domain's A or AAAA record ("implicit MX"), but modern hosted mail should always publish explicit MX records.

Priorities decide the order, not redundancy by themselves. Hosted providers typically publish a primary at priority 1 and several alternates at priority 5 or 10 — sending servers always try the primary first, then walk down the list. A setup with five records at priority 10 is also valid: senders just pick randomly between them, which is how cloud providers spread inbound load across multiple ingress hosts.

NXDOMAIN means the domain itself does not exist in DNS. A successful response with zero MX records means the domain exists but has not published any mail-routing records — mail to it will usually bounce or fall back to the A record. An MX record pointing to a hostname that does not resolve is worse than no MX at all: senders will get a temporary failure and queue retries. If the resolver returns SERVFAIL, the domain's authoritative nameservers are unreachable or DNSSEC validation is failing. Mail that routes correctly but still lands in spam is usually an authentication problem — see SPF, DKIM, and DMARC explained.