SSL TLS Protocols: Ports, Differences & Best Practices

Most developers know that port 443 means “secure web” and port 587 means “secure email submission” — but the layers underneath trip people up all the time. The terms SSL, TLS, STARTTLS, HTTPS, and implicit versus explicit encryption get mixed together in ways that cause misconfigured servers and weak security choices. This article sorts through those distinctions using authoritative sources and concrete port-by-port recommendations.

HTTPS Standard Port: 443 · SMTP TLS Submission Port: 587 · Legacy SMTP SSL Port: 465 · TLS Successor To: SSL · Common Alt HTTPS Port: 8443

Is 587 TLS or SSL?

Port 587 is a TLS port, not an SSL port. Email clients connecting to this port begin with a plain SMTP handshake and then upgrade the connection to TLS encryption using the STARTTLS command. This is called explicit TLS — the upgrade is negotiated rather than assumed from the start of the connection.

Port 587 for SMTP Submission

Port 587 became the standard for authenticated email submission in the early 2000s. Unlike port 25, which is restricted to server-to-server relay across most networks, port 587 requires authentication from the sending client and supports TLS encryption. MailerSend’s analysis confirms that port 587 remains the recommended submission port for most email sending configurations today.

TLS Wrapper on Port 587

The STARTTLS command on port 587 tells the receiving server “I want to upgrade this connection to TLS.” If the server supports it, both sides agree on a cipher suite and the traffic is encrypted. If the server does not support STARTTLS, the connection falls back to plaintext — which is why some environments prefer implicit TLS on port 465 instead. Cloudflare’s SMTP security guide notes that this opportunistic encryption model makes port 587 widely supported but not as robust against downgrade attacks as implicit TLS.

What SMTP port should be used? Port 25, 587, or 465?

Choosing the right SMTP port depends on whether you are sending server-to-server, submitting mail on behalf of a user, or setting up a dedicated encrypted channel. Each port implies a different level of security, authentication, and ISP cooperation.

Port 25: Relay Basics

Port 25 handles raw SMTP relay between mail servers. It was the original SMTP port and remains the backbone of email transport across the internet. However, most residential ISPs and cloud providers block port 25 to reduce spam. The connection on port 25 is typically unencrypted by default unless both servers explicitly negotiate TLS. Mailtrap’s port breakdown confirms that port 25 is reserved for server-to-server relay and should not be used for client email submission.

Port 587: Secure Submission

Port 587 is the standard for email submission by end-user clients. It requires authentication credentials and supports STARTTLS encryption. The vast majority of email service providers and mail client applications default to port 587 for outgoing mail. Cloudflare confirms that port 587 is widely supported across email platforms and remains the baseline for secure submission.

Port 465: Legacy SMTPS

Port 465 was originally assigned for SMTPS — implicit TLS from connection start. IETF deprecated this usage in 1998, then reconsidered and approved it again in recent years. Today port 465 is the preferred choice for new SMTPS deployments because it encrypts immediately without any plaintext handshake window. Cloudflare’s security team states that port 465 offers better protection against certain attack vectors compared to STARTTLS on port 587.

Is 443 TLS or SSL?

Port 443 is exclusively a TLS port in any modern context. SSL 2.0 and earlier versions were never deployed on port 443 at scale, and SSL was formally deprecated for web traffic long before browsers started enforcing encrypted connections. When you visit a site over HTTPS, you are using TLS on port 443 — almost certainly TLS 1.2 or TLS 1.3.

Port 443 for HTTPS

HTTPS means HTTP over TLS, and port 443 is the default assigned port for this combination. The encryption begins immediately upon TCP connection establishment — there is no plaintext phase, no STARTTLS negotiation. Flarexes’ protocol history confirms that HTTPS uses TLS implicitly on port 443, meaning the encryption wrapper is built into the connection from the first packet.

Modern TLS Implementation

TLS 1.3 (RFC 8446) streamlined the handshake to just two round trips — half the latency of TLS 1.2. Major browsers enabled TLS 1.3 by default starting in 2020, and it is now the dominant cipher suite for encrypted web traffic. AWS’s technical comparison confirms that TLS handshake performance is significantly faster than the older SSL process, which required multiple round trips and complex negotiation steps.

Is SSL/TLS the same as HTTPS?

SSL and TLS are transport-layer encryption protocols. HTTPS is an application-layer protocol that uses TLS as its encryption layer. The distinction matters because SSL and TLS can encrypt many protocols beyond HTTP — SMTP, IMAP, POP3, FTP, and others — while HTTPS specifically refers to HTTP running over TLS.

HTTPS Layer on TLS

HTTPS = HTTP + TLS. The HTTP specification defines how browsers and servers exchange requests and responses. The TLS specification defines how those bytes are encrypted in transit, authenticated via certificates, and protected against tampering. Cloudflare notes that SMTPS follows the same pattern as HTTPS — the application protocol (SMTP) runs over an encryption layer (TLS) rather than over a raw TCP socket.

Key Differences

The critical difference between SSL and TLS lies in their cryptographic foundations. SSL uses MACs (Message Authentication Codes) for integrity checking and sends alerts in plaintext. TLS uses HMACs, encrypts alerts, and supports a wider range of cipher suites including AES-256. AWS confirms that TLS’s encrypted alerts and HMAC-based integrity checks provide substantially stronger protection than SSL’s original design.

Why is SSL no longer used?

SSL is no longer used because it has structural vulnerabilities that cannot be patched. The protocol itself — not just individual cipher suites — is fundamentally weaker than TLS. Organizations still running SSL are leaving themselves open to known attacks that have been obsolete in TLS for over two decades.

SSL Vulnerabilities

SSL 2.0 was released in 1995 by Netscape and contained flaws that allowed man-in-the-middle attacks. SSL 3.0 followed in November 1996, addressing some of these issues, but the protocol remained vulnerable to cryptographic downgrade attacks. The POODLE attack (discovered in 2014) specifically exploited SSL 3.0’s block cipher padding, forcing browsers and servers to drop SSL 3.0 support entirely. Acunetix’s protocol timeline documents that SSL 3.0 was formally deprecated the same year POODLE was disclosed.

TLS as Secure Successor

TLS 1.0 arrived in 1999 as RFC 2246, essentially standardizing SSL 3.0 under IETF governance. Each subsequent TLS version — 1.1, 1.2, and 1.3 — closed specific vulnerabilities: explicit IVs, cipher suite preferences, and zero-round-trip resumption. TLS 1.3, published as RFC 8446 in 2018, eliminated obsolete features entirely and reduced handshake latency. Feisty Duck’s standards history notes that TLS 1.3 required a decade of development after TLS 1.2 to achieve its simplified design.

Protocol and Port Reference

Three protocols, six ports, and two encryption models — the full picture in one view.

“The only difference between the two is that TLS evolved out of SSL technology and is a more secure version of SSL.”

— Comodo Blog (SSL/TLS security analysis)

“Port 465 is today the recommended choice for SMTPS, as it uses Implicit TLS and offers better protection against certain attacks.”

— Cloudflare (Cloud security provider)

“SSL 2.0 was the first version of SSL deployed on the public internet.”

— Flarexes (Security protocol analysis)

For developers configuring email infrastructure today, the choice is clearer than it was five years ago: use port 465 with implicit TLS for new deployments, fall back to port 587 with STARTTLS for maximum compatibility, and disable SSL on every service that supports it. The TLS ecosystem has settled on strong defaults — the remaining risk comes from configurations that have not been updated since the POODLE era. Staying current means auditing your cipher suites, enforcing TLS 1.2 minimum, and watching for TLS 1.3 adoption in your client base. Cloudflare and AWS both confirm that the TLS handshake improvements and cipher suite hardening in TLS 1.3 make the upgrade worthwhile for most environments.