SMTP Test
Resolve a domain's mail servers and probe SMTP.
Enter a domain to find its mail servers and try a connection to the primary host. We look up the MX records and open a connection over an encrypted path. Nothing is stored.
The SMTP Test resolves a domain's mail servers and checks how they are set up to receive mail. It looks up the MX records to find which hosts accept mail for the domain, reports their preference order, and confirms each host resolves to an IP address. This tells you, quickly, whether a domain is configured to receive email at all and where that mail is routed.
What it can and cannot probe
This tool runs on Cloudflare Workers, which cannot open outbound connections on port 25. That means it cannot perform a live SMTP handshake (the HELO/MAIL FROM/RCPT TO conversation) the way a traditional command-line test would. We are honest about that limitation rather than pretending otherwise. What it does check is reliable: MX presence and priority, hostname resolution, and the surrounding records that affect mail delivery.
Reading the result
- No MX records: the domain cannot receive mail. Some senders fall back to the
Arecord, but a missing MX is usually a misconfiguration. - Multiple MX records: the lowest preference number is tried first; the others are backups. Make sure each one resolves.
- MX pointing at a hostname with no address: mail to that priority will fail; fix the host's
A/AAAArecord.
Fixing common problems
If mail is bouncing, confirm the MX hosts exist and resolve, check that your provider's records match their documentation, and verify SPF authorises those same servers to send. To prove a server actually accepts mail on port 25 you will need a tool that can open that port directly from your own network. For inbound security, pair healthy MX records with MTA-STS and TLS-RPT, covered on our requirements page.
Frequently asked questions
Why can't this tool complete a full SMTP handshake?
The tool runs on Cloudflare Workers, which block outbound connections on port 25. A full handshake requires opening that port to the mail server, so the test reports MX and DNS resolution instead. To verify a live SMTP conversation, use a client such as swaks or telnet on port 25 from a network that permits it.
What is an MX record and why does the order matter?
An MX record names the mail server that accepts email for a domain. When several exist, the one with the lowest preference number is tried first and the higher numbers act as backups. Sending servers honour this order, so a misconfigured priority can route mail to the wrong host.
What does it mean if a domain has no MX records?
It usually means the domain is not set up to receive email. Per the standards a sender may fall back to the domain's A record, but most modern mail systems treat a missing MX as a delivery failure, so you should publish a proper MX record.
My MX record exists but mail still bounces. What now?
Check that the hostname in the MX record resolves to a valid A or AAAA address, and that the server actually listens on port 25. Also confirm your firewall and provider settings allow inbound SMTP. A correct MX is necessary but not sufficient if the host behind it is unreachable.
Does this test check whether I can send email?
Not directly. MX records govern receiving mail. To check that you can send, verify your SPF record authorises the right servers, that DKIM is signing your messages, and that DMARC is published. Our tools cover each of those.
Should the MX hostname point at an IP address directly?
No. An MX record must point at a hostname, not an IP address, and that hostname must have its own A or AAAA record. Pointing an MX at an IP literal is invalid and many senders will refuse to deliver to it.