If you need to test whether a mail server supports STARTTLS, use command-line verification plus release-gate tests.

Quick answer

A server supports STARTTLS when:

  1. it advertises in capabilities
  2. it returns after the command
  3. TLS handshake succeeds and SMTP session can continue securely

Method 1: OpenSSL one-liner

Use OpenSSL for a direct STARTTLS probe:

What success looks like:

  • certificate chain and negotiated TLS details are shown
  • server accepts post-handshake
  • SMTP commands proceed without plaintext downgrade

Method 2: Capability check before upgrade

You can inspect capabilities manually:

If is missing, STARTTLS is not available on that endpoint/port.

Method 3: End-to-end STARTTLS session probe

Important: after TLS negotiation, run again to refresh capability negotiation in encrypted mode.

Common STARTTLS test failures

Server requires TLS before auth. Enable STARTTLS in client config.

Handshake fails with certificate errors

Certificate chain, hostname, or trust-store mismatch.

not advertised on selected port

Wrong endpoint or port. Validate provider docs and transport mode.

Auth works locally but fails in production

Environment mismatch in port/TLS settings, auth policy, or network egress controls.

STARTTLS validation checklist for release gates

  1. Confirm capability includes .
  2. Confirm returns .
  3. Confirm cert validity and hostname match.
  4. Confirm post-TLS + flow works.
  5. Confirm send/receive assertions in staging and CI.

Use these routes for full workflow validation:

FAQ

Is STARTTLS the same as SMTPS?

No. STARTTLS upgrades a plaintext session; SMTPS starts encrypted immediately (commonly port ).

Should I use STARTTLS on port 465?

Usually no. Port typically expects implicit TLS, not STARTTLS upgrade.

Is capability advertisement enough to trust transport security?

No. You must also verify TLS handshake, certificate validity, and post-handshake SMTP behavior.

Next steps