Port 25 is mainly for email moving between mail servers. If you’re configuring a website, script, or email app to send messages through a provider, you’ll usually need that provider’s submission service on port 587 or 465 instead.
That distinction matters: the ports are all associated with SMTP, but they serve different parts of the email delivery path.
Where port 25 fits in email delivery
SMTP—the Simple Mail Transfer Protocol—is used to hand email from one mail system to another. When a provider has a message for a recipient at a different domain, it finds the mail server responsible for that domain and typically connects to it over TCP port 25.
The path looks roughly like this:
Email app → sender's mail provider → recipient's mail server
SMTP transfer, usually TCP 25
The email app normally submits the message to its own provider first. The provider’s mail server then handles delivery to the recipient’s server. Mail transfer agents (MTAs), such as Postfix, Exim, and Sendmail, can receive or relay this server-to-server SMTP traffic.
A port number identifies a network service endpoint; it doesn’t prove that a service is running there. An open port 25, by itself, doesn’t tell you whether a server is a correctly configured mail server—or even what software is listening.
If you’re comparing common service ports, this overview of well-known ports and their typical uses provides the broader context.
Port 25 vs. 587 vs. 465
These ports are not interchangeable just because they’re all used with SMTP.
| Port | Typical role | Common use |
|---|---|---|
25 |
SMTP transfer or relay | Mail server delivering to another mail server |
587 |
Message submission, commonly with STARTTLS | App or email client submitting mail to its provider |
465 |
Message submission with implicit TLS | App or email client using a provider’s submission service |
For a website or application that sends email, use the hostname, port, and encryption settings documented by your provider. Port 587 is a common submission choice; port 465 is also used for submission when supported by the provider.
Port 25 is generally not the right substitute. Destination mail servers may not accept unauthenticated client submissions on it, and networks may block outbound connections to it. Use an authorized provider relay for application mail rather than trying to bypass a restriction.
Why outbound port 25 can fail
A connection to port 25 that times out or is refused doesn’t identify the cause on its own. The restriction could be on your hosting account, cloud network, local firewall, or destination server. Some ISPs and hosting providers restrict outbound port 25 to reduce spam and abuse.
When troubleshooting, check these in order:
- Provider policy: Confirm that your ISP or hosting provider permits outbound SMTP on port 25 for your account.
- Network rules: Check local firewall rules and any cloud firewall or network policies for outbound TCP port 25.
- Destination service: Confirm that the destination mail server is reachable and accepting SMTP connections.
- Application configuration: If an app is sending through an email provider, verify that it uses the provider’s submission hostname, port, and encryption requirements—typically port 587 or 465.
Opening a port in your server’s firewall won’t override an upstream restriction imposed by a cloud provider or ISP. If you operate a mail server and need direct delivery, ask the provider whether outbound SMTP is allowed. For more on the layers involved, see this guide to opening ports across servers, routers, and cloud firewalls.
Is an open port 25 unsafe?
Port 25 is a normal part of email infrastructure, not inherently a security problem. The risk depends on the service and its configuration.
One important misconfiguration is an open relay: a mail server that lets unauthorized users send messages through it to arbitrary destinations. That can be abused for spam and may damage the server’s reputation with mail providers. A properly configured mail server restricts relaying to authorized users and applies appropriate mail policies.
If you don’t operate an SMTP server, there’s generally no reason to expose an inbound port 25 service on your machine. If you do, keep the mail software maintained and review relay permissions and firewall rules. A port being open doesn’t, by itself, mean the system has been compromised.
The practical takeaway
Use TCP port 25 for the usual server-to-server SMTP delivery path. Use your email provider’s port 587 or 465 submission service for an app or email client sending through that provider. If direct delivery fails, check both the network path and provider policy; a local firewall change alone may not be enough.
I originally published a more detailed version of this guide on the SSHFlow blog.
I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.
Top comments (0)