Ports 25, 465, 587 and 2525: which should you use?

Port 587: submission with STARTTLS#

On port 587 the connection starts in plain text, and the client issues the STARTTLS command to upgrade to TLS before authenticating:

S: 220 smtp.provider.example ESMTP
C: EHLO app.example.com
S: 250-smtp.provider.example
S: 250-STARTTLS
S: 250 AUTH PLAIN LOGIN
C: STARTTLS
S: 220 Ready to start TLS
   ... TLS handshake, then EHLO again, then AUTH ...

The risk with STARTTLS is a downgrade: an attacker on the network path who strips the STARTTLS capability can trick a careless client into continuing in plain text. Configure your client to require TLS on 587 and fail if it is not available, rather than using opportunistic mode.

Port 465: submission over implicit TLS#

On port 465 the TLS handshake happens immediately, before any SMTP command, just as HTTPS works on 443. There is no plain-text phase to strip.

Port 465 has an odd history. It was briefly assigned for "SMTPS" in the 1990s, then revoked, but clients and servers kept using it. RFC 8314, published in 2018, formally registered port 465 for message submission over implicit TLS and recommends that clients prefer implicit TLS for submission where available. So despite older advice calling 465 "deprecated," it is now the standards-preferred option for submission.

In practice, both 587 with mandatory STARTTLS and 465 with implicit TLS are secure when configured correctly. Use whichever your provider supports; if both are available, 465 removes the downgrade question entirely.

Port 2525: the unofficial fallback#

Port 2525 is not registered for SMTP with IANA. Many email providers listen on it anyway, as an alternative for environments where 25, 465 or 587 are blocked by a hosting provider or a corporate firewall. Behavior differs by provider: some offer STARTTLS on 2525, some terminate TLS elsewhere, and some do not encrypt at all. Read your provider's documentation and check what it says about encryption before using it.

What to choose for your application#

If your provider documents a preferred port, use it. Otherwise, try 465 with implicit TLS first, fall back to 587 with mandatory STARTTLS, and use 2525 only when your hosting network blocks both. Whatever you pick, put the host, port and TLS mode in configuration rather than code, so you can switch without a deploy when a network policy changes.

Common mistakes#

• Mixing up implicit TLS and STARTTLS. Configuring a client for STARTTLS on port 465, or implicit TLS on 587, results in a hang or an immediate handshake error. In many libraries, "SSL" or "secure: true" means implicit TLS (port 465), and "TLS" or "STARTTLS" means upgrade (port 587).
• Allowing opportunistic STARTTLS on submission. Require TLS so credentials are never sent in clear text.
• Disabling certificate verification to "fix" a TLS error. Fix the hostname or trust store instead.
• Testing from a laptop on a network that blocks 25 and concluding the provider is down.

Testing a port#

You can check what a server offers with OpenSSL:

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

# STARTTLS on 587
openssl s_client -connect smtp.provider.example:587 -starttls smtp -crlf -quiet

After connecting, type EHLO test.example.com and check that the server lists AUTH mechanisms. Tools like swaks can run a full authenticated test send.

Key takeaways#

• Port 25 is for server-to-server relay; applications should submit on 587 or 465.
• Port 587 uses STARTTLS; require TLS rather than allowing a plain-text fallback.
• Port 465 uses implicit TLS and is the submission option RFC 8314 recommends.
• Port 2525 is an unofficial fallback; check how your provider handles encryption on it.
• Match your client's TLS mode to the port, and never disable certificate verification.