Mail targets
Priority Host TTL
No MX targets or direct hosts were returned.
SMTP Test
Preflight mail-routing targets before a real SMTP connectivity test.
Use SMTP Test to discover the live MX targets for a mail domain or resolve a direct SMTP host so you can choose the right endpoint before testing an actual SMTP handshake from a backend, terminal, or monitoring worker.
This page checks the DNS side of SMTP troubleshooting. Browsers cannot open raw SMTP connections.
Test result
example.com
MX TARGETS FOUND
Resolved addresses
Host Address TTL
No A or AAAA records were returned for the selected targets.
What this SMTP Test tool does
SMTP Test on this page performs a DNS preflight for mail delivery. It resolves MX records for a mail domain or resolves a direct SMTP hostname so you can identify the correct target before running a real SMTP handshake elsewhere.
Use it to confirm which hosts currently receive mail, inspect priority order, and see whether those hosts resolve to public addresses.
It does not open TCP port 25, 465, or 587 from the browser. A true SMTP banner, STARTTLS, or authentication test still requires a backend, CLI, or monitoring worker.
When to use this tool
Mail delivery is failing and you need to confirm which SMTP targets the domain currently publishes.
A mail provider migration happened recently and you want to see whether the new MX targets are visible.
You want a quick preflight before running a real SMTP socket test from a backend, terminal, or monitoring system.
You need to separate DNS mail-routing issues from SMTP service issues.
An app or relay expects a direct SMTP hostname and you want to confirm that host resolves in DNS.
You need the exact MX priority order and resolved hosts before continuing mail troubleshooting.
How to use SMTP Test
- Enter a mail domain or direct SMTP hostname.
- Run the preflight and review the returned MX targets or direct host resolution.
- Check the advertised hostnames, priorities, and resolved addresses.
- Use the output to choose the endpoint you want to test with a real SMTP client.
- If the result looks wrong, continue to MX Lookup, DNS Lookup, or propagation checks next.
How to interpret SMTP preflight results
MX targets found
Likely meaning: The domain publishes one or more MX records and the browser could resolve the advertised mail hosts.
Common causes: This usually means the DNS layer for inbound mail routing is visible.
Next action: Continue to a real SMTP socket test from a backend or terminal if delivery still fails.
Direct SMTP host resolved
Likely meaning: No MX targets were used, but the supplied hostname resolved to at least one address.
Common causes: This often happens when you are testing a direct relay or provider hostname rather than a mail domain.
Next action: Use the resolved host for a real SMTP handshake test outside the browser.
No target found
Likely meaning: The lookup returned no MX targets and no direct host addresses.
Common causes: The domain or hostname may be wrong, DNS may be incomplete, or the mail service may not be published correctly.
Next action: Check MX Lookup, DNS Lookup, and nameserver delegation next.
Browser limitation
Likely meaning: This page can preflight mail-routing targets, but it cannot open SMTP connections from the browser.
Common causes: Browsers do not expose raw SMTP socket access for security reasons.
Next action: Use this output to choose the correct host, then run a true SMTP test from a backend, CLI, or monitoring worker.
NXDOMAIN
Likely meaning: The queried domain or host does not exist in DNS.
Common causes: Typos, wrong hostnames, or expired domains are common reasons.
Next action: Confirm the exact domain or hostname and rerun DNS Lookup.
SERVFAIL or timeout
Likely meaning: The recursive resolver could not complete the DNS preflight cleanly.
Common causes: DNSSEC failures, broken delegation, or authoritative DNS problems can interrupt the lookup.
Next action: Verify nameservers and DNSSEC before assuming the SMTP server itself is at fault.
Common SMTP issues this tool helps uncover
MX records point to the wrong provider after a migration
No MX records published for a domain that should receive email
Direct SMTP hostnames that do not resolve publicly
Resolver-visible DNS looks correct, but SMTP still needs a real socket test
Recent mail-routing changes not yet visible across recursive resolvers
Nameserver or DNSSEC issues mistaken for SMTP service failures
Confusion between the mail domain and the actual SMTP relay hostname
Next steps after SMTP Test
Run MX Lookup
Use this to inspect the mail-routing records in more detail if the preflight finds unexpected targets.
Check SPF, DKIM, and DMARC
Once the SMTP targets look correct, continue with email-authentication records.
Check DNS propagation
Use this when SMTP or MX changes were made recently and different resolvers may still disagree.
Run DNS Lookup
Inspect the broader DNS view for the same mail domain or host if you need more context.
Related tools
MX Lookup
Inspect mail exchange records and delivery destinations for a domain.
SPF Check
Review SPF records and authorized sending sources for a domain.
DKIM Check
Validate DKIM selectors and public keys for signed email.
DMARC Check
Inspect DMARC policy, alignment, and reporting configuration.
DNS Lookup
Query A, AAAA, CNAME, TXT, and other DNS records for a domain.
DNS Propagation Check
Verify whether recent DNS changes are visible across resolvers.
SMTP Test FAQ
What does SMTP Test do on this page?
It performs a DNS preflight for mail delivery by checking MX targets for a domain or resolving a direct SMTP hostname. It does not open a real SMTP socket from the browser.
Can this page run a real SMTP handshake?
No. Browsers cannot make raw SMTP connections, so this page focuses on the DNS-side precheck and target discovery needed before a true SMTP test.
What input should I enter?
Enter a mail domain like example.com or a direct SMTP host like mail.example.com. If you paste an email address, the tool uses the domain part.
Why are MX records shown instead of an SMTP response code?
MX records tell you where mail should go. A real SMTP response code requires a backend or terminal-based socket test, which browsers cannot perform directly.
What should I check after this preflight?
Usually MX Lookup, SPF, DKIM, DMARC, propagation, or a real SMTP handshake from a backend depending on what looks wrong.
What does it mean if the host resolves but mail still fails?
That usually means DNS is not the blocker and you should move next to SMTP connectivity, banner, TLS, authentication, or mailbox acceptance checks outside the browser.