MX Lookup
See which mail servers accept email for a domain.
An MX record tells the rest of the internet which servers accept email for a domain. A sending server looks up the MX records for the recipient's domain, sorts them by preference, and tries the lowest number first. Without an MX record there is nowhere to deliver, and mail to the domain bounces.
The preference number is a priority, and the ordering is counter-intuitive: 10 is preferred over 20. Publishing several records at different preferences gives you failover, since a sender that cannot reach the primary moves down the list. Publishing several at the same preference distributes load between them instead.
MX records are only the first of four things that decide whether your email arrives. They establish where mail is delivered; SPF says which servers may send on your behalf, DKIM signs the messages, and DMARC tells receivers what to do when those checks fail. A domain with perfect MX records and no DMARC policy is still trivially spoofable.
How to look up MX records from a terminal
The same question this page asks can be put to any resolver from your own machine, which is useful when you want to compare what a particular resolver has cached, or script the check. The number before each hostname is the preference.
dig MX example.com +short # Against a specific public resolver nslookup -type=MX example.com 8.8.8.8 # PowerShell, with the remaining cache time in the TTL column Resolve-DnsName example.com -Type MX -Server 8.8.8.8
A record existing is not the same as mail being deliverable to it. Two further checks show whether the server named will actually take a message: that the hostname resolves to an address, and that something answers SMTP on port 25.
Checking that the mail server actually answers
Take the hostname with the lowest preference from the lookup and test it directly. The second command opens an SMTP connection, upgrades it to TLS and prints the certificate the server presents, which is the same handshake a sending server performs.
# Does the MX hostname resolve? dig A mx1.example.net +short # Does it accept a connection and offer STARTTLS? openssl s_client -starttls smtp -connect mx1.example.net:25 -crlf -brief # Windows: is port 25 reachable at all? Test-NetConnection -ComputerName mx1.example.net -Port 25
Run these from a server rather than a laptop. Many residential ISPs and cloud providers block outbound port 25 to fight spam, so a timeout from home proves nothing about the mail server. To enforce TLS on inbound mail rather than merely offer it, see the MTA-STS checker.
Identifying the email host from its MX records
The MX hostnames name the platform that receives the domain's mail, which answers "who hosts email for this domain?" without asking anyone. The common patterns:
- Google Workspace:
smtp.google.comon newer setups, oraspmx.l.google.comwithalt1toalt4variants on older ones. - Microsoft 365: a name ending in
mail.protection.outlook.com, built from the domain with dots replaced by dashes. - Zoho Mail:
mx.zoho.com,mx2.zoho.comandmx3.zoho.com, or the regional equivalents such aszoho.euandzoho.in. - Proton Mail:
mail.protonmail.chandmailsec.protonmail.ch. - Fastmail:
in1-smtp.messagingengine.comandin2-smtp.messagingengine.com. - A security gateway such as Mimecast (
mimecast.com) or Proofpoint (pphosted.com): the gateway receives the mail and passes it on, so the mailbox provider behind it is not visible in DNS at all.
Common MX mistakes and how to fix them
Most MX faults are visible in the lookup itself once you know what to look for:
- Records from the previous provider left in place. If they share the new records' preference, senders split mail between the two providers; if they carry a higher number, they still receive mail whenever the new servers are briefly unreachable. Either way some messages land in a mailbox nobody reads. Delete the old records once the new provider is live.
- A backup server given the lower number. Preference 10 is tried before 20; if the backup is at 5, it becomes the primary.
- A missing trailing dot in a zone file. In BIND-style zones,
mail.example.netwithout a final dot is read as relative and becomesmail.example.net.example.com. If the lookup shows your own domain appended to the target, this is why. - An MX pointing at a CNAME. The DNS specification says an MX target must be a name with its own address records, not an alias. Many senders tolerate it, which is why it survives, but the ones that do not will defer mail.
- Expecting a subdomain to inherit the parent's MX. It does not. Mail for
user@support.example.comneeds MX records published onsupport.example.comitself.
After changing MX records, confirm the new set is being served everywhere with the DNS propagation checker set to MX, then check that the new provider is authorised to send in your SPF record. The email security checker reviews MX, SPF, DKIM and DMARC together.
What this tool does
Priorities in order
MX records carry a preference number, and lower wins. The list shows the order senders will actually try, not just the set.
Identify the provider
The hostnames name the platform: Google Workspace, Microsoft 365, Proton, Zoho or a self-hosted server are all recognisable at a glance.
Confirm a migration
After moving providers, the old servers must be gone from this list. Leaving them in place silently splits incoming mail between two systems.
Start of the delivery check
MX records say where mail goes. SPF, DKIM and DMARC decide whether it is trusted — check those next.
Frequently asked questions
What is an MX record?
An MX ("mail exchanger") record names a server that accepts email for a domain, along with a preference number. Sending servers look up MX records for the recipient domain and connect to them in preference order to deliver a message.
What does the MX priority number mean?
It is a preference, and lower numbers are tried first. A record with priority 10 is used before one with priority 20, which only receives mail if the first is unreachable. Records sharing a priority are treated as equal and selected between at random, spreading the load.
Why is my email bouncing when I have MX records?
MX records only say where to deliver. Mail still bounces if the named server refuses the connection, does not recognise the recipient address, or rejects the sender on SPF, DKIM or DMARC grounds. Check the bounce message — it usually quotes the receiving server's own reason.
Can a domain have no MX record and still receive email?
There is a legacy fallback where a sender with no MX answer may try the domain's A record, but you should not rely on it: many modern senders skip it, and receivers increasingly treat a missing MX as a signal the domain does not do email. If the domain should receive mail, publish MX records.
How many MX records should I have?
Whatever your provider specifies — usually two to five. Google Workspace and Microsoft 365 each publish their own recommended set, and the right answer is to match it exactly. Extra records pointing at servers you no longer use are worse than none, because some mail will be delivered there.
Should MX records point at a hostname or an IP address?
A hostname, always. The specification requires the MX target to be a name with its own address records, and an IP address in an MX record is invalid — some senders reject it outright while others silently fail, which makes it a difficult fault to diagnose.
How do I find out who hosts email for a domain?
Look up its MX records and read the hostnames. Google Workspace, Microsoft 365, Zoho, Proton and Fastmail each use recognisable names, listed above. If the MX points at a security gateway such as Mimecast or Proofpoint, DNS shows only the gateway, and the mailbox provider behind it cannot be identified from the records alone.
What does an MX record of "0 ." mean?
It is a null MX, defined in RFC 7505, and it states that the domain accepts no email at all. Senders that see it fail the message immediately instead of retrying for days. It is the right record for a domain that sends mail but never receives any, or for a parked domain you want to protect from being used as a reply address.
Monitor it, don't just check it
One-off checks catch what is broken today. CertNotify re-checks your certificates and domains every day and emails you before either expires; paid plans add a daily DNS check and a scan of connected repositories on every push.