MX Lookup

An MX lookup shows which mail servers accept email for a domain, which makes it the quickest way to find who hosts email for a business. It is also the first thing to check when messages stop arriving or you are moving to a new email provider. Our tool works as an email host lookup and mail server finder: it reads the live MX records, puts them in priority order, confirms that every mail server hostname resolves, names the email provider behind them, from Google Workspace and Microsoft 365 to Zoho, Proton Mail and Fastmail, and labels security gateways such as Mimecast or Proofpoint. It also flags mail servers that have no reverse DNS and understands a null MX for domains that never receive mail.

How to use the MX lookup

1. 1 Enter the domainType the part after the @ in the email address, for example example.co.uk. Pasting a full email address or a website URL also works.
2. 2 Run the MX lookupSign in with your free account and run the check. We query the domain's MX records live and keep the result cached for about ten minutes.
3. 3 Review the checksYou will see how many MX records were found, the email provider where we recognise it, whether every host resolves, how many servers there are and any reverse DNS warnings.
4. 4 Fix any failures and recheckCorrect the records at your DNS host using your provider's values, wait for the old TTL to expire, then run the lookup again.

How email finds your mail server

When someone sends a message to sales@example.co.uk, their mail server asks DNS for the MX records of example.co.uk. Each answer contains a preference number and a hostname. The sender sorts them, connects to the most preferred host on port 25 and hands the message over. If that server does not respond, it tries the next one, and if none respond it queues the message and keeps retrying, typically for up to five days, before bouncing it back to the sender.

One detail surprises many people: if a domain has no MX records at all, the rules in RFC 5321 tell senders to fall back to the domain's own A or AAAA record and try delivering there, which is usually a web server that is not set up for mail. The result is slow, confusing failures rather than a clean bounce. That is why our MX lookup treats a missing MX record as a failure, and why domains that should never receive mail ought to publish a null MX instead.

What our MX lookup checks

Our MX lookup reads the records through standard DNS, sorts them by priority and then tests each mail server hostname. Each finding appears as a separate check, so you can see at a glance what is fine and what needs attention.

• Records found: the number of MX records and the hostnames they point to, lowest priority number first.
• Email provider: recognised from the hostnames, including Google Workspace, Microsoft 365, Zoho Mail, Proton Mail, Fastmail, Yahoo, iCloud Mail, Amazon SES and WorkMail, GoDaddy, IONOS and Rackspace. MX hostnames on the domain itself are shown as an own mail server or web host, which is typical of cPanel hosting.
• Security gateways: Mimecast, Proofpoint, Barracuda, Cisco, Trend Micro, Sophos and similar filtering services are labelled as gateways. When the MX only shows a gateway, we read the SPF record for a hint of the mailbox provider behind it.
• Resolution: whether every MX host has an IPv4 or IPv6 address. A host that does not resolve is a failure, because mail sent to it cannot be delivered.
• Redundancy: whether there is more than one mail server. A single MX is shown as information, not a fault.
• Reverse DNS: whether the first IPv4 address of each server has a PTR record. Servers without one are listed as a warning.
• Null MX: a single "0 ." record is recognised and reported as correct for a domain that does not accept email.

Priorities, backups and single MX records

The preference number only matters relative to the others, so 10 and 20 behave exactly like 1 and 2. Records with the same number share the load randomly. Older setups often list a backup MX at a higher number, run by the ISP or hosting company, to queue mail while the main server is down. That made sense when small businesses ran their own Exchange server in a cupboard; today a backup MX that is poorly maintained can become a back door for spam, because it may accept mail your main filters would have refused.

Large providers build their redundancy behind a single hostname. Microsoft 365 normally gives one record such as example-co-uk.mail.protection.outlook.com, and Google Workspace now recommends a single record, smtp.google.com, although the older five-record set still works. If you use one of these, a single MX is entirely normal and our lookup marks it as information rather than a problem.

How to find who hosts email for a domain

The MX record is the most reliable public clue to who hosts a domain's email, because it has to point at the servers that actually accept the mail. Hostnames ending in google.com mean Google Workspace, mail.protection.outlook.com means Microsoft 365, protonmail.ch means Proton Mail, messagingengine.com means Fastmail and secureserver.net means GoDaddy's email. Our email host lookup does this matching for you and shows the provider next to each server.

Two situations need a closer look. If the MX points to a security gateway such as Mimecast, Proofpoint or Barracuda, that service only filters incoming mail before passing it on, so the real mailbox host is hidden. The domain's SPF record often reveals it, because it has to authorise the mailbox provider to send mail: include:spf.protection.outlook.com points to Microsoft 365 and include:_spf.google.com to Google Workspace. If the MX hostname is on the domain itself, such as mail.example.com, the mail is usually handled by the web host or the company's own server; the reverse DNS name of its IP address normally shows which hosting company runs it.

Reverse DNS and why it is flagged

A PTR record maps an IP address back to a hostname. Receiving servers commonly check that a connecting mail server has reverse DNS, and many also expect the name to resolve back to the same IP, known as forward-confirmed reverse DNS. Gmail's sender guidelines, for example, require valid reverse DNS on sending IPs.

An MX record describes where you receive mail, not where you send it from, but on many cPanel and self-managed servers the same machine does both. If our lookup warns that a mail server has no reverse DNS, ask whoever controls the IP address to set it, which is usually your hosting company rather than your domain registrar, because PTR records live in the IP owner's DNS, not yours. Large providers manage this themselves, so the warning normally appears only on smaller or self-hosted servers.

Changing email provider without losing mail

Moving a business from a hosting company's mailboxes to Microsoft 365 or Google Workspace is mostly about timing the MX change. Plan it so that no mail is lost while caches update.

• A day before, lower the TTL on your existing MX records to around 300 seconds so the switch takes effect quickly.
• Create the mailboxes and verify the domain with the new provider before touching MX.
• Replace the old MX records with the new provider's values, deleting the old ones rather than leaving them at a higher priority.
• Keep the old mailboxes open for a few days, as some senders will deliver to the cached old server until their TTL runs out.
• Update SPF to include the new provider and set up DKIM, then run the MX lookup and check the provider shown is the new one.

When to publish a null MX

Many businesses own extra domains: old brand names, defensive registrations of .uk and .com variants, or campaign domains that only redirect to the main site. If those domains never receive mail, RFC 7505 lets you publish a single MX record with priority 0 and a target of a single dot. Senders that respect it reject mail immediately with a clear error instead of retrying for days or trying the web server.

A null MX must be the only MX record on the domain. Pair it with an SPF record of v=spf1 -all and a DMARC policy of p=reject, so the domain is not useful to criminals who want to send mail that appears to come from you.

Troubleshooting mail that is not arriving

When customers say their emails to you are bouncing, run the MX lookup before anything else. If it reports no MX records, the records were probably deleted during a website move or a nameserver change, which is one of the most common causes of lost mail for small businesses. Copy the correct values from your email provider's admin panel and add them back at whichever DNS host is live for the domain.

If the lookup shows MX hosts that do not resolve, the hostname is mistyped, or it belongs to a provider you no longer use and the name has been removed. If everything resolves and the right provider is shown, the fault is more likely to be inside the mail service, such as a full mailbox, a forwarding rule or a filter, or on the sender's side. Ask the sender for the full bounce message: the three-digit SMTP code and the server named in it tell you which step failed, and whether it happened before or after your MX was reached.

Examples you can copy

example.co.uk.  3600  IN  MX  0  example-co-uk.mail.protection.outlook.com.

example.co.uk.  3600  IN  MX  1  smtp.google.com.

example.co.uk.  3600  IN  MX   0 .
example.co.uk.  3600  IN  TXT  "v=spf1 -all"

dig +short MX example.co.uk
nslookup -type=mx example.co.uk
dig +short -x 203.0.113.25

Common mistakes to avoid

Frequently asked questions