SMTP Ports Explained: 25, 465, 587, and 2525 (Which to Use)

Use port 587 with STARTTLS for virtually all application email submission. It is the standard submission port defined in RFC 6409 and requires authentication before accepting mail. If your network or firewall blocks 587, try port 465 (implicit TLS, re-standardized in RFC 8314) or port 2525 (a non-official but widely supported fallback). Port 25 is for server-to-server relay between mail transfer agents, and you should not use it from an application: AWS, GCP, and most residential ISPs block outbound port 25 by default.

SMTP Port Reference: The Four Ports at a Glance

Port	Direction	Encryption	Typical Use	Auth Required
25	Server to server (MTA relay)	None / STARTTLS optional	Mail transfer between mail servers	No (not suitable for apps)
465	Client to server (submission)	Implicit TLS (always on)	App/client email submission over implicit TLS	Yes
587	Client to server (submission)	STARTTLS (upgrades from plaintext)	App/client email submission; recommended default	Yes
2525	Client to server (submission)	TLS / STARTTLS	Fallback when 587/465 are blocked by firewall	Yes

Port 25: Server-to-Server Relay, Not for Apps

Port 25 is the original SMTP port, defined in RFC 821 in 1982 and now specified in RFC 5321. Its purpose is mail transfer between mail transfer agents (MTAs): when your mail server hands a message off to the recipient’s mail server, it uses port 25. That server-to-server path is called a relay, and understanding how SMTP works at this layer explains why port 25 was never designed to require authentication.

That design made it a spam magnet. From the early 2000s onward, abuse from compromised machines prompted ISPs and cloud providers to block outbound port 25 by default. Google Cloud Platform states it blocks external port 25 traffic “due to the risk of abuse.” AWS throttles and restricts port 25 on EC2 instances by default, and requests to lift the restriction are reviewed individually. Most residential ISPs do the same. If you are running application code that needs to send email, port 25 will be blocked in most environments before you even start.

The rule: port 25 is for your mail server’s outbound relay to other mail servers. Never use it for client-to-server submission from an application.

Port 587: The Modern Submission Standard

RFC 6409 (Message Submission for Mail) defines port 587 as the standard submission port, explicitly separating the act of submitting a message for delivery from the act of relaying it between servers. The RFC states that “port 587 is reserved for email message submission” and requires that “the MSA MUST, by default, issue an error response to the MAIL command if the session has not been authenticated.”

In practice, this means port 587 requires SMTP AUTH before it will accept a message. The session begins as a plaintext TCP connection, then upgrades to encrypted TLS through the STARTTLS command before credentials or message content are transmitted. This upgrade-based approach is why it is sometimes called “opportunistic TLS” or “explicit TLS.”

Port 587 is supported by virtually every email service provider and SMTP relay. Most email APIs, including Coldletter, accept submission on 587 as the primary port. If you are configuring a mail client, an application, or an SMTP relay, start here.

Decision point: use 587 unless something on your network specifically blocks it.

Port 465: Implicit TLS, With a Complicated History

Port 465 has an unusual past. IANA registered it as “smtps” in 1997, intending it for SMTP over implicit TLS. But because the IETF had decided to standardize port 587 with STARTTLS instead, IANA de-registered port 465 and reassigned it to a different service in 1998.

The problem: large amounts of mail software had already adopted port 465 for submission. Removing it from the registry did not stop vendors from using it. RFC 8314 (published January 2018) acknowledged this reality and re-registered port 465 officially as the “submissions” port for implicit TLS submission, stating that “some widely deployed mail software interpreted ‘smtps’ as ‘submissions’ and used that port for email submission by default when an end user requested security.”

RFC 8314 defines implicit TLS as “the automatic negotiation of TLS whenever a TCP connection is made on a particular TCP port that is used exclusively by that server for TLS connections.” Unlike STARTTLS on port 587, there is no plaintext phase: the connection is encrypted from the first byte. The RFC notes that “there is no significant difference between the security properties of STARTTLS on port 587 and Implicit TLS on port 465 if the implementations are correct,” and recommends that “clients and servers SHOULD implement both STARTTLS on port 587 and Implicit TLS on port 465 for this transition period.”

Some providers, including Postmark, have opted not to support port 465. Others, including Gmail and many corporate mail servers, support both. Use 465 when your client library supports only implicit TLS, when the provider explicitly recommends it, or when 587 is blocked by a network policy that allows 465 through.

Port 587 vs. Port 465: The Practical Decision

Port 587 with STARTTLS and port 465 with implicit TLS both produce an encrypted session before any credentials are sent. The security outcome is equivalent when both are implemented correctly.

The practical differences:

• STARTTLS (587) starts as plaintext and upgrades. A misconfigured client that does not enforce the TLS upgrade could fall back to sending credentials in plaintext. Most modern libraries prevent this, but it is the theoretical attack surface.
• Implicit TLS (465) requires TLS from byte one. There is no negotiation phase and no downgrade path, which some security teams prefer for compliance reasons.
• Library support is the deciding factor for most developers. If your SMTP client library has a clear “use implicit TLS / SMTPS” toggle, use 465. If it only has a STARTTLS option, use 587.
• Provider support matters too. Not every provider exposes 465. Check your provider’s documentation before assuming it is available.

When you are using an email API rather than raw SMTP, the port selection is abstracted: you call an HTTPS endpoint and the API handles delivery. SMTP port choice becomes relevant only when you configure SMTP credentials for a client application or a relay.

Port 2525: The Unofficial Fallback

Port 2525 is not registered with IANA as an SMTP port and is not defined in any RFC. It exists as a pragmatic industry convention. Mailgun describes it as “an alternate port, which mirrors port 587, in the event the above ports are blocked.”

The reason it exists: some corporate firewalls and network policies block both port 25 (standard anti-spam measure) and port 587 (occasionally caught in overly broad outbound rules). Because port 2525 is a high-numbered port outside the well-known range, it often passes through firewall rules that block 25 and 587. It supports TLS and requires authentication, just like 587.

Major providers that support 2525 include SendGrid, Mailgun, Mailjet, and Brevo. Some, including Postmark, list it as a supported option alongside 587. It is not a replacement for 587 in normal environments; it is a fallback for when your network is the obstacle.

When sending email from Node.js via Nodemailer and 587 is blocked, switching the port to 2525 in your transport config is the fastest workaround.

Testing SMTP Port Connectivity

When a connection times out or refuses, the first diagnostic question is whether the port is reachable at all. Three command-line tools help:

Test with telnet (basic reachability):

telnet smtp.yourprovider.com 587

A successful response begins with 220. A timeout means the port is blocked between your machine and the server.

Test port 465 with openssl (implicit TLS):

openssl s_client -connect smtp.yourprovider.com:465

You should see the TLS handshake output followed by the 220 greeting.

Test STARTTLS on port 587 with openssl:

openssl s_client -starttls smtp -connect smtp.yourprovider.com:587

This initiates a plaintext connection, sends EHLO, and upgrades via STARTTLS. Inspect the certificate chain and look for the 220 greeting after the upgrade.

Common error meanings:

• Connection timed out or Connection refused: the port is blocked by a firewall, either on your network or at the provider level.
• SSL handshake error on port 465: TLS version mismatch or certificate issue on the server.
• 530 Authentication required: you reached the port, but your SMTP AUTH credentials are missing or wrong.

Good deliverability depends on more than the port you connect on. Correct SPF, DKIM, and DMARC configuration matters far more for inbox placement than whether you send over 587 or 465.

The Decision Rule

Use port 587 with STARTTLS by default. Fall back to port 465 with implicit TLS if your library or provider prefers it, or if your network blocks 587 but allows 465. Use port 2525 if both 587 and 465 are blocked. Never use port 25 from an application: it is for server-to-server relay and is blocked by most cloud providers and residential ISPs.

Frequently Asked Questions