SMTP ports 25, 465, and 587: which should your app use?
Choose the SMTP port and encryption mode your provider supports, understand submission versus relay, and avoid solving connection errors with the wrong port.
In this guide
For a website or app sending email through a provider, use the provider’s documented submission settings. The usual choices are 587 with STARTTLS or 465 with implicit TLS. Port 25 is mainly for mail servers delivering to other mail servers, not the default choice for your contact form or Python script.
The port and encryption mode are a pair. Entering the right number with the wrong mode can still fail.
The difference in one table
SMTP is the protocol used to transfer outgoing email. Submission means your app hands a message to its sending provider; relay means mail servers pass messages between themselves.
| Port | Usual purpose | Encryption behavior | For a small app |
|---|---|---|---|
| 587 | Authenticated message submission | STARTTLS upgrades the connection before credentials/message data are sent | Use when your provider documents 587 + STARTTLS |
| 465 | Message submission with implicit TLS | TLS begins immediately when connecting | Use when your provider documents 465 + SSL/TLS |
| 25 | Server-to-server SMTP relay | May use STARTTLS; relay policy differs from app submission | Do not switch to it as a generic workaround |
TLS encrypts the connection and verifies the server. Interfaces sometimes call implicit TLS SSL/TLS or just SSL. That label should mean the provider’s modern TLS configuration, not permission to use obsolete SSL protocols.
Properly configured 587 with required STARTTLS and certificate verification can be secure; 465 is not automatically “more secure” just because its number differs. Avoid an option that silently continues without encryption if STARTTLS fails.
Copy a complete settings tuple
Suppose your provider’s instructions say:
Server: smtp.YOUR_PROVIDER_HOST
Port: 587
Encryption: STARTTLS (required)
Authentication: requiredThis is an illustrative pattern, not a working server address. Replace it with the actual host, username, and credential type shown in your provider’s sending settings. The SMTP username may be an API-related value rather than your normal website login.
Use that entire pair in your app or plugin. If it offers SSL/TLS but not STARTTLS, do not enter port 587 and assume the names are interchangeable. Check whether the app has a separate STARTTLS setting or whether the provider supports implicit TLS on 465.
For a documented 465 configuration, the connection must start with TLS immediately. In Python terms, smtplib.SMTP_SSL fits implicit TLS; smtplib.SMTP followed by starttls() fits the upgrade path. In either case, use certificate verification and the provider’s instructions before authenticating.
You do not need to open inbound port 587 on your own VPS just to connect to someone else’s SMTP service. Your app makes an outbound connection. Running your own mail server is a different task.
Match the error to the stage
| Symptom | Check first |
|---|---|
| Timeout or connection refused | Host spelling, port, provider availability, and outbound network restrictions |
| TLS handshake error immediately | Port/encryption pair and certificate verification |
| Authentication rejected | SMTP username, credential type, and sending permission |
| Provider accepts the message but recipient does not see it | Provider delivery log, recipient address, spam folder, and authentication—not another random port |
Some hosts restrict outgoing SMTP, including ports beyond 25. Read your host’s current policy or ask support; switching between numbers does not necessarily remove the restriction. If the provider supports an HTTPS sending API, that may be another supported integration, but it is not interchangeable with SMTP settings in an existing plugin.
Do not log a password, API key, or full message content while diagnosing the connection. If a credential has already been exposed, replace it through the provider’s official interface.
What a successful test proves
A successful authenticated submission means your sending provider accepted the message. It does not prove inbox placement or delivery to every recipient. Check the provider’s delivery status and a permissioned recipient’s actual inbox for the test you intended to send.
SPF, DKIM, and DMARC help receiving systems assess your sender identity; they do not select the SMTP port or repair a TLS-mode mismatch. Our authentication guide explains that separate layer.
Your next step is to open the sending provider’s official SMTP settings and copy its supported host + port + encryption + authentication into the app. If that pair already works, there is no reason to change it or buy a different service just to prefer another port.
Sources and useful links
- RFC 6409: message submission — distinguishes submission, normally on 587, from relay on 25.
- RFC 8314: TLS for email — explains implicit TLS on 465 and secure STARTTLS submission.
- Python smtplib reference — shows the distinct implicit-TLS and STARTTLS methods.