What this checks
MX (Mail Exchanger) records tell the world where email for a domain should be delivered. When someone sends a message to [email protected], their mail server looks up the MX records of yourdomain.com, sorts them by priority (the lowest number first), and connects to the first server that answers. Without MX records the sender falls back to the domain's own address, which usually is a web server that does not speak SMTP at all.
This checker fetches the MX records of the domain you type, as public DNS resolvers (1.1.1.1 and 8.8.8.8) see them right now, sorts them by priority, and names the provider behind the hostnames when it recognises one: Google Workspace, Microsoft 365, Zoho Mail, Proton Mail, Fastmail, iCloud Mail, Cloudflare Email Routing, Mimecast, Proofpoint, Mailgun, Amazon SES inbound and a dozen others, the same table our Chrome extension uses. It then resolves the preferred server once, so a record that points at a dead hostname shows up. When there is no MX record, it looks up the domain's own address to tell you where mail would be tried instead. It never sends a message and never connects to port 25.
MX records only cover incoming mail. Whether your outgoing mail is accepted depends on SPF, DKIM and DMARC, which have their own checkers here.
How to read the result
Pass means the domain publishes MX records that point at a server with an address, or a correct null MX. Warning means mail probably works but something is off: a record that points at an IP address, a null MX mixed with real servers, or an answer that could not be read. Fail means the preferred mail server does not resolve, so mail bounces or falls through to a backup. Missing means there are no MX records; what that means for you depends on whether the domain should receive mail. Could not check means our resolvers did not get an answer; try again in a minute.
Below the status you see each server with its priority, the provider recognised from its name, and the addresses of the preferred server. Each finding links to its explanation here.
No MX record
The domain publishes no MX records. A sending server then tries the domain's own A or AAAA address on port 25 (RFC 5321 allows this). If that address belongs to a web server, which is the usual case, the connection is refused or times out and the message bounces after a few days of retries. For a domain that only sends mail and should never receive any, this is harmless but sloppy; a null MX (below) says the same thing explicitly and gives senders an immediate answer. For a domain whose users expect replies, it is a real problem: add the MX records your mailbox provider gives you.
Where mail would go without an MX
The domain has no MX record but has an address record, so receivers would try that address on port 25. The checker shows the address. Unless a mail server listens there, nothing arrives. If you do run a mail server on that host, add an MX record anyway: some senders refuse to deliver to a domain without one.
No MX and no address
The domain has neither MX records nor an A or AAAA record. There is nowhere for a sender to try, so every message to the domain bounces immediately. For a parked domain that is fine. For anything else, publish MX records.
Null MX
The only MX record is 0 . (priority zero, an empty hostname). This is the null MX of RFC 7505: an explicit statement that the domain does not accept email. Senders get an immediate, clear bounce instead of retrying a web server for days, and spammers learn nothing. It is the right record for a domain that only sends, or for a parked domain, and the checker treats it as a pass.
Null MX mixed with real servers
A 0 . record sits next to real mail servers. The standard says a null MX must be the only MX record; with a mix, some receivers deliver to the real servers and others treat the domain as not receiving mail. Decide which it is and remove the other records.
Provider recognised
The hostnames match a known mail provider. That is useful for two reasons: you can tell at a glance whether the records are the ones your provider documents, and the provider's SPF include is what your SPF record needs if you also send from its mailboxes. The checker names the include where the provider documents one.
Provider not recognised
The hostnames do not match any provider in our table. That usually means a self-hosted mail server or a smaller provider, and it is not a problem in itself. Our table covers the providers we see most often; it is the same list our Chrome extension uses.
Amazon SES inbound
The mail servers are Amazon SES inbound endpoints (inbound-smtp.<region>.amazonaws.com). Mail is received by an application built on SES rather than by a mailbox provider. Ackuna Agent Mail receives mail for its inboxes the same way.
MX points at an IP address
An MX record must name a host, not an IP address. Some receivers ignore a record like 10 192.0.2.5, so mail goes to a lower-priority server or bounces. Create an A record for the server (for example mail.yourdomain.com) and point the MX at that name.
Preferred mail server does not resolve
The server with the lowest priority has no A or AAAA record, so nobody can connect to it. Senders fall through to the next server if there is one, with a delay, and bounce if there is not. This usually happens when a server was decommissioned and the MX record was forgotten, or when a hostname was mistyped. Fix the address or remove the record.
An MX answer could not be read
One of the records did not look like priority hostname. Receivers skip such a record. Check what was published at your DNS provider.
The preferred server's address could not be looked up
Our resolvers did not answer the address query for the preferred server, so whether it resolves is unknown. The MX records themselves were read. Re-check in a minute.
The domain does not exist
Public DNS has no entry for the domain at all. Either it is not registered, it is not delegated yet, or there is a typo. Nothing can receive mail for a name that does not exist.
How to fix it
- Decide whether the domain should receive mail. If not, publish a null MX: one MX record with priority 0 and the hostname
.. Senders then get an instant, honest bounce. - If it should, copy the MX records your mailbox provider documents (Google Workspace, Microsoft 365, Zoho and the others each publish an exact list with priorities) and enter them at your DNS provider. Replace old records; do not add to them.
- Use hostnames, never IP addresses, and make sure each hostname has an A or AAAA record.
- Wait for DNS, then check again. The preferred server should show its addresses and the provider should be recognised.
- Send yourself a test message from another domain and confirm it arrives.
Need inboxes for agents or automations? Ackuna Agent Mail gives each agent its own address and makes every incoming message available through the API, on our shared domain or, on paid plans, on your own domain.