What does your mail server actually say?

When email stops working, the useful question is what your mail server says to a client that connects to it. MailProbe opens a real SMTP connection, reads the banner, checks STARTTLS, and lists every advertised authentication mechanism — no terminal required.

How it works

1 Enter a hostname — the mail server you want to test, e.g. mx.example.com.
2 Choose a port — 25 (SMTP), 587 (Submission), or 465 (SMTPS).
3 MailProbe connects — opens a raw TCP socket, reads the server greeting, sends EHLO, and parses the capability list.
4 See the results — banner text, STARTTLS support, auth mechanisms, and handshake latency. The server's own protocol text, verbatim.
$ mailprobe mx.example.com 587
Connecting to mx.example.com:587...
220 mx.example.com ESMTP Postfix (Ubuntu)
EHLO mailprobe
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
Latency: 87 ms

What you get

Greeting banner — the server identifies itself. See the exact software and version it advertises on connect.
STARTTLS support — detects whether the server offers STARTTLS and shows the encrypted capability set after upgrade.
Auth mechanisms — lists every advertised SASL mechanism (PLAIN, LOGIN, CRAM-MD5, etc.). No credentials sent.
Handshake latency — measures how long the server took to respond, from connect to EHLO response.
No credentials stored — MailProbe reads public banners only. It never sends AUTH, never stores results.

Why a real connection?

DNS lookups and port scans can guess whether a server exists, but only a real SMTP handshake tells you what the server actually supports. MailProbe does what an admin would do by hand with telnet or openssl s_client — it just saves you the typing.

The tool connects on your behalf from a dedicated server. This is necessary because browsers cannot open raw TCP sockets, and SMTP is a line-based protocol, not HTTP.

What this is not