SMTP Port 587 vs 2525: Which Should You Use?
When sending emails, it's best to use port 587 with STARTTLS for secure message submission. This should be your first choice. Only use port 2525 if your email service says it's okay and you can't connect to port 587 because of network issues.
The port number does not encrypt a connection by itself. Your client still needs the correct TLS mode, certificate validation, and authentication sequence for the service it is using.
SMTP port 587 vs 2525 at a glance
RFC 6409 separates message submission by a client from message relay between mail servers. RFC 6409 reserves port 587 for email message submission. It also says relay continues over port 25.
Port 2525 has a different status. IANA does not register port 2525 for SMTP or message submission. Some email services listen there as a fallback, but that convention is provider-specific.
| Port | Registered mail purpose | Typical TLS mode | When to use it |
|---|---|---|---|
| 25 | SMTP relay between mail servers | Opportunistic STARTTLS is common | Server-to-server delivery, not normal client submission |
| 465 | Message submission over TLS | Implicit TLS from connection start | When the service documents port 465 |
| 587 | Message submission | STARTTLS | Default for an authenticated SMTP client |
| 2525 | No SMTP or submission registration | Usually STARTTLS when an email service offers it | Documented fallback when 587 is blocked |
Treat the service's connection guide as part of the protocol. A host that accepts SMTP on 2525 may require STARTTLS, implicit TLS, or no service at all. Do not infer the mode from the number.
Why port 587 is the default
Port 587 gives clients and servers a shared, standard meaning: this connection is a message submission, not an unauthenticated relay attempt. That distinction lets the submission service apply authentication and sender policy at the correct boundary.
When you start a session with STARTTLS, it begins like a regular SMTP connection, but then it gets upgraded to TLS. This happens after the server says it can handle TLS. At this point, the client should check the server's certificate to make sure it's valid, and then finish setting up the TLS connection. Only after that's all done should the client send its credentials. If for some reason TLS can't be set up, the connection should be stopped right there, instead of trying to keep going with the authentication process.
Use these settings when the provider documents the usual 587 path:
- Set the port to
587.
- To start a secure connection, choose the STARTTLS option, which may be referred to as
tlsin some client libraries.
- Require certificate validation.
- Authenticate only after TLS succeeds.
When setting up a connection, don't use an implicit TLS option with port 587 unless your provider specifically tells you to. The reason is that if the TLS mode doesn't match between the client and server, it can cause problems that look like a timeout or a sudden disconnection. This happens because the client and server are expecting different things at the start of the connection.
When port 2525 makes sense
Port 2525 is useful when a provider offers it and an outbound firewall blocks 587. It can also help with a legacy network policy that filters recognised mail-submission ports while permitting a higher alternative port.
The fallback is safe only when the connection policy is safe. Confirm that the provider supports 2525 for authenticated submission, that your client uses the documented TLS mode, and that certificate validation remains enabled.
Do not assume that a successful TCP connection proves the setup is correct. It only proves that something answered at that address and port. Check the SMTP greeting, advertised capabilities, completed TLS handshake, and authentication result.
What about ports 465 and 25?
Port 465 is a registered message-submission option where TLS starts as soon as the TCP connection opens. RFC 8314 states that correctly configured STARTTLS on 587 and implicit TLS on 465 have no significant difference in security properties.
The practical difference is how TLS starts. On 465, the client opens with a TLS handshake. On 587, the client connects with SMTP and then issues STARTTLS. Match the client setting to the provider's published connection details.
Port 25 remains essential for mail servers relaying messages to one another. It is often restricted for outbound application traffic because open or compromised clients can abuse direct relay access. An application submitting authenticated email should follow its provider's submission guide instead of treating 25 as another interchangeable client port.
Diagnose an SMTP connection before changing ports
Start with the exact SMTP host, port, TLS mode, username format, and credential type in the provider's current guide. Test one setting at a time so the result identifies the failed layer.
For STARTTLS on port 587:
openssl s_client -starttls smtp -connect smtp.example.com:587 -servername smtp.example.com
For a provider-documented STARTTLS fallback on port 2525:
openssl s_client -starttls smtp -connect smtp.example.com:2525 -servername smtp.example.com
For implicit TLS on port 465:
openssl s_client -connect smtp.example.com:465 -servername smtp.example.com
Inspect the certificate verification result, negotiated TLS version, and SMTP response. A missing STARTTLS capability means you should stop and confirm the endpoint rather than send credentials. A certificate error needs a trust or hostname fix, not disabled verification.
If 587 times out but 2525 works with the provider's documented settings, inspect outbound firewall rules and ask the network operator about the blocked path. If both ports negotiate TLS but authentication fails, changing ports again will not repair an invalid credential or username format.
Configure retries without hiding the failure
A connection timeout can be transient, but a port fallback should not turn into an endless loop. Set a connection timeout, record the endpoint and error class, and limit the number of attempts.
Retry a temporary network failure with delay and jitter. Do not retry a certificate validation failure or authentication rejection unchanged. Those responses require configuration or credential work.
Keep 2525 as an explicit fallback rather than silently cycling through arbitrary ports. That makes network policy visible in logs and prevents a future configuration change from sending credentials to an unintended service.
Using 587 and 2525 with Sendmux
Sendmux's public SMTP connection guide lists port 587 with STARTTLS and port 2525 with STARTTLS. Both use the same documented SMTP authentication options. For a new connection, use 587 first and keep 2525 for a network that blocks the standard submission port.
When you're creating a new app, the Sendmux HTTP Sending API is often the better choice. But if you have an existing app, plugin, or mail client that already uses SMTP, it's still a good option.
Whichever route you choose, test with one message and confirm the result in delivery logs before increasing volume. Port selection establishes the connection path. It does not replace sender authentication, bounce handling, rate control, or delivery monitoring.
Sources
Frequently Asked Questions
What is the purpose of port 2525?
Some email services offer port 2525 as an authenticated SMTP submission fallback when port 587 is blocked. IANA does not register 2525 for SMTP or message submission, so use it only when your provider documents the host, TLS mode, and authentication settings.
Why is SMTP port 25 blocked so often?
Port 25 is used for SMTP relay between mail servers. Networks often restrict outbound access from application hosts to reduce direct-to-MX spam and abuse from compromised systems. Use the authenticated submission port documented by your email provider.
Is port 25 still relevant today?
Yes. Mail servers still use port 25 for server-to-server relay. It is not the normal choice for an application or mail client submitting authenticated outbound email.
What is SMTP port 587 used for?
Port 587 is reserved for email message submission. Clients normally connect there with STARTTLS, validate the server certificate, complete TLS negotiation, and then authenticate according to the provider's instructions.
Does Sendmux support both 587 and 2525?
Yes. Sendmux's public SMTP connection guide lists both port 587 and port 2525 with STARTTLS and the same documented authentication options. Use 587 first, then 2525 when the network blocks 587.
