SMTP port 587 vs 465 - STARTTLS or implicit TLS?

Choosing the right SMTP port determines how encryption is negotiated between your client and the mail server. The four ports you will encounter, 25, 465, 587, and 2525, each have a specific role and encryption behavior. Picking the wrong port and security mode combination is one of the most common causes of connection timeouts and handshake failures.

A short history of ports 465 and 587

Port 25 was the original SMTP port, standardized in the early 1980s. For decades, every mail client submitted mail over it directly. As spam grew in the 1990s, the IETF split two jobs that had been sharing one port: relaying mail between servers, and submitting mail from a user or application to an outgoing server. RFC 2476, later revised as RFC 6409, assigned port 587 to submission, where authentication is expected.

Port 465 has a stranger history. It was assigned in 1997 for "SMTPS", SMTP over implicit TLS, as a transitional port while STARTTLS was being standardized. A year later the assignment was revoked in favor of STARTTLS on port 587. For roughly two decades 465 was officially unassigned, even though many providers and client libraries kept supporting it because implicit TLS proved simpler and less error-prone. In 2018, RFC 8314 made it official again, recommending implicit TLS on port 465 for submission.

So both 465 and 587 are valid submission ports endorsed by current RFCs. The difference is when the TLS handshake happens.

SMTP test port 587 - the modern submission standard

Port 587 is defined by RFC 6409 as the mail submission port. The connection starts in plain text, and the client upgrades it to TLS by sending the STARTTLS command after EHLO. Once the server responds 220 Ready to start TLS, both sides negotiate a TLS handshake and all subsequent data (including AUTH credentials) is encrypted.

Because the session begins in plain text, the server's greeting banner arrives before encryption. On an openssl session you see the 220 greeting, then the EHLO response listing STARTTLS, then the handshake. This ordering is what makes 587 flexible but also what creates the downgrade risk described later.

Key facts:

• Supported by virtually every current provider and MTA.
• Requires the client to explicitly request encryption via STARTTLS.
• If STARTTLS fails or is not advertised, the session remains unencrypted (unless the client enforces it, which SMTP Tester does when security is set to STARTTLS).
• This is the recommended default for apps, scripts, and mail clients.

SMTP test port 465 - implicit TLS (SMTPS)

Port 465 uses implicit TLS: the TLS handshake begins immediately when the TCP connection is established, before any SMTP commands are exchanged. The client connects, negotiates TLS, and only then sends EHLO. The first thing the server sends, the 220 greeting, is already inside the encrypted channel.

This ordering difference is visible when you test both ports on the same server. On 587, the STARTTLS command and the 220 2.0.0 Ready to start TLS reply appear in the transcript before the TLS metadata. On 465, the TLS metadata (protocol version, cipher suite, certificate) precedes any SMTP dialogue, since there is no plaintext phase.

Key facts:

• Originally assigned for SMTPS in 1997, revoked, then re-endorsed by RFC 8314 (2018).
• Functionally as secure as 587; the difference is only when TLS negotiation occurs.
• Some older clients and libraries default to this port for "SSL mode."
• Connect to 465 without a TLS handshake and the connection hangs, because the server expects the TLS ClientHello immediately.

Explicit vs implicit TLS, and what a downgrade attack looks like

The two models have names: STARTTLS on 587 is explicit TLS, and the handshake on 465 is implicit TLS.

With explicit TLS, encryption is an optional extension negotiated mid-session. That optionality is the historical weakness. A STARTTLS downgrade (or "stripping") attack works like this: a machine-in-the-middle attacker on the same network, for example an open Wi-Fi hotspot or a compromised router, intercepts the server's EHLO response and removes the 250-STARTTLS line. The client sees no STARTTLS advertisement, concludes the server does not support encryption, and proceeds in plain text, sending AUTH LOGIN with base64-encoded credentials the attacker reads directly. The client never errors out, which is what makes this attack quiet and dangerous.

Defenses against stripping:

• Client-side enforcement. A client configured to require STARTTLS aborts the session if the extension is missing.
• MTA-STS and DANE. These let a domain publish a policy stating that mail to it must use TLS, so senders refuse to fall back to plaintext. They mainly apply to server-to-server mail on port 25.
• Implicit TLS. With 465 there is nothing to strip. TLS starts before any SMTP data exists, so an attacker cannot tamper with a negotiation that never happens in the clear.

In practice, the negotiated TLS version and cipher suite determine the actual protection, visible in the TLS diagnostics panel of a test transcript for either port.

Test SMTP port 25 - server-to-server relay

Port 25 is the original SMTP port, now used primarily for server-to-server (MX) relay: one mail server delivering to another. It is not for authenticated submission from applications or end users.

Key facts:

• Most cloud providers (AWS, GCP, Azure, DigitalOcean) block outbound port 25 by default to prevent spam.
• Residential ISPs often block it too.
• Connections on port 25 are typically unauthenticated (the receiving server accepts mail for its own domains based on MX records).
• Some MTAs (Postfix, PowerMTA, KumoMTA) accept local injection on port 25 from trusted IPs without AUTH, but this should not be exposed to the internet without access controls.

Port 2525 - unofficial fallback

Port 2525 is not registered with IANA, but many transactional email providers (SendGrid, Mailgun, Brevo, Postmark, Mailjet) listen on it as a fallback when port 587 is blocked. It uses STARTTLS, exactly like 587; only the port number differs.

Use 2525 when your network or firewall blocks outbound 587, or when your hosting provider whitelists 2525 while restricting other outbound traffic.

Comparison table

Firewall and ISP behavior by port

Port reachability depends heavily on where you are connecting from:

Two practical consequences:

1. Debugging from a laptop on hotel Wi-Fi or a mobile hotspot, port 25 results tell you almost nothing. Test on 587 or 465.
2. Corporate networks that allow 587 sometimes route it through an SMTP proxy or DPI appliance. If your transcript shows a greeting banner that does not match the provider's real server, or a certificate issued by a proxy CA instead of a public CA, you are talking to a middlebox.

Which clients and libraries expect which port

Most modern clients support both ports but express them differently. Two conventions cause most misconfigurations:

• Port and security are separate settings. In many UIs (Thunderbird, Apple Mail) you pick a port and a connection security independently, so a mismatch is possible. Port 465 with "STARTTLS" selected will not work; the server is waiting for a TLS ClientHello, not an EHLO.
• Libraries often infer security from the port. In nodemailer, secure: true means implicit TLS on connect (port 465), while secure: false means plaintext that may be upgraded with STARTTLS. Setting secure: true while pointing at 587 produces a timeout; setting secure: false while pointing at 465 produces a hang, because the library sends plaintext into a TLS socket.

// Port 465: implicit TLS
const transport465 = nodemailer.createTransport({
  host: "smtp.example.com",
  port: 465,
  secure: true, // TLS on connect
  auth: { user: "user@example.com", pass: process.env.SMTP_PASS },
});

// Port 587: plaintext, then STARTTLS upgrade
const transport587 = nodemailer.createTransport({
  host: "smtp.example.com",
  port: 587,
  secure: false, // STARTTLS, not "no encryption"
  requireTLS: true, // refuse to send without STARTTLS
  auth: { user: "user@example.com", pass: process.env.SMTP_PASS },
});

You can reproduce both handshakes from a terminal with openssl s_client. The -starttls smtp flag is what differs:

# Implicit TLS on 465
openssl s_client -connect smtp.example.com:465 -quiet

# Explicit TLS on 587
openssl s_client -connect smtp.example.com:587 -starttls smtp -quiet

Running the STARTTLS variant against a 465 listener stalls, because the server never speaks plaintext. That is the same symptom as a secure: true / port 587 mismatch.

Quick decision guide by scenario

How to test both ports on the same server with SMTP Tester

Comparing 587 and 465 against the same host takes two runs and shows where the handshake models diverge.

1. Enter the host, port 587, and STARTTLS as the security mode. Add credentials if the server requires AUTH for submission.
2. Run the test and read the transcript. You should see the plaintext 220 greeting, the EHLO response advertising STARTTLS, the STARTTLS command, the 220 Ready to start TLS reply, then the TLS metadata.
3. Change only the port to 465. SMTP Tester auto-selects TLS (implicit) when you switch, matching the securityForPort default. Override it manually if your server is unusual.
4. Run again. This transcript starts with the TLS handshake and certificate details; there is no plaintext phase at all.
5. Compare the TLS panels from both runs. Protocol version, cipher suite, certificate subject, issuer, and days until expiry should be identical, since it is the same server certificate. If they differ, something between you and the server terminates TLS differently per port.

What the transcripts tell you:

• A 587 run with no STARTTLS line in the EHLO response means the server does not offer encryption on that port. Never send credentials over it.
• A 465 run that times out while 587 succeeds usually means a firewall is filtering 465, or the server is offering STARTTLS on 465.
• A 587 run that hangs right after connecting suggests the port is speaking implicit TLS. Switch the security mode to TLS.

What to do when a port is blocked

Symptoms of a blocked port:

• Connection timeout (no server greeting at all).
• "Connection refused" if the port is filtered at the server level.
• The transcript stops at "Connecting..." with no 220 response.

Steps to resolve:

1. Try port 465 if 587 times out (or vice versa).
2. Try port 2525, widely supported by transactional providers.
3. Check outbound firewall rules on your network or cloud instance.
4. Ask your hosting provider if they block outbound SMTP ports.
5. If you run your own MTA, verify the listener is bound to the public interface and the port is open in iptables/ufw/security groups.

Frequently asked questions

Is port 465 deprecated?

No. It was unassigned by IANA for many years, which is where the "deprecated" reputation comes from, but RFC 8314 (2018) re-endorsed it for submission with implicit TLS. Both ports are valid today.

Which is more secure, 587 with STARTTLS or 465 with implicit TLS?

Once the TLS handshake completes, they are equivalent. Implicit TLS is slightly harder to misconfigure because there is no plaintext phase an attacker can downgrade. If your client enforces STARTTLS, 587 is equally safe.

Why does my connection hang on port 465?

The server expects a TLS ClientHello as the very first bytes. If your client sends plaintext SMTP commands instead, the server never responds and the connection stalls. Switch the security mode to TLS, or from secure: false to secure: true in nodemailer.

Can I use port 25 for sending from my application?

Technically you can if your network allows it, but you should not. Port 25 is for server-to-server relay, it is commonly blocked, and providers treat authenticated submission on it as unusual.

Does port 2525 support TLS?

Yes. Providers that offer 2525 support STARTTLS on it, exactly like 587. It is a port-number fallback, not a different protocol.

My test works on 587 but my production server cannot reach the provider. What changed?

The network path, most likely. Production hosts often sit behind security groups, NAT rules, or egress proxies that differ from your workstation. Run the same test from the affected network, or ask your infrastructure team to confirm outbound access to the provider's submission ports.

Where to go next

• What is an SMTP test? - how a full SMTP test works, step by step
• Fixing SMTP authentication error 535 - when the port is reachable but credentials fail
• Gmail SMTP settings and how to test them - 587 with STARTTLS and app passwords in practice
• Amazon SES SMTP: how to test your credentials - region-specific hosts and multiple port options