Is port 465 deprecated?

No, not any more. It was de-registered in 1998 in favour of STARTTLS on 587, which is why older documentation calls it obsolete. RFC 8314 formally reinstated it in 2018 under the service name "submissions" and recommends implicit TLS as the preferred submission mechanism. Both 465 and 587 are current and correct.

Is 465 more secure than 587?

Marginally, and only against one specific attack. Because TLS starts before any SMTP command is exchanged, there is no plaintext capability list for an on-path attacker to strip. On 587, a client that merely prefers STARTTLS rather than requiring it can be downgraded to plaintext. A correctly configured 587 client that requires TLS and validates the certificate is equally safe.

Why does my application time out on port 25 but work on 587?

Almost certainly an outbound port 25 block. Residential ISPs and most cloud providers filter outbound TCP 25 to limit spam from compromised hosts, while leaving 587 and 465 open. Submission ports are the intended path for applications anyway, so switch to 587 or 465 with authentication rather than requesting an unblock.

Do I need to open port 587 on my inbound mail server?

Only if your own users submit mail through that server. Inbound delivery from the rest of the internet arrives on port 25 to the hosts named in your MX records. If all your mail is submitted through a hosted provider, your MX host needs 25 open and nothing else.

Can I send mail on port 2525?

Only if your provider listens there. It is not an IANA-assigned SMTP port and no RFC defines it — it is a convention among hosted relay providers to work around firewalls that block 587. Check your provider's current documentation, and treat it as a fallback rather than a default.

Which port should a web application use to send transactional email?

Port 587 with STARTTLS or 465 with implicit TLS, authenticating to your relay provider or your own submission server. Never port 25 — cloud providers block it outbound, and even where it works you would be relaying anonymously, which harms deliverability and invites abuse.

Port 465 vs 587 vs 25: Which SMTP Port to Use

The three SMTP ports are not three flavours of the same thing. Two of them (587 and 465) are submission ports: an authenticated user or application handing a new message to its own provider. The third (25) is relay: one mail server delivering to another server on the public internet. Choosing the wrong one is behind a large share of "my app cannot send email" tickets.

What is each SMTP port actually for?

Port 25 — MTA-to-MTA relay

Port 25 is the original SMTP port and the only one that matters for inbound mail. When Gmail delivers a message to your domain, it looks up your MX records, picks the lowest-priority host, and connects to it on TCP 25. There is no authentication in that transaction — the sending server is anonymous, and the receiving server decides whether to accept the message based on SPF, DKIM, DMARC, reputation, and its own filtering.

Because port 25 is anonymous by design, it is also the port compromised machines use to spew spam. Almost every residential ISP and most cloud providers block outbound TCP 25 by default, and many will only unblock it after a support request. That block does not affect your ability to *receive* mail on 25 — it affects your ability to originate connections on it. If you are unsure which direction is failing, read Is Port 25 Blocked? and test both directions.

Port 587 — message submission with STARTTLS

Port 587 is the Message Submission port defined by RFC 6409. A client connects in plaintext, issues EHLO, sees STARTTLS in the capability list, upgrades the connection to TLS, and only then authenticates and sends. The key property is that a well-configured submission server does not advertise AUTH before TLS is established, so credentials never cross the wire in the clear.

You can see that behaviour directly. The plaintext EHLO below advertises STARTTLS but no AUTH line; after the upgrade, AUTH appears.

openssl s_client -starttls smtp -crlf -connect smtp.gmail.com:587

# After the handshake completes, type:
#   EHLO test.example.com
#   QUIT

Negotiate STARTTLS on 587 and inspect the post-TLS capabilities

Port 465 — implicit TLS submission

Port 465 has a messy history. It was registered as "smtps" in the 1990s, then de-registered in favour of STARTTLS on 587, which is why a decade of documentation called it deprecated. RFC 8314 (2018) reversed that: 465 is now formally registered as submissions, and the RFC recommends implicit TLS as the preferred submission mechanism over STARTTLS. There is no plaintext phase at all — the TLS handshake starts immediately on connect.

That matters operationally because a STARTTLS negotiation can be stripped by a middlebox: an on-path attacker rewrites the STARTTLS capability out of the EHLO response and the client silently falls back to plaintext unless it is configured to require TLS. Implicit TLS has no such downgrade surface. If your client library lets you choose, 465 is the slightly safer default.

openssl s_client -connect smtp.gmail.com:465 -crlf -quiet

# 220 smtp.gmail.com ESMTP ... gsmtp
# EHLO test.example.com
# 250-smtp.gmail.com at your service
# 250-AUTH LOGIN PLAIN XOAUTH2 ...

Implicit TLS on 465 — the banner arrives already encrypted

Port 2525 — the unofficial escape hatch

Port 2525 has no IANA assignment for SMTP and no RFC behind it. It exists because hosted SMTP relay providers needed a port that residential ISPs and cloud firewalls do not filter, and 2525 was conveniently unused. Providers that offer it typically run the same STARTTLS submission service there as on 587. Treat it as a fallback when 587 and 465 are both blocked by a network you do not control, and confirm in your provider's current documentation that they actually listen on it.

Which SMTP port should I use? A comparison

Port	Registered name	Role	TLS model	Auth	Who connects
25	smtp	MTA-to-MTA relay and inbound delivery	Opportunistic STARTTLS	None (anonymous)	Other mail servers
587	submission	Message submission (RFC 6409)	STARTTLS upgrade	Required	Mail clients, apps, scripts
465	submissions	Message submission (RFC 8314)	Implicit TLS on connect	Required	Mail clients, apps, scripts
2525	Not assigned for SMTP	Alternate submission port	Usually STARTTLS	Required	Apps behind restrictive firewalls

Rule of thumb: if you are typing a username and password, you want 587 or 465. If there are no credentials involved, you are doing MTA relay and the port is 25.

How do I configure a client or application correctly?

The single most common misconfiguration is mismatching the port and the encryption mode. Libraries and mail clients usually expose these as separate settings, and pairing them wrongly produces confusing errors rather than a clean failure.

Port 587 + STARTTLS. In most libraries this is the starttls / TLS / "explicit TLS" option. Setting an SMTP library to "SSL/implicit TLS" on 587 makes the client send a TLS ClientHello to a server expecting plaintext — you get a handshake timeout or a garbled-response error.
Port 465 + implicit TLS. Called SSL, SMTPS, or "SSL/TLS" in most UIs. Setting STARTTLS on 465 makes the client wait for a plaintext 220 banner that never comes in the clear, so it hangs until timeout.
Require TLS, do not merely prefer it. On 587, set the library flag that aborts if STARTTLS is unavailable. Silent plaintext fallback is the whole reason RFC 8314 prefers implicit TLS.
Verify the certificate. Disabling certificate validation to "make it work" is how a stripped-TLS problem gets papered over. Check the submission host's certificate with the SSL Certificate Checker instead.
Never point an application at port 25 on your own MX host. Your inbound MX will refuse to relay for you unless it is badly misconfigured as an open relay.

SMTP Connection Test

Can your mail server be reached on ports 25/465/587?

How do I tell whether the port or the credentials are the problem?

Split the question in two. First establish whether TCP reaches the host at all, then whether SMTP behaves as expected on that port. A connection that hangs with no banner is almost always a firewall drop; a connection that is refused immediately is usually nothing listening; a banner followed by an auth failure is a credentials or policy problem, not a network one.

# Which hosts receive mail for the domain?
dig +short MX example.com

# Does anything answer on the submission ports?
openssl s_client -starttls smtp -crlf -connect mail.example.com:587 </dev/null
openssl s_client -crlf -connect mail.example.com:465 </dev/null

Confirm the MX host and probe each port

Run the same probes from our servers with the Port Checker to find out whether the block is on your side or theirs. If the port is open from us but closed from your host, the filter is local — your ISP, your cloud provider's security group, or a host firewall.

What about TLS policy on port 25?

Encryption on port 25 is opportunistic: the sending server uses STARTTLS if the receiver offers it, and falls back to plaintext if not. MTA-STS and DANE exist to close that downgrade gap for inbound mail, by publishing a policy that says "always use TLS to my MX hosts, with a valid certificate". If you run your own inbound mail, check what you are publishing with the MTA-STS & TLS-RPT Checker. None of this applies to 465 or 587, where TLS is mandatory anyway.

Finally, remember that the port only governs transport. It has nothing to do with whether the receiving side accepts your message. Authentication results are decided by your SPF, DKIM, and DMARC records plus your sending IP's PTR record — run the Email Deliverability Test once the connection itself works.