A developer spent hours debugging why their application couldn't send email. The code was correct. The credentials were valid. The email service was working. The problem? They were trying to connect on port 25, which their cloud provider blocked by default. Switching to port 587 fixed everything instantly.
Email uses different ports for different purposes, and the distinctions matter more than you might think. Using the wrong port can mean blocked connections, security vulnerabilities, or delivery failures. Understanding which port to use when saves debugging time and improves your email infrastructure.
Port 25: the original SMTP port
Port 25 is the traditional SMTP port, defined in the original protocol specification. It's used for server-to-server email transfer—when one mail server delivers email to another.
When your mail server needs to deliver an email to gmail.com, it connects to Gmail's servers on port 25. This is how email has flowed between servers since the beginning of internet email.
However, port 25 has problems for modern use. It was designed before spam was a major concern, and it's been heavily abused. Many ISPs and cloud providers block outbound port 25 connections from their networks to prevent compromised machines from sending spam directly.
If you're running a mail server that needs to receive email from other servers, you need to accept connections on port 25. That's where other servers will connect. But for sending email from applications, port 25 is usually the wrong choice—it's likely blocked, and even if it isn't, it doesn't require authentication by default.
Port 587: the submission port
Port 587 is the designated port for email submission—when an email client or application submits a message to a mail server for delivery. It was specifically designed to separate client submission from server-to-server transfer.
Unlike port 25, port 587 requires authentication. You can't just connect and send; you must prove you're authorized. This makes it much harder for spammers to abuse and much safer for legitimate use.
Port 587 uses STARTTLS for encryption. The connection starts unencrypted, then upgrades to TLS after the initial handshake. This is called "explicit TLS" or "opportunistic TLS." Modern servers require the upgrade; the unencrypted phase is just for compatibility with the protocol flow.
For applications sending email through an email service or SMTP relay, port 587 is usually the right choice. It's designed for this purpose, requires authentication, supports encryption, and isn't typically blocked by network providers.
Port 465: implicit TLS
Port 465 has a complicated history. It was briefly assigned for SMTPS (SMTP over SSL) in the 1990s, then deprecated, then recently re-standardized for "implicit TLS" submission.
With implicit TLS, the connection is encrypted from the very first byte. There's no unencrypted handshake followed by an upgrade—you connect with TLS immediately. This is arguably more secure than STARTTLS, which has a brief unencrypted window that could theoretically be exploited.
Modern email services increasingly support port 465 for submission. If your email provider offers it, and your client or library supports it, port 465 is a solid choice. The immediate encryption provides slightly better security than the STARTTLS approach on port 587.
The historical confusion around port 465 means some older documentation says to avoid it. That advice is outdated. The port has been re-standardized and is now a legitimate, recommended option for email submission.
Port 2525: the alternative
Port 2525 isn't an official standard—it's a convention that emerged because ports 25, 465, and 587 are sometimes blocked or restricted.
Some ISPs block port 25 to prevent spam. Some corporate firewalls restrict email ports. Some cloud providers limit which ports you can use. When the standard ports don't work, port 2525 often does.
Email services commonly offer port 2525 as an alternative submission port. It works exactly like port 587—same protocol, same authentication, same STARTTLS encryption—just on a different port number.
If you're having trouble connecting on standard ports, try 2525. It's widely supported by email services and rarely blocked. It's not "better" than 587 or 465; it's just an escape hatch when those don't work.
Choosing the right port
For different scenarios, different ports make sense.
For application email submission (sending through an email service), use port 587 or 465. Both require authentication and support encryption. Port 587 with STARTTLS is the most universally supported. Port 465 with implicit TLS is slightly more secure. If both are blocked, try 2525.
For server-to-server transfer (running your own mail server), you need to accept connections on port 25. Other servers will connect there to deliver email to you. You might also send on port 25 to other servers, though many mail servers now prefer encrypted connections.
For receiving email on your own server, listen on port 25 for incoming server-to-server connections. You might also listen on 587 and/or 465 for authenticated submission from your own users and applications.
Never use port 25 for unauthenticated submission from applications. Even if it works, it's a security risk and likely to cause deliverability problems.
Security considerations
Port choice affects security in several ways.
Authentication requirements differ by port. Port 25 traditionally doesn't require authentication (though modern servers often do). Ports 587 and 465 require authentication by design. Always use authenticated ports for submission.
Encryption approaches vary. Port 587 uses STARTTLS (upgrade to encryption). Port 465 uses implicit TLS (encrypted from start). Port 25 might support STARTTLS but doesn't require it. For security, always use ports that enforce encryption.
Network exposure matters. If you're running a mail server, port 25 must be open to the internet to receive email. Ports 587 and 465 can be restricted to known clients or VPNs if you don't need public submission access.
Firewall rules should reflect these differences. Allow port 25 inbound for receiving email. Allow ports 587/465 for submission, possibly with additional restrictions. Block port 25 outbound from systems that shouldn't be sending email directly.
Common port problems
Several issues commonly arise around email ports.
Blocked ports are the most frequent problem. Cloud providers often block port 25 by default. Corporate networks might restrict email ports. ISPs sometimes block residential connections from sending email. When connections fail, try alternative ports.
Wrong port for the purpose causes confusion. Trying to submit email on port 25 might work but lacks proper authentication. Trying to receive server-to-server email on port 587 won't work—other servers expect port 25.
TLS configuration mismatches happen when the client expects one encryption mode and the server offers another. Port 587 expects STARTTLS; port 465 expects immediate TLS. Using the wrong mode for the port causes connection failures.
Firewall rules that are too restrictive block legitimate email. Too permissive, and you're exposed to abuse. Getting the balance right requires understanding which ports serve which purposes.
Testing port connectivity
Before debugging complex email issues, verify basic port connectivity.
Telnet or netcat can test whether a port is reachable. "telnet mail.example.com 587" attempts a connection. If it connects, the port is open. If it times out or refuses, something is blocking it.
OpenSSL can test encrypted connections. "openssl s_client -connect mail.example.com:465" tests implicit TLS. "openssl s_client -starttls smtp -connect mail.example.com:587" tests STARTTLS.
Online tools can test from outside your network. If connections work from external tools but not from your application, the problem is likely your network's outbound restrictions.
Email service documentation specifies which ports they support and recommend. Check their docs rather than guessing—different services have different configurations.
Frequently asked questions
Which port should I use for sending email from my application?
Port 587 with STARTTLS is the most widely supported choice. Port 465 with implicit TLS is also good if your email service supports it. If both are blocked, try port 2525.
Why is port 25 blocked on my cloud server?
Cloud providers block port 25 by default to prevent spam. Compromised servers often try to send spam directly. You can usually request port 25 access if you have a legitimate need, but for application email, use port 587 instead.
Is port 465 secure to use?
Yes. Despite its complicated history, port 465 is now re-standardized for implicit TLS submission. It's arguably more secure than port 587 because encryption starts immediately rather than after a STARTTLS upgrade.
Do I need to open multiple ports for email?
It depends on your setup. For receiving email on your own server, you need port 25 open. For submission, you might offer 587 and/or 465. For sending through an email service, you only need outbound access to their ports.