SMTP Server Test: Ports 25, 465, 587, STARTTLS, and TLS Certificates

What the SMTP Server Test Does

The mxio SMTP Server Test connects to an SMTP server on one or more ports, performs a TLS handshake (either via STARTTLS upgrade or implicit TLS), and reports what it finds: whether the port is open, what SMTP extensions the server advertises, whether TLS is supported and what version, and the full details of the server's TLS certificate.

This is a connectivity and configuration test, not a mail delivery test. It answers: "Is this SMTP server reachable, does it support encryption, and is its certificate valid?" It does not send email or test authentication credentials.

The Three SMTP Ports

SMTP uses three standard ports, each with a different role and a different TLS model. The tool tests all three by default.

Port 25: Relay

Port 25 is the original SMTP port, used for server-to-server email relay. When a sending mail server delivers a message to a receiving mail server, it connects on port 25. The connection starts in plaintext, and the server may advertise STARTTLS in its EHLO response to allow an encrypted upgrade.

Port 25 does not require authentication — it is designed for relay between mail servers, not for end users submitting email. This is why ISPs and cloud providers often block outbound port 25 from consumer and VM networks: to prevent spam.

Port 587: Submission

Port 587 is the designated mail submission port, defined in RFC 6409. Email clients (Outlook, Thunderbird, mobile apps) and applications use port 587 to submit outbound email to their mail server. The connection starts in plaintext, upgrades to TLS via STARTTLS, and then the client authenticates with credentials.

Port 587 requires authentication. This is the key difference from port 25: submission implies a trusted sender identity, while relay does not.

Port 465: Submission (Implicit TLS)

Port 465 was originally assigned for SMTPS (SMTP over SSL) in the 1990s, briefly deprecated, and then re-standardized in RFC 8314 as the implicit TLS submission port. Unlike ports 25 and 587, port 465 encrypts the connection from the first byte — there is no plaintext phase and no STARTTLS negotiation. The TLS handshake happens before any SMTP commands are exchanged.

Port 465 is functionally equivalent to port 587 with STARTTLS, but eliminates the window where an attacker could intercept the plaintext phase or strip the STARTTLS command.

STARTTLS vs. Implicit TLS

The tool reports which TLS model each port uses. Understanding the difference matters for troubleshooting.

STARTTLS (ports 25, 587): The connection starts in plaintext. The server advertises STARTTLS in its EHLO capability list. The client sends the STARTTLS command, the server responds with 220 Ready to start TLS, and both sides perform a TLS handshake. After the handshake, the SMTP session restarts over the encrypted channel.

The risk with STARTTLS is that the upgrade is optional by default. A network attacker positioned between the client and server can strip the STARTTLS advertisement from the EHLO response, forcing a plaintext connection. This is why MTA-STS and DANE exist — they let domains declare that TLS is mandatory and must be validated.

Implicit TLS (port 465): The TLS handshake happens immediately upon TCP connection, before any SMTP data is exchanged. There is no plaintext phase and no stripping attack surface. The server's SMTP banner is delivered inside the encrypted channel.

The tool reports starttls_supported: true for ports that use STARTTLS and implicit_tls: true for port 465.

Reading the Results

Connection and Banner

For each port, the tool reports whether the TCP connection succeeded and the SMTP banner the server returned. A healthy server responds with a 220 greeting:

220 mx1.example.com ESMTP ready

If the connection times out, is refused, or returns a non-220 response, the tool reports the specific error.

EHLO Capabilities

After connecting, the tool sends an EHLO command and reports the server's advertised capabilities. Common capabilities include:

If STARTTLS is absent from a port 25 or 587 server, the tool flags it as a warning — most modern mail servers should support TLS.

TLS Details

When TLS is successfully negotiated, the tool reports:

• TLS version — TLS 1.2 or TLS 1.3 are expected. Anything below TLS 1.2 is flagged as weak.
• Cipher suite — The negotiated encryption algorithm (e.g., TLS_AES_256_GCM_SHA384).
• Certificate subject and issuer — Who the certificate was issued to and by whom.
• Subject Alternative Names (SANs) — The hostnames the certificate covers.
• Expiry date and days remaining — Certificates expiring within 30 days are flagged as warnings. Expired certificates are flagged as errors.
• Chain validation — Whether the certificate chain validates against trusted root CAs.
• Hostname match — Whether the certificate's CN or SANs match the hostname you tested.
• Self-signed detection — Self-signed certificates are noted. They work for opportunistic TLS but fail strict validation.

What Certificate Warnings Mean

Certificate expired — The certificate's notAfter date has passed. Most receiving servers will still negotiate TLS with an expired certificate under opportunistic mode, but servers enforcing MTA-STS or DANE will reject the connection.

Certificate expiring soon — The certificate expires within 30 days. Automate renewal with ACME (Let's Encrypt) to prevent outages.

Hostname mismatch — The certificate was issued for a different hostname than the one you tested. This commonly happens when a mail server uses a certificate for mail.example.com but the MX record points to mx1.example.com. Under opportunistic TLS, most servers accept mismatched certificates. Under strict validation, the connection fails.

Self-signed — The certificate was not issued by a trusted CA. Self-signed certificates provide encryption but not identity verification. They work for server-to-server relay under opportunistic TLS but will fail MTA-STS and DANE validation.

Chain validation failed — The server did not present a complete certificate chain. The fix is to configure your mail server to send the full chain (server certificate + intermediate certificates).

When to Use This Tool

The SMTP Server Test tells you about the server's connectivity and TLS posture. It does not tell you about DNS configuration (use MX Lookup), sender reputation (use Blacklist Check), or mail delivery results (use Header Analyzer).

For a complete picture of an email server, combine the SMTP Server Test with a PTR Lookup (reverse DNS), MX Lookup (mail routing), and Blacklist Check (reputation).

Test your SMTP server