What this test does, precisely
Three things happen when you press the button. We resolve the hostname to an address and reject it if it lands on a private, loopback, or link-local range. We open a TCP connection to that address on the port you chose, with a six-second timeout. On the cleartext ports we then wait for the server to speak first, because SMTP, POP3, and IMAP are all server-greets-first protocols, and we show you the greeting verbatim.
That is the whole test. No EHLO is issued, no AUTH is attempted, no MAIL FROM is sent, and no message is delivered. Anything that claims to test "delivery" without credentials and a recipient is testing something else. What you get here is the answer to one narrow question — is the TCP path from a public network to this port clear, and what does the far end announce itself as — which happens to be the first question worth asking in almost every mail outage.
Which port to test, and why
| Port | Purpose | Encryption | Who connects |
|---|---|---|---|
| 25 | MTA-to-MTA relay (RFC 5321) | Opportunistic STARTTLS | Other mail servers delivering to you |
| 587 | Message submission (RFC 6409) | STARTTLS, AUTH required | Your users and applications |
| 465 | Submission over implicit TLS (RFC 8314) | TLS from the first byte | Your users and applications |
| 2525 | Unofficial alternate submission | Provider-dependent | Clients on networks that filter 587 |
| 110 / 995 | POP3 / POP3 over implicit TLS | STARTTLS / implicit | Mail clients retrieving mail |
| 143 / 993 | IMAP / IMAP over implicit TLS | STARTTLS / implicit | Mail clients retrieving mail |
Read the full explanation of smtp connection test results ↓Show less ↑
Test 25 when inbound mail is bouncing — that is the port other servers use to reach you. Test 587 or 465 when your own users or an application cannot send. Testing the wrong one produces a confusing result: plenty of correctly configured servers answer on 587 while deliberately refusing 25 from anywhere but their own network.
Reading the greeting banner
A healthy SMTP greeting looks like 220 mx.example.com ESMTP Postfix (Ubuntu). Break it into three parts. The 220 is the service-ready reply code. The hostname that follows is what the server calls itself — this should match its PTR record, because receivers that run forward-confirmed reverse DNS checks compare them. The trailing text names the software, which is useful for knowing what you are dealing with and, if you would rather not advertise it, is trivially suppressed in your MTA config.
- `220 …` — the server is ready. Normal.
- `421 …` — service unavailable, try later. The host is up but shedding load, in a maintenance window, or applying a connection-rate limit to our address.
- `554 …` — transaction failed at the greeting. Almost always means the connecting IP is blocked outright by that server's policy or a blocklist it consults.
- A banner naming a different host than you expected — you are hitting a spam-filtering gateway or a load balancer, not your mail server. Follow the MX records to see who is really in front.
- Connected but no greeting inside six seconds — usually a firewall that completes the TCP handshake and then drops the session, or a tarpit deliberately slowing suspicious connections.
What each failure mode actually means
Connection refused means a TCP RST came back: the host is reachable and something actively said no. Nothing is listening on that port, or a local firewall rejected rather than dropped the packet. Check that the service is running and bound to the public interface, not to 127.0.0.1.
Connection timed out means the packets vanished. A firewall is dropping them silently — the default behaviour of most cloud security groups and of ISP filtering. This is the signature of a blocked port 25: your provider has not refused you, they have quietly discarded the traffic. See the port 25 guide for how to confirm it and what your options are.
Host does not resolve means the DNS problem comes before any of this. Check the name with the A record lookup; if you typed an MX hostname, confirm it exists — MX records pointing at hostnames that do not resolve are a surprisingly common cause of total inbound mail failure.
Host resolves to a private address is rejected before we connect. That is deliberate: a public checker that will connect to 10.0.0.5 on request is an SSRF tool aimed at its own operator's network. Test internal hosts from inside your own network with telnet or openssl s_client.
Doing this by hand
The same test from your own machine, which is worth running because it tests your network path rather than ours:
# Cleartext ports (25, 587, 2525) — the server greets you first.
# openssl's -starttls flag also proves STARTTLS works, which telnet cannot.
openssl s_client -connect mail.example.com:587 -starttls smtp -crlf
# Implicit-TLS ports (465, 993, 995) — TLS begins immediately, no STARTTLS.
openssl s_client -connect mail.example.com:465 -crlf
# Bare reachability, no protocol:
nc -vz mail.example.com 25
# Full manual conversation once connected — type these lines:
# EHLO test.example.org
# QUITIf openssl s_client -starttls smtp succeeds it also prints the certificate chain, so you can confirm the name on the certificate matches the hostname — a mismatch is why some senders refuse to negotiate TLS with you and fall back to cleartext or defer. The SSL certificate checker covers the same ground for HTTPS.
What an open port does not tell you
This is the important limitation. A green result means the door opens. It says nothing about whether your mail will be accepted, because everything that determines acceptance happens after the greeting: the receiver evaluates your PTR record, your HELO name, your SPF and DKIM results, your DMARC alignment, your IP reputation, and finally the content. A server with a perfect banner on port 25 can still reject every message you send.
So use this test to eliminate the network layer, then move up the stack. Confirm reverse DNS with the PTR lookup, check whether your address carries a listing with the blacklist checker, and get the whole authentication picture in one pass with the deliverability snapshot.