SMTP Server Test

🛡 Deliverability & security

Connect to a mail server and check its banner, EHLO extensions, STARTTLS, TLS version and certificate.

No sign-up required Runs on our own infrastructure Also available via API

Runs on our diagnostic API. We don’t attach your input to an account for these free tools; short-lived rate-limit/security logs may exist, and requests are rate-limited per IP.

When mail isn’t flowing and you’re not sure whether the problem is DNS, the server, or TLS, the quickest sanity check is to just talk to the mail server the way another mail server would. That’s what this tool does: it opens a real SMTP conversation, reads what the server announces about itself, negotiates encryption, and reports back — without ever handing over a message. Think of it as putting a stethoscope on your inbound mail path.

What actually happens on the wire

You give us a domain or a mail hostname. If it’s a domain, we resolve its MX records and connect to the highest-priority one. Then we walk through the opening moves of an SMTP (RFC 5321) session:

  1. Read the banner. A healthy server greets you with a 220 line naming itself, e.g. 220 mail.example.com ESMTP. A slow or missing banner is itself a signal — often a sign of greylisting or an overloaded host.
  2. Send EHLO, list the extensions. The server replies with the capabilities it supports — STARTTLS, SIZE, 8BITMIME, PIPELINING, AUTH and so on. The presence or absence of STARTTLS here is the single most important line for deliverability.
  3. Attempt STARTTLS. If offered, we upgrade the plaintext connection to TLS and inspect the negotiated TLS version and the server’s certificate — issuer, subject, expiry, and whether the name matches the hostname.
  4. Check reverse DNS. We note the server’s PTR record, since receivers care whether an SMTP host’s forward and reverse names agree.

We never send an actual email. The session stops after the handshake — no MAIL FROM, no RCPT TO, no DATA. This is a connectivity and TLS diagnostic, not a delivery test.

Ports 25, 465 and 587 — which is which

People conflate these constantly, and it matters. This tool checks port 25, because that’s the port servers use to talk to each other (mail transfer, MTA-to-MTA). The other two are for clients submitting outgoing mail:

  • Port 25 — server-to-server relay. How inbound mail reaches your MX. TLS here is opportunistic: the server offers STARTTLS and senders use it if present, but fall back to plaintext if not, because rejecting mail outright would break interoperability.
  • Port 587 — the modern submission port. Where your mail client or app authenticates and hands off outgoing mail. It also uses STARTTLS, but here TLS and authentication are typically required.
  • Port 465 — implicit TLS submission. Same job as 587, but the connection is encrypted from the very first byte (no plaintext STARTTLS upgrade step). Once deprecated, now standardised again and widely used.

Why opportunistic TLS on port 25 looks the way it does

Because port-25 encryption is best-effort, a lot of servers present TLS that would be rejected in a browser — self-signed certs, mismatched names, expired chains — and mail still flows. That’s by design: any encryption beats none against passive snooping. But it also means a passing SMTP test isn’t the same as a strictly-validated one. If you want enforced, authenticated transport encryption for inbound mail, that’s what DANE/TLSA (and MTA-STS) add on top — and DANE in turn depends on DNSSEC being in place.

Reading the results

A clean result shows a prompt 220 banner, STARTTLS in the EHLO list, a TLS 1.2 or 1.3 handshake, a certificate that hasn’t expired, and a PTR that matches. Red flags: no STARTTLS offered (inbound mail travels in the clear), a certificate expiring soon, or a banner hostname that has nothing to do with your reverse DNS. To see how this fits with the rest of your setup, run the aggregate Email Health Check, which folds SMTP, MX, and authentication into one score.

Frequently asked questions

Does this test send an email?
No. It reads the banner, EHLO extensions and STARTTLS/TLS certificate, then disconnects — it never issues MAIL FROM, RCPT TO or DATA. Nothing is sent.
What’s the difference between port 25, 465 and 587?
Port 25 is server-to-server relay (your MX, opportunistic STARTTLS). 587 and 465 are client submission ports for sending — 587 upgrades via STARTTLS, 465 is TLS from the first byte. This tool checks port 25.
The server offers a self-signed or expired certificate but mail still works. Is that a problem?
On port 25 TLS is opportunistic, so senders accept imperfect certs rather than fall back to plaintext. It works, but isn’t authenticated — enforce it with DANE/TLSA or MTA-STS.
Why does my server not offer STARTTLS?
Either TLS isn’t configured on the MTA, or something upstream is stripping the capability. Without it, inbound mail travels in plaintext. Enable TLS in your mail server config and re-test.