SMTP TLS vs STARTTLS: Port 465 or 587?

Pick the wrong SMTP port and you either lose encryption silently or you fail to connect at all. The debate over SMTP TLS vs STARTTLS is really a debate over two delivery contracts: port 465 wraps the entire session in TLS from byte zero, and port 587 starts in cleartext and upgrades with the STARTTLS verb. Both are standardized, both are in production, and they behave differently when something goes wrong.

This article walks through the handshake on each port, explains why STARTTLS on port 25 is downgrade-prone, and ends with a decision section so you can lock in the right transport for transactional mail.

The two SMTP transport models

SMTP has supported encryption in two distinct ways for more than two decades.

• Implicit TLS (SMTPS) opens the TCP connection and immediately performs a TLS handshake. No SMTP commands are sent in cleartext. The convention is port 465.
• STARTTLS opens the connection in cleartext, exchanges an EHLO, and then issues the STARTTLS command (RFC 3207) to upgrade the same socket to TLS. The conventional ports are 587 for submission and 25 for relay between MTAs.

The handshake difference is the whole story. With implicit TLS, the server cannot accept any SMTP traffic until TLS is established, so the channel cannot be downgraded by an active attacker who strips a command. With STARTTLS, the upgrade is opportunistic, and an attacker who can rewrite the cleartext portion of the session can convince either side that encryption is unavailable.

How port 465 negotiates

The client opens TCP to port 465 and the server immediately presents its certificate. Only after the TLS record layer is established does the SMTP banner appear inside the encrypted channel.

You can watch the full handshake with openssl:

openssl s_client -connect smtp.example.com:465 -servername smtp.example.com -crlf

Once the handshake completes you should see the 220 smtp.example.com ESMTP banner inside the TLS session, not before it. If you ever see SMTP text before the TLS handshake on port 465, the server is misconfigured.

How port 587 negotiates

Port 587 is the submission port (RFC 6409). The session starts in cleartext, the client greets the server with EHLO, the server advertises STARTTLS in its capability list, and then the client upgrades:

220 smtp.example.com ESMTP ready
EHLO client.example.net
250-smtp.example.com
250-STARTTLS
250-AUTH PLAIN LOGIN
250 SIZE 52428800
STARTTLS
220 2.0.0 Ready to start TLS

After the 220 Ready to start TLS reply, both sides perform the TLS handshake on the same socket. Any commands sent before STARTTLS are in cleartext and must be discarded by the server after the upgrade; that reset is mandated by RFC 3207 and prevents command injection across the boundary.

You can drive that handshake from the command line:

openssl s_client -connect smtp.example.com:587 -starttls smtp -servername smtp.example.com -crlf

The -starttls smtp flag tells openssl to speak just enough SMTP to issue EHLO and STARTTLS before the TLS handshake.

Why port 25 STARTTLS is downgrade-vulnerable

Port 25 is the inter-MTA relay port. It also supports STARTTLS, but the SMTP banner and the capability list on port 25 are transmitted in cleartext, and there is no out-of-band signal that encryption is required. An active attacker sitting between two MTAs can do any of the following:

• Strip the advertisement. Remove 250-STARTTLS from the EHLO response. The sending MTA sees a server with no TLS support and falls back to a cleartext session.
• Reject the upgrade. Replace the 220 Ready to start TLS response with a 454 TLS not available error. Sending MTAs are required to continue without TLS on a hard failure.
• Forge the certificate. Most MTA-to-MTA TLS is opportunistic and does not validate the certificate against the recipient domain, so a self-signed cert from a man-in-the-middle is accepted silently.

The result is that two servers that both support TLS may end up exchanging your mail in cleartext, and neither end sees an error. This is not theoretical; passive monitoring of SMTP traffic has repeatedly shown stripped STARTTLS advertisements at ISP and transit-network boundaries.

MTA-STS as the modern fix

MTA-STS (RFC 8461) is the standardized counter-measure. The recipient domain publishes an HTTPS policy file declaring that its MX hosts require TLS, and a DNS TXT record points senders at that policy:

_mta-sts.example.com.   IN TXT  "v=STSv1; id=20240101T000000;"

The policy itself lives at https://mta-sts.example.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mail.example.com
mx: *.example.net
max_age: 604800

A sending MTA that supports MTA-STS fetches the policy over HTTPS (which is itself authenticated via the web PKI), caches it, and refuses to deliver mail to the listed MX hosts unless STARTTLS succeeds with a valid certificate matching the MX name. A stripped STARTTLS advertisement now causes a hard delivery failure instead of a silent downgrade, and the failure can be reported through TLS-RPT (RFC 8460).

If you operate a receiving domain, publish an enforce-mode MTA-STS policy and a TLS-RPT record. If you operate a sending MTA, honour cached MTA-STS policies. SESMetric does both for outbound mail on your behalf.

What clients and MTAs expect on each port

The ports carry conventions, not just transports, and middleboxes enforce those conventions.

Port	Role	Encryption	Auth required	Typical client
25	MTA-to-MTA relay	Opportunistic STARTTLS	No	Postfix, Exim, sendmail
465	Submission	Implicit TLS	Yes (SMTP AUTH)	Apps, libraries, MUAs
587	Submission	STARTTLS upgrade	Yes (SMTP AUTH)	Apps, libraries, MUAs
2525	Submission (unofficial)	Usually STARTTLS	Yes	Fallback when 25/465/587 are blocked

A handful of practical points:

• Residential ISPs and cloud providers routinely block outbound port 25 to suppress spam. If your code uses port 25 from a developer laptop or an EC2 instance, expect connections to hang. Always use 465 or 587 for submission.
• Port 587 must reject any MAIL FROM issued before a successful STARTTLS and AUTH exchange. Modern submission servers also reject AUTH over a cleartext channel.
• Port 465 was deregistered, then re-registered as the standard submission-over-TLS port in RFC 8314. It is no longer "legacy" — it is the implicit-TLS counterpart to 587.
• Most SMTP libraries pick the right behaviour from the port: smtplib.SMTP_SSL("host", 465) in Python, secure: true on port 465 with Nodemailer, or mail.smtp.ssl.enable=true in JavaMail. Mixing the wrong wrapper with the wrong port gives the cryptic wrong version number or unknown protocol errors during the handshake.

RFC 8314 and the deprecation of cleartext submission

RFC 8314, published in 2018, formalised the position that mail submission and access protocols must use TLS. The relevant points for SMTP:

• Implicit TLS on port 465 is the recommended default for submission. Port 587 remains valid but must require STARTTLS before any authentication.
• Cleartext submission is deprecated. Servers should refuse AUTH and MAIL FROM on a session that has not negotiated TLS.
• Clients should prefer implicit TLS when both are offered, because it eliminates the cleartext greeting where a downgrade or fingerprinting attack could occur.

RFC 3207, which defined the STARTTLS extension in 2002, is still in force and still correct; RFC 8314 simply makes the security expectations around it explicit and elevates port 465 from convention to standard.

If you are choosing transports today, treat RFC 8314 as the baseline. Anything that lets a credential or message body cross the wire in cleartext, even briefly, is non-compliant.

Which should you pick?

For a transactional sender talking to a relay (SESMetric, AWS SES, Postmark, your own MTA), the choice between SMTP TLS vs STARTTLS comes down to three questions.

• Do you control the client library and want the smallest attack surface? Use port 465 with implicit TLS. The connection is encrypted before any SMTP byte is exchanged, so there is no cleartext window for a network attacker to manipulate. This is the RFC 8314 default and what SESMetric recommends for new integrations.
• Are you constrained by an older library, a corporate proxy, or an environment that only allows port 587? Use port 587 with STARTTLS. It is fully supported and, with a properly configured client, is functionally equivalent on submission. Make sure your client enforces TLS (does not silently fall back) and validates the server certificate against the submission hostname.
• Are you running an MTA that relays between domains? You will use port 25 with opportunistic STARTTLS, because that is the only protocol the public internet speaks. Mitigate the downgrade risk by honouring MTA-STS policies on outbound, publishing one on inbound, and emitting TLS-RPT reports so you can see failures.

A short rule of thumb: 465 for apps, 587 if 465 is blocked, 25 only for relay, and never cleartext. For SESMetric customers, both 465 and 587 are available on smtp.sesmetric.com with valid certificates and SMTP AUTH; pick the one your stack handles cleanly and move on.

Once you have the transport sorted, the next deliverability step is authenticating the messages themselves — see the SESMetric guides on SPF, DKIM, and DMARC for that.