Free tool
See which mail servers accept email for a domain, ordered by priority.
Enter a domain to look up its MX records.
An MX (Mail Exchange) record tells the internet which servers accept email for your domain, and in what order to try them. Lower priority numbers are tried first.
Misconfigured MX records are a common cause of email delivery failures. This tool lists every mail server for a domain with its priority so you can confirm mail routes where it should.
Each MX record pairs a priority number with the hostname of a mail server, and each mail server name needs its own address record:
example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.
mail1.example.com. 3600 IN A 192.0.2.25
mail2.example.com. 3600 IN A 198.51.100.25
Sending servers try the lowest number first and move to the next if it does not answer. Records with the same number share the load. Only the order matters, not the numbers themselves, so 10 and 20 behave exactly like 1 and 2.
The target must be a hostname with an A or AAAA record. It cannot be an IP address, and RFC 2181 says it must not be a CNAME. If a domain has no MX records at all, senders fall back to its A or AAAA record (RFC 5321). To say outright that a domain never receives mail, publish a null MX: example.com. IN MX 0 .
Rows are sorted by priority, lowest first, in two columns: Priority and Mail server. The bar above shows how many MX records were found and the query time. The lookup is made live from the PulseStack™ server in the UK through Google Public DNS (8.8.8.8), with Cloudflare (1.1.1.1) as the fallback, and nothing is stored.
The mail server names usually show who runs the mailboxes. Google Workspace domains point at smtp.google.com or at the older aspmx.l.google.com set, and Microsoft 365 domains usually point at a name ending in mail.protection.outlook.com.
A single row with priority 0 and a blank mail server is a null MX: the domain accepts no email. No MX records found means the domain publishes no mail servers at all.
The old provider's records are still there. After moving email, leftover MX records split incoming mail between the old and new systems. Remove every MX record that belongs to the provider you left.
A backup with the lowest number. If a backup or filtering server has the lowest priority, it receives everything first. Check that the order in the table matches what your provider specified.
A mail host that no longer resolves. The MX points at a name with no A or AAAA record, so delivery fails. Look up each mail server name with the A record lookup.
Records on the wrong name. MX records belong on the domain after the @ in your email addresses. For you@example.com that is example.com itself, usually written as @ in DNS panels, not www.example.com. Look up exactly that name here.
Mail arrives, but your replies land in spam. MX records only control incoming mail. Outgoing trust comes from your SPF, DKIM and DMARC records, and from the reverse DNS of the sending server, which the reverse IP lookup shows.
On macOS or Linux, run dig MX example.com +short. On Windows, use nslookup -type=MX example.com, or in PowerShell Resolve-DnsName -Name example.com -Type MX.
To see whether a mail server accepts connections, PowerShell's Test-NetConnection -ComputerName mail1.example.com -Port 25 tries the SMTP port. Many home broadband providers block outgoing port 25, so a failure from home does not always mean the server is down.
After changing mail provider, the DNS propagation checker shows which public resolvers return the new MX records. To be told if they change again, a PulseStack™ DNS record monitor on a paid plan checks them as often as every five minutes and alerts you when no MX record contains the mail server you expect.
Priority (also called preference) sets the order mail servers are tried. Sending servers attempt the lowest number first. Equal priorities share load. It is not a quality ranking, just a sequence.
If a domain does not handle email, having no MX records is normal. If you expect to receive mail and see none, senders will try the domain's A record instead, which usually points at a web server that does not accept mail, so add the MX records your email provider gives you.
No. MX records must point to a hostname (like mail.example.com), never directly to an IP. The hostname then resolves through its own A or AAAA records, and it should not be a CNAME either.
That is a null MX (RFC 7505): a statement that the domain accepts no email at all, so senders give up straight away instead of retrying. In this tool it appears as priority 0 with a blank mail server.
Not directly. MX records only decide where mail to your domain is delivered. Whether your outgoing mail is trusted depends on your SPF, DKIM and DMARC records and on the reverse DNS of the server that sends it.
Every one runs a real check, live, with nothing to install.
PulseStack™ DNS record monitors check MX, A, AAAA, CNAME, TXT and NS records as often as every five minutes and alert you when the value you expect disappears. Included from the Starter plan at £9 a month, with a 14-day trial and no card.