For an application or mail client sending through a provider, use the SMTP host, port, TLS mode, and authentication method that the provider specifies. The common choices are port 587 with required STARTTLS or port 465 with implicit TLS. Port 25 is primarily for mail transfer between servers, not the default for a password-reset or invoice app.
| Port | Usual role | How TLS starts | Typical client setting |
|---|---|---|---|
| 25 | Usually mail-server relay | SMTP starts without TLS; STARTTLS may be negotiated according to server policy | Use for submission only if your provider explicitly designates it |
| 587 | Message submission | SMTP greeting first, then STARTTLS upgrades the connection |
“STARTTLS” or “TLS upgrade”; require successful TLS before authentication or sending |
| 465 | Message submission over implicit TLS | TLS handshake begins immediately on connection | “SSL/TLS,” “implicit TLS,” or “TLS from connect” |
These are protocol roles, not guarantees about any particular provider. The IANA port registry identifies 587 as submission and 465 as submissions; RFC 6409 distinguishes message submission from relay on 25. A provider can publish different supported settings, so check its current instructions before changing a working configuration.
Submission and relay are different jobs
A mail client or application submits a new message to a mail submission agent. That service checks whether the sender is authorized and accepts the message for subsequent processing. A mail transfer agent then relays a message toward another mail server. Both use SMTP, but they operate under different authorization and transport policies.
If an app sends account emails through a hosted mail service, configure the provider’s submission endpoint. Do not point it at a recipient domain’s MX server on port 25 and expect the MX server to accept authenticated client submission.
Port 25 is not exclusively relay in every possible deployment. RFC 6409 permits a site to designate particular port-25 hosts for submission. That is a site-specific arrangement, not a reason to choose 25 when your provider documents 465 or 587. Networks may also restrict outbound port 25. A timeout on that port does not prove your username or password is wrong.
Port 587: require STARTTLS before sending
On 587, the client connects to an SMTP submission service and receives its greeting. The client sends EHLO, sees the server’s advertised capabilities, and issues STARTTLS. After a successful TLS handshake, the SMTP conversation continues inside the encrypted connection.
The important client setting is required TLS, not merely “use TLS if available.” If STARTTLS is unavailable or the handshake or certificate check fails, the app must not continue by sending credentials or message content over an unprotected session. Use the provider’s approved authentication method only after TLS is established.
A “TLS” checkbox may mean different things in different applications. Confirm that your client’s setting for 587 means STARTTLS, not an immediate TLS handshake. An implicit-TLS client pointed at a STARTTLS endpoint will speak the wrong protocol at connection start.
Port 465: TLS begins at connection start
On 465, the client starts the TLS handshake as soon as the TCP connection opens. SMTP commands follow only after that handshake succeeds. In an application’s settings this mode may be called implicit TLS, SSL/TLS, or TLS from connect. The older “SSL” label in a UI does not mean you should enable obsolete SSL protocol versions; use the provider’s supported modern TLS configuration.
Port 465 is not deprecated as an SMTP submission port. RFC 8314 defines the submissions service on 465 and recommends implicit TLS for mail submission. It also recognizes STARTTLS on 587. The RFC says correctly implemented 587 with required TLS and 465 with implicit TLS have no significant difference in security properties when both sides require TLS before submission. Choose the mode your provider supports and configure it correctly rather than treating the port number as a security score.
A STARTTLS client pointed at 465 expects a plain SMTP greeting that the server will not send before TLS. That mismatch can appear as a timeout, immediate disconnect, or TLS/protocol error.
Port 25: understand the relay policy
Mail servers use port 25 to exchange messages. STARTTLS can protect a server-to-server connection, but the relay’s TLS policy is a separate question from an application’s submission policy. RFC 8314’s submission guidance does not claim to solve TLS policy for every later relay hop.
For a self-managed mail server, check the route it uses to reach other mail servers and the network’s outbound-port policy. For an app that merely needs to hand mail to a provider, use that provider’s submission instructions. Opening port 25 does not fix a client configured with the wrong hostname, TLS mode, or credentials.
Check the four settings together
A reliable submission configuration has four matching parts:
- Hostname: Use the provider’s published SMTP submission hostname, not an unrelated MX record or web hostname.
- Port and TLS mode: Match 587 with STARTTLS or 465 with implicit TLS when those are the provider’s documented options. Require successful TLS, and validate the server certificate against the expected hostname.
- Authorization: Use the provider’s approved account, token, OAuth flow, or other supported method. An SMTP server may require account-specific sender permissions as well as successful login.
- Network path: Permit the application to reach the selected hostname and TCP port. A firewall or provider restriction can prevent the TCP connection before TLS or authentication begins.
For ordinary client submission, require both encrypted transport and authorized submission. RFC 6409 requires a submission agent to reject unauthenticated submission by default, while permitting independently established authorization in a protected environment. Do not turn off authentication or certificate validation merely to make a test pass.
Test the TLS handshake without sending mail
On a system with OpenSSL 3.x, s_client can check the connection and certificate without supplying a password or submitting a message. Replace smtp.example.net with the exact hostname from your provider. These are diagnostic connections; they do not authenticate or send mail.
For 587 with STARTTLS:
openssl s_client -connect smtp.example.net:587 \
-starttls smtp \
-servername smtp.example.net \
-verify_hostname smtp.example.net \
-verify_return_error -brief
For 465 with implicit TLS:
openssl s_client -connect smtp.example.net:465 \
-servername smtp.example.net \
-verify_hostname smtp.example.net \
-verify_return_error -brief
The OpenSSL s_client documentation documents these flags. -starttls smtp performs the SMTP upgrade before the TLS handshake; it is absent for implicit TLS. -servername supplies the TLS server name, while -verify_hostname checks the expected certificate name and -verify_return_error stops on a verification error. A successful handshake proves neither that your credentials work nor that a message will be delivered. Exit the interactive connection when you have the result; do not type credentials into a terminal probe.
If the provider uses a private certificate authority, the testing host must trust the appropriate CA to validate it. Do not hide a certificate failure by disabling verification.
Diagnose the failure by its stage
No TCP connection or a timeout: Confirm the provider hostname, DNS answer, port, local firewall, container or cloud egress rule, and provider status. Test from the same host or runtime as the failing app. A successful test from your laptop does not verify a production server’s outbound path.
TLS handshake or certificate error: Check that the client’s mode matches the port. Then check the hostname, certificate chain, trust store, and system clock. A certificate presented for a different name is not fixed by changing the SMTP password.
Authentication rejected: The connection and TLS may be fine. Check the provider’s current authentication method, account permissions, and allowed sender identity. Avoid placing passwords or tokens in shell arguments, tickets, or shared logs.
Message rejected after authentication: Read the SMTP response and the provider’s message or account policy. The address, sender authorization, message content, or quota can cause rejection after login succeeds. Do not label every SMTP error a “TLS port problem.”
Submission accepted but no inbox arrival: Acceptance by the first server is only a handoff. Check its message ID, queue or provider activity, later relay and delivery status, and any rejection or bounce. TLS on the first hop does not guarantee transport encryption on every later hop, inbox placement, or end-to-end confidentiality. RFC 8314 explicitly distinguishes submission TLS from end-to-end email encryption.
Keep useful evidence without logging secrets
For a recurring failure, keep the connection time, configured hostname and port, TLS mode, certificate-verification result, SMTP response code, and provider message ID when available. Avoid logging SMTP AUTH exchanges, passwords, access tokens, or complete messages just to diagnose a port mismatch.
If your application or mail server emits relevant operational logs, Fluxtail log management can help search them alongside other service events. Fluxtail is a place to inspect those logs; it is not the SMTP sender or a substitute for your mail provider’s delivery records. For general guidance on interpreting log entries, see how to read logs.