For sending email in 2026, use SMTP port 587 with STARTTLS as your default, fall back to port 465 (implicit TLS) if 587 is blocked, and use 2525 only when both are unavailable. On SMTP port 587 vs 465 the practical difference is when encryption starts: 587 opens plaintext and upgrades to TLS, while 465 is encrypted from the first byte. Port 25 is for server-to-server relay, not app submission, and most ISPs and cloud hosts block it outbound to fight spam.
I've wired up SMTP credentials on hundreds of servers. The port question comes up every single time, usually after something is already broken. Here's what each port is actually for.
SMTP port comparison table
| Port | Encryption | Purpose | Use it for | Blocked often? |
|---|---|---|---|---|
| 25 | Optional (opportunistic TLS) | Server-to-server mail relay | MTA-to-MTA delivery only | Yes, outbound blocked by most ISPs/clouds |
| 465 | Implicit TLS (encrypted from start) | Client mail submission | App/client sending mail | Rarely |
| 587 | STARTTLS (upgrades to TLS) | Client mail submission | App/client sending mail (default) | Sometimes on locked-down networks |
| 2525 | STARTTLS (provider-specific) | Alternate submission | Fallback when 587/465 blocked | No, but not universally supported |
Port 25: the original, now for relay only
Port 25 is the original SMTP port from 1982. When your mail server hands a message to the recipient's mail server, that conversation happens on port 25. That part hasn't changed and never will.
What changed is submission. Sending mail from your laptop or app server to your provider on port 25 is now blocked almost everywhere. AWS, Google Cloud, DigitalOcean, and every residential ISP block outbound 25 by default. The reason is spam: a compromised machine sending directly to recipient servers on 25 is the classic botnet pattern, so providers cut it off.
If you're trying to send through port 25 from an app and it times out, that's expected. Switch to 587. The receiving server still accepts your mail on 25; you just don't submit on it.
Port 587: the modern submission default
Port 587 is the official submission port (RFC 6409). It uses STARTTLS: the client connects in plaintext, the server advertises that it supports encryption, and the client issues a STARTTLS command to upgrade the connection to TLS before any credentials or message data are sent.
This is what you should configure first. Nearly every provider, from Amazon SES to Mailgun to a self-hosted Postfix box, accepts authenticated submission on 587. The one risk: a misconfigured client can send credentials before upgrading to TLS. Any decent server rejects that by requiring STARTTLS, but enforce it on your side too.
Port 465: implicit TLS, back from the dead
Port 465 has a messy history. It was deprecated around 1998, then reinstated as an official standard in 2018 (RFC 8314) for implicit TLS submission. "Implicit" means the TLS handshake happens immediately on connect, before any SMTP commands. There's no plaintext window at all.
For SMTP port 587 vs 465, the security outcome is the same once TLS is up. The differences that matter in practice:
- 465 is simpler to reason about: encrypted from byte one, no upgrade step that can be skipped.
- 587 is more widely assumed as the default in libraries and docs.
- Some providers and corporate firewalls treat one more kindly than the other.
If 587 gives you grief on a particular network, try 465 before anything else.
Port 2525: the unofficial fallback
Port 2525 isn't in any RFC. It exists because providers got tired of support tickets from customers on networks that block 587 and 465. SendGrid, Mailgun, SMTP2GO, and several others listen on 2525 and run the same STARTTLS as 587.
Treat it as a fallback, not a primary. If your code can't connect on 587 or 465 (common on locked-down office Wi-Fi or some cloud egress rules), 2525 often slips through because firewalls rarely block high non-standard ports. Don't hardcode 2525 as your only port, since not every provider supports it.
Which port should you actually use?
The decision tree I give people:
- Submitting mail from an app or client? Start with 587.
- 587 blocked or flaky? Use 465.
- Both blocked (restrictive network)? Use 2525 if your provider supports it.
- Building a mail server that delivers to other servers? That leg uses 25, and nothing you configure changes that.
The port has zero effect on deliverability. Whether a message lands in the inbox depends on IP reputation, authentication, and content. If inbox placement is your problem, the port is a red herring. Start with how to reduce email bounce rate and dedicated IP vs shared IP instead.
Common port mistakes I keep fixing
Using port 25 for app submission on a cloud host. It times out silently and people burn hours on it. Switch to 587.
Mixing up TLS modes. Telling your client to use STARTTLS on port 465, or implicit TLS on 587, produces confusing handshake errors. Match the mode to the port: STARTTLS on 587, implicit TLS on 465.
Assuming the port fixes reputation. I've watched senders flip between 587 and 465 chasing spam-folder issues. The port was never the cause. Warm-up and authentication were. See how long IP warm-up takes.
If you're choosing a provider rather than debugging one, Amazon SES vs dedicated SMTP server, SendGrid alternatives, and the cost to send 1 million emails per month cover the parts that actually move the needle.
How BulkEmailSetup helps
BulkEmailSetup gives you a dedicated SMTP server preconfigured for submission on 587 and 465, with TLS enforced, plus managed IP warm-up, DNS setup, and blacklist monitoring. You get clean credentials that work on the first try and a reputation that's entirely yours, at a flat monthly fee that beats per-email pricing at volume. See pricing for current plans.
Frequently asked questions
What is the difference between SMTP port 587 and 465?
Port 587 uses STARTTLS: the connection opens in plaintext and upgrades to TLS after a command. Port 465 uses implicit TLS: the connection is encrypted from the first byte. Both are encrypted and both are fine for sending in 2026. Port 587 is the modern default; 465 came back as an official standard in 2018 and is preferred by some providers for simplicity.
Which SMTP port should I use to send email?
Use port 587 first. If your network or host blocks it, use 465. Use 2525 only as a fallback when both are blocked, and only if your provider supports it. Never use port 25 for client-to-server submission; it's for server-to-server relay and is blocked by most ISPs.
Why is SMTP port 25 blocked?
Residential ISPs and most cloud hosts (AWS, GCP, DigitalOcean) block outbound port 25 to fight spam from compromised machines. Port 25 is meant for mail-server-to-mail-server delivery, not for apps submitting mail. Use 587 or 465 to submit, and the receiving server still gets your mail on 25.
Is SMTP port 2525 secure?
Port 2525 isn't an official SMTP standard, but providers like SendGrid, Mailgun, and SMTP2GO support it as an alternate submission port that runs the same STARTTLS as 587. It's as secure as 587 when TLS is enforced. Treat it as a fallback, not a primary.
Does the SMTP port affect deliverability?
No. The port only determines how your app connects to the submission server. Inbox placement depends on IP reputation, authentication (SPF, DKIM, DMARC), and content, not on whether you used 587 or 465.
