SMTP ports are the network ports email clients and servers use to submit or relay mail. If you are asking which SMTP port should I use, the safest default for application sending is usually port 587 with SMTP AUTH and STARTTLS.
The right choice still depends on your provider, TLS mode, network rules, and whether you are submitting mail from an app or relaying mail between servers. MailSlurp helps teams test that decision with SMTP diagnostics, sandbox inboxes, message inspection, and deliverability checks.
Quick answer: which SMTP port should I use?
Use this order for most modern applications:
- Use port
587with STARTTLS for authenticated SMTP submission. - Use port
465when your provider requires implicit TLS from the start of the connection. - Use port
2525as an alternate submission port when587is blocked and your provider supports it. - Use port
25mainly for server-to-server relay, not ordinary app submission.
If you need one answer, start with 587 and STARTTLS, then validate the connection and inbox result before release.
SMTP ports quick table
| Port | Common role | TLS mode | Best use | Common mistake |
|---|---|---|---|---|
25 | Server-to-server relay | Opportunistic or policy-specific STARTTLS | Mail transfer between MTAs | Using it for app submission in a cloud network where outbound 25 is blocked |
465 | SMTP submission | Implicit TLS | Providers that require TLS before SMTP commands | Configuring it as STARTTLS |
587 | SMTP submission | STARTTLS | Default authenticated app sending | Treating it as implicit TLS |
2525 | Alternate SMTP submission | Provider-specific, often STARTTLS | Fallback when 587 is blocked | Assuming every provider supports it |
Decision framework
Choose the port by answering these questions in order.
1. Are you submitting email from an app?
Use port 587 first. It is the standard submission port for authenticated application sending. Your client connects, the server advertises capabilities, the client issues STARTTLS, and authentication happens over the encrypted connection.
Use MailSlurp's SMTP tester to check host, port, TLS negotiation, and SMTP AUTH behavior before you put the configuration into production.
2. Does your provider require implicit TLS?
Use port 465 when your provider documents SMTPS or implicit TLS. On 465, the TLS session starts immediately when the connection opens. Do not configure 465 as if it were a STARTTLS upgrade port.
3. Is port 587 blocked?
Use port 2525 only when your provider supports it and your network blocks 587. Port 2525 is common as a provider fallback, but it is not the universal default.
4. Are you relaying mail between mail servers?
Use port 25 for server-to-server mail relay scenarios. Avoid it for normal app submission because many cloud providers, ISPs, and corporate networks restrict outbound 25.
What is the secure port for SMTP?
There is no secure SMTP port by number alone. The secure choice is the port plus the correct TLS mode:
587with STARTTLS is the normal secure SMTP submission setup.465with implicit TLS is secure when your provider expects TLS from connection start.25can use STARTTLS between servers, but it is not the right default for app-level authenticated submission.2525can be secure when the provider supports TLS and documents the expected configuration.
For most application teams, 587 with STARTTLS is the best answer to secure port for SMTP.
SMTP submission port vs relay port
SMTP submission and SMTP relay solve different jobs.
| Job | Best port starting point | What to validate |
|---|---|---|
| App sends password reset, OTP, billing, or notification email | 587 with STARTTLS | SMTP AUTH, TLS, sender alignment, inbox receipt |
| Provider requires implicit TLS | 465 | TLS handshake starts immediately, then AUTH works |
| Network blocks normal submission | 2525 if provider supports it | Provider docs, TLS support, production egress policy |
| Mail server relays to another mail server | 25 | Relay policy, STARTTLS support, DNS, abuse controls |
If your application only needs to send user-facing email, treat this as a submission problem. Start with 587, validate the connection, then validate the received message in a MailSlurp inbox.
Common failure patterns by SMTP port
587 misconfigured as implicit TLS
If you treat 587 as implicit TLS instead of STARTTLS, the connection can fail before authentication. Configure the client to connect first, issue STARTTLS, then authenticate.
465 used with STARTTLS assumptions
Port 465 generally expects TLS from connection start. If your client waits for a plain SMTP banner before TLS, the handshake can fail.
25 blocked in cloud environments
Many cloud providers restrict or throttle outbound 25 traffic for abuse prevention. Use a submission endpoint instead of trying to force application traffic through 25.
2525 copied from another provider
Port 2525 is not guaranteed. Use it only when your provider explicitly supports it and your SMTP client can use the documented TLS mode.
SMTP port troubleshooting matrix
| Symptom | Likely cause | First check |
|---|---|---|
| Connection times out | Firewall, cloud egress policy, wrong host, blocked port | Test host and port reachability from the same environment |
Must issue STARTTLS first | Client authenticated before TLS upgrade | Enable STARTTLS on 587 |
TLS handshake fails on 587 | Client is using implicit TLS on a STARTTLS port | Switch to STARTTLS mode |
TLS handshake fails on 465 | Client expects STARTTLS on an implicit TLS port | Switch to implicit TLS mode |
| SMTP accepts the message but user never receives it | Delivery, filtering, sender auth, or content issue | Send to a MailSlurp inbox and run deliverability checks |
| Works locally but fails in production | Different egress, DNS, secret, TLS, or provider policy | Reproduce from staging or CI with the production-like config |
Security checks to run with port selection
Port selection is only one part of email reliability. Before release, verify:
- SMTP AUTH mechanism and credential behavior
- TLS mode and certificate behavior
- sender-domain alignment with SPF, DKIM, and DMARC
- final message headers and return-path
- inbox receipt and placement outcome
- template variables, OTP codes, reset links, attachments, and unsubscribe or preference links where relevant
Recommended references:
MailSlurp validation workflow for SMTP ports
A working SMTP handshake is not enough. The message also needs to arrive, render correctly, pass important assertions, and avoid avoidable deliverability risk.
Use this workflow:
- Run the SMTP tester to validate host, port, TLS, and authentication behavior.
- Send the final rendered message to a MailSlurp inbox or Email Sandbox.
- Inspect headers, body, links, attachments, OTPs, and reset URLs.
- Check authentication with SPF, DKIM, and DMARC.
- Run Email deliverability testing when sender posture or inbox placement matters.
- Add Email integration testing so critical SMTP workflows stay covered in CI.
FAQ
What is an SMTP port?
An SMTP port is the network endpoint used for SMTP submission or relay. The port tells your client how to connect, but the TLS mode, authentication, and provider policy determine whether the setup actually works.
Which SMTP port is most commonly recommended?
Port 587 with STARTTLS is the most common recommendation for authenticated application submission.
Is port 587 better than port 465?
For most application sending, start with 587 because it is the standard message submission port with STARTTLS. Use 465 when your provider requires implicit TLS.
Is port 465 still valid?
Yes. Port 465 is still used by many providers for implicit TLS submission. It is valid when the provider documents it.
Should applications use port 25?
Usually no. Port 25 is mainly for server-to-server relay and is commonly blocked for application egress.
Why does SMTP work locally but fail in production?
Production often has different firewall rules, secret values, DNS records, TLS libraries, provider policies, and egress restrictions. Test from the same environment path that will send user-facing email.
Does choosing the right SMTP port guarantee delivery?
No. Correct port selection proves the connection path is plausible. You still need authentication checks, message inspection, spam checks, and inbox placement validation.