Port 465 and 587: SMTP with TLS

When you configure an email client to send messages, you're asked to choose between port 465 and port 587. Both handle encrypted SMTP. Both work. But they have a strange history that explains why this choice exists at all.

The Port That Refused to Die

Port 465 was designated for encrypted SMTP in the late 1990s. It used implicit TLS—the connection was encrypted from the first packet, no negotiation required.

Then in 1998, the Internet Assigned Numbers Authority revoked the assignment. Port 465 was reassigned to an entirely different service. The official replacement was port 587, which used a different approach: start unencrypted, then upgrade to TLS using a command called STARTTLS.

There was just one problem. Millions of email clients were already configured to use port 465. And those users didn't care what IANA said. They kept using it. Email providers kept supporting it. The officially dead port outlived the officially blessed one—a twenty-year standoff between what the standards said and what the Internet actually did.

In 2018, IANA surrendered. RFC 8314 formally resurrected port 465 for encrypted email submission and actually recommended it over port 587 when both are available.

How They Differ

Port 587: Explicit TLS (STARTTLS)

Your client connects unencrypted. The server announces its capabilities, including STARTTLS support. Your client says "let's encrypt this," and both sides negotiate a TLS connection. Only then do you authenticate and send your message.

The vulnerability: that initial unencrypted exchange. An attacker positioned between you and the server could strip the STARTTLS announcement, causing your client to send credentials in plaintext. This is called a downgrade attack. Well-configured clients refuse to continue without encryption, but the attack window exists.

Port 465: Implicit TLS

The TLS handshake begins immediately. No unencrypted phase. No STARTTLS negotiation. No downgrade attack window. The connection is encrypted from the first byte.

This is why RFC 8314 recommends implicit TLS when available—it eliminates an entire class of attacks by design rather than configuration.

Which Port to Use

Check your email provider's documentation first. They'll tell you which port they prefer.

If you're choosing without guidance:

• Port 587 with STARTTLS works everywhere. It's the most compatible choice. If one port is going to work, it's this one.

• Port 465 with implicit TLS is more secure by design and increasingly recommended. Gmail, Outlook, and most major providers support it.

• Port 25 is for server-to-server communication. Don't use it for email clients. Most ISPs block it anyway to prevent spam.

Configuration Settings

Email clients use confusing labels. Here's what they mean:

Always enable authentication. Both ports require it on modern servers.

If connections fail, your network might be blocking one port. Corporate networks and public Wi-Fi often block 465 while allowing 587, or vice versa. Try the other port.

The Broader Pattern

The port 465 saga reflects a larger shift in how the Internet thinks about security. The old model: encryption is optional, negotiated after connection. The new model: encryption is mandatory, built in from the start.

STARTTLS was a reasonable compromise in 1998. Start compatible, upgrade when possible. But "when possible" created too many opportunities for things to go wrong—or be made to go wrong. Implicit TLS says: there is no unencrypted option. The connection is secure or it doesn't happen.

Both ports work reliably today. But the resurrection of port 465 after twenty years in the wilderness tells you which direction things are heading.