MX Lookup Guide: Find Where a Domain Receives Email

When you send an email, your mail server must answer one question before anything else: which server actually accepts mail for the recipient's domain? The answer lives in the domain's MX records, short for mail exchange records, which are entries in the domain's public DNS that name the servers responsible for receiving its mail, each with a priority number. The MX Lookup reads those records for a domain you supply and presents them in priority order, so you can see where mail for that domain is supposed to go. It is a format and consistency check on the records you supply or that a lookup returns, describing pasted or returned input rather than performing a live DNS query itself, and its report should be read as a snapshot of those records, not as a guarantee of delivery.

MX records work by priority and fallback. Each record names a mail server and carries a preference number, where a lower number means higher priority. A sending server tries the lowest-numbered server first; if that server is unreachable, it tries the next one, and so on. This design gives a domain both routing and resilience: the primary server handles mail normally, while secondary servers catch mail during outages or maintenance. A common and sensible setup lists two or three servers with distinct priorities, often spread across providers or locations, so that no single failure stops mail entirely. A setup with only one server works, but it has no fallback, and a setup where all servers share the same priority leaves the choice to the sender, which is acceptable but less predictable than an explicit order.

Reading an MX result means checking several things beyond the server names. First, do the records exist at all? A domain with no MX records will not receive mail reliably, and senders may fall back to other record types or reject the message, depending on their configuration. Second, do the server names resolve to real addresses? A record pointing at a name that does not exist is a dead end that senders will try and fail on before moving to the next record, delaying delivery. Third, are the priorities sensible, with the intended primary server holding the lowest number? A common mistake is assigning the backup server a lower number than the primary, which quietly routes all mail to the backup. Fourth, do the servers actually accept mail for the domain? A record can be perfectly formed and still point at a server that is not configured for the domain, in which case mail bounces with a relay error, and that failure is only visible in delivery reports, not in the DNS records themselves.

Worked example

Take a sample domain, with values clearly labelled as an illustration. An MX lookup for the domain returns three records: mail1.example.com with priority 10, mail2.example.com with priority 20, and mail3.example.com with priority 30. The sending server tries mail1 first, since 10 is the lowest number. Suppose mail1 is down for maintenance: the sender waits for its connection attempt to time out, then tries mail2, which accepts the message. The fallback worked, but the delay equals the timeout on mail1, which is why a primary server that is down for hours still causes slow delivery even with a working backup. Now suppose the priorities were accidentally reversed, with mail3 at 10 and mail1 at 30. All mail would then flow to mail3, the intended last resort, even while mail1 is healthy, and mail3's smaller capacity might queue or reject mail under load. The fix is a one-line priority correction, but finding it requires reading the records in priority order rather than assuming the first record listed is the primary. In a third variation, the lookup returns no MX records at all, and the domain owner discovers that a DNS migration dropped them; restoring the three records restores delivery, which shows why MX records belong on every post-migration checklist.

Mistakes to avoid

The first mistake is assuming mail delivery is broken at the sender when the recipient domain's MX records are missing, wrong, or pointing at dead names. The second is giving the backup server a lower priority number than the primary, which silently reroutes all mail. The third is listing only one mail server and calling the setup finished, leaving no fallback for outages. The fourth is changing mail providers without updating MX records, which leaves mail flowing to a provider that no longer serves the domain. The fifth is pasting private details into a lookup or a report: MX records themselves are public by design, but a troubleshooting note should never include passwords, internal server addresses, or account credentials alongside them.

Putting it into practice

Check a domain's MX records after any DNS migration or mail provider change, when delivery problems appear, and before launching a new domain's email. Read the records in priority order, confirm each server name resolves, and confirm with the mail provider that each listed server is configured for the domain. For related tools, the DNS Lookup covers the wider record set, the NS Lookup shows which name servers answer for the domain, and the companion guide on the DNS Lookup explains DNS records in depth. MX records are small, public, and easy to overlook, but they are the signposts that tell the world's mail servers where your mail lives.

Key points

• MX records name the servers that receive a domain's mail, each with a priority number where lower means tried first
• Sending servers fall back through the list in priority order, so a wrong order silently reroutes mail to the backup
• Check that records exist, that server names resolve, and that each server is actually configured for the domain
• Update MX records before a mail provider change and verify them after any DNS migration

In short: read the records in priority order, confirm every server is real and configured, keep a fallback, and re-check after every DNS or mail change.