Free SMTP Server Connection Test

What the SMTP greeting tells you

Almost every mail delivery problem is one of three things: the port is not reachable, TLS is not available where it should be, or authentication is not configured the way the client expects. All three are visible in the first two exchanges of an SMTP conversation, before any message is involved. That is what this test captures — it connects, reads the greeting, asks the server to introduce itself with EHLO, and reports what came back.

A successful greeting is a 220 response containing the server's hostname. It proves the port is open, nothing is filtering the connection, and the service behind it is actually SMTP. If you see a greeting, connectivity is not your problem and you can move on to authentication or DNS. If you do not, the distinction between a timeout and a refusal matters: a refusal means nothing is listening, while a timeout means packets are being dropped, which is a firewall.

Choosing the right port

• Port 25 — server-to-server relay. This is the port other mail servers use to deliver to you. Most cloud and residential providers block outbound 25 by default to limit spam, so a timeout here from a hosted environment is expected rather than surprising.
• Port 587 — the submission port, used by authenticated clients and applications sending through your server. It should always advertise STARTTLS, because credentials cross this connection.
• Port 465 — implicit TLS. The session is encrypted before the greeting is sent, so STARTTLS is not advertised and does not need to be.
• Port 2525 — an unofficial alternative widely supported by relay providers for environments where 25 and 587 are blocked.

Reading the capability list

The EHLO response is where a server declares what it can do, and the entries worth checking are few. STARTTLS means the plaintext session can be upgraded to an encrypted one; its absence on port 587 is a security problem, not a preference. AUTH lists the supported authentication mechanisms — if your client expects LOGIN and the server only advertises PLAIN, that mismatch is your failure. SIZE declares the maximum message the server will accept, which is the usual explanation for large messages with attachments failing while small ones succeed. 8BITMIME indicates the server handles 8-bit content without forcing an encoding conversion.

Why this test does not send mail

A public endpoint that could be made to send a message on request is an open relay, whatever the intent behind it. This test therefore stops at EHLO: it never issues MAIL FROM or RCPT TO, never authenticates, and never transmits a message body. As a side effect it also cannot be used to enumerate which mailboxes exist on someone else's server, which is a common abuse of tools in this category.

End-to-end verification — authenticating against your own server and actually delivering a test message — belongs in a tool you run yourself with your own credentials. That is the SMTP tester in PMTAcore, which tests all three ports with TLS and SSL, authenticates, sends a real message, and keeps a history of every test against every server you manage.

When the port is open but mail still does not arrive

A clean result here narrows the problem considerably: the transport works, so the failure is further up. The next two things to check are reputation and authentication. Confirm the sending IP is not listed using the blacklist checker, then confirm the domain publishes valid SPF, DKIM and DMARC with the SPF, DKIM and DMARC checker. Between those three tools you can distinguish a network problem from a reputation problem from a configuration problem, which is usually the hard part.