Port 25 is the original SMTP port, defined in 1982, and it is used for one thing today: relaying mail between mail servers. If you are writing an application that sends email, port 25 is almost certainly not the port you want — and on most cloud providers, outbound connections to it are blocked entirely.
That block catches people out constantly. The code is correct, the credentials are correct, and the connection just hangs until it times out. Nothing in the error says anything about a policy decision made by your hosting provider, because from your application’s point of view the packet simply went nowhere.
Table of contents
- What port 25 is for
- Why it gets blocked
- The four ports and what each is for
- Diagnosing a hanging mail connection
- What to do instead of running a mail server
- Keeping the credentials out of your code
- How this fits the rest of the stack
- FAQ
What port 25 is for
SMTP has two distinct jobs, and they got split across different ports for good reasons.
- Relay — one mail server handing a message to another mail server, typically the recipient’s. This is port 25. It is server-to-server, usually unauthenticated, and it is how mail actually moves across the internet.
- Submission — a client handing a message to its own mail server to be sent. This is port 587. It is authenticated and it is what an application should use.
The confusion comes from the fact that port 25 works for both in principle. The original design had no separation, so early mail clients used port 25 to submit, and plenty of documentation still reflects that.
The separation was formalised because relay and submission want opposite security properties. Relay must accept mail from strangers, or mail from other organisations could never reach you. Submission must only accept mail from authenticated users, or you are an open relay.
Why it gets blocked
Port 25’s willingness to accept mail from anyone made it the primary vehicle for spam. A compromised machine on a residential connection or a cloud VM could relay directly to any mail server on the internet, and for years that is exactly what happened at scale.
The industry response was to block outbound port 25 by default. Residential ISPs did it first; cloud providers followed. Today, on most major clouds, outbound connections to port 25 are blocked at the network level unless you specifically request an exemption — and those requests are frequently declined for new accounts.
This is not an obstacle to work around. A brand-new cloud IP address has no sending reputation, which means even if the port were open, the mail would land in spam or be rejected outright by the receiving server. The block is saving you from discovering that the slow way.
The practical consequence: an application server should not be delivering mail directly. It should hand mail to something that specialises in delivery.
The four ports and what each is for
The full set, so you can pick without guessing:
- 25 — relay. Server to server. Blocked outbound almost everywhere. Your app should not use it.
- 587 — submission with STARTTLS. The standard for authenticated sending. The connection opens in plaintext and upgrades to TLS via the STARTTLS command. This is the default answer.
- 465 — submission with implicit TLS. TLS from the first byte. Once deprecated, then un-deprecated by RFC 8314, which now prefers it over 587 on security grounds. Widely supported.
- 2525 — unofficial alternative. Not a standard. Offered by many providers purely as a fallback for networks that block both 587 and 465.
If you have no other constraint, use 587. If your provider offers 465 and your library supports implicit TLS cleanly, 465 is marginally better because there is no plaintext phase where a downgrade attack could strip STARTTLS. Use 2525 only when the others are blocked.
Diagnosing a hanging mail connection
The signature of a port 25 block is a connection that hangs rather than one that refuses. A refused connection comes back immediately; a blocked one times out.
Test it directly:
# Blocked: hangs until timeout. Open: prints a 220 greeting.
curl -v --connect-timeout 10 telnet://smtp.example.com:25Then test the port you should be using:
curl -v --connect-timeout 10 telnet://smtp.example.com:587If 587 connects and 25 hangs, you have confirmed the block and the fix is a one-line configuration change. If both hang, the problem is broader — check whether outbound traffic is restricted generally, or whether the hostname resolves at all.
One thing worth ruling out early: a DNS failure looks similar from inside an application, because the connection attempt never starts. Confirm the hostname resolves before concluding anything about ports.
What to do instead of running a mail server
The honest recommendation for application email is to not operate mail infrastructure. Deliverability is a full-time specialism, and the failure mode — mail silently landing in spam — is one you cannot observe from your own logs.
What actually determines whether your mail arrives:
- SPF — a DNS record listing which servers may send for your domain.
- DKIM — a cryptographic signature proving the message was not altered and came from your domain.
- DMARC — a policy record telling receivers what to do when SPF or DKIM fails, plus reporting so you can see what is being sent in your name.
- IP and domain reputation — built over time by sending mail people want and not sending mail they do not.
- Reverse DNS matching your sending hostname.
The first three are DNS records you control regardless of who sends your mail, and they are worth setting up properly even when a provider handles delivery. The last two are what you are really buying when you use a delivery service: an IP pool with established reputation and someone whose job is keeping it that way.
For an application, the shape that works is simple: your code connects to a delivery provider on port 587 with credentials stored as environment variables, and that provider handles the relay on port 25 from IPs that are allowed to.
Keeping the credentials out of your code
Whatever you send through, the SMTP credentials are a secret with a specific and unpleasant failure mode: a leaked sending credential is used to send spam from your domain, which destroys the sending reputation you have built and is slow to recover.
Treat them accordingly:
- Store host, port, username, and password as environment variables, not in a config file in the repository.
- Use separate credentials per environment, so a leak from staging does not compromise production sending.
- Rotate them if they were ever committed to git, even to a private repository and even if you deleted the commit — history persists in clones and forks.
The one that surprises people is the third. Deleting a file does not remove it from history, and rewriting history does not remove it from anyone’s existing clone. If a credential was ever committed, it must be rotated.
How this fits the rest of the stack
Outbound mail is a good example of infrastructure where the failure is silent — the code runs, no exception is thrown, and the message simply does not arrive. The parts you can control are the DNS records and where the credentials live. Custom domains and certificates on RunxBuild covers the DNS side, and environment variables are set per service rather than committed to the repository, so the same code runs in staging and production with different sending credentials. If you are working out what the app, the database, and the bandwidth cost together, the RunxBuild hosting calculator puts them side by side as line items.
Useful related references:
- What Port is SSH: 22 (Default), How to Change, and Why
- Default Port for SSH: Why 22, and When to Change It
- What Port for SSH: 22, 2222, and the Right Defaults
- Services on RunxBuild
FAQ
Why is port 25 blocked on my server?
Cloud providers and ISPs block outbound port 25 by default because it was the main channel for spam relay. A new cloud IP also has no sending reputation, so mail from it would likely be rejected or filtered even if the port were open.
Should I use port 587 or 465?
Use 587 unless you have a reason not to — it is the standard submission port with STARTTLS. Port 465 uses implicit TLS from the first byte, which RFC 8314 now prefers on security grounds. Both are widely supported; 2525 is a non-standard fallback.
What is the difference between SMTP relay and submission?
Relay is one mail server handing a message to another, on port 25, usually unauthenticated. Submission is a client handing a message to its own server to send, on port 587, always authenticated. Applications do submission, not relay.
How do I test whether port 25 is blocked?
Run curl -v —connect-timeout 10 telnet://smtp.example.com:25. A blocked port hangs until the timeout; an open one returns a 220 greeting immediately. Compare against port 587 to confirm it is the port and not the network.
Do I still need SPF and DKIM if a provider sends my mail?
Yes. SPF, DKIM, and DMARC are DNS records on your domain, and receivers check them regardless of who operates the sending servers. Your provider will tell you what records to publish; without them your mail is far more likely to be filtered.