SMTP port 465 versus 587: match the provider's transport mode

Define the decision

A port number alone does not describe a working connection. The client and server must agree on how encryption starts, and authentication happens after that transport is established. Randomly changing ports while retaining the previous encryption setting can create a different failure rather than solve the original one.

Work through the procedure

1. Open the provider's current submission settings and record the host, port, transport and authentication method as one configuration.
2. Compare the saved connection with that complete configuration, not just the port field.
3. Run a scoped connection test and distinguish handshake errors from authentication errors.
4. If the provider supports more than one combination, change only one complete supported pairing at a time and record the result.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Provider-supported pairing A: submission host + 465 + implicit TLS
Provider-supported pairing B: submission host + 587 + STARTTLS
Do not assume both are offered by every provider.
A credential error after successful TLS is a different stage from a failed handshake.

Read the result

The useful diagnostic is the stage reached, not which port has the larger number. A successful encrypted connection followed by rejected credentials points toward identity or policy. A handshake failure points toward transport, endpoint or certificate investigation before password changes.

Check before moving on

1. Confirm the hostname is the provider's submission endpoint, not an unrelated website host.
2. Keep authentication credentials out of logs shared for support.
3. Retest a controlled send after the connection test succeeds.

Limits and next action

RFC 8314 describes implicit TLS submission on 465 and STARTTLS usage on 587; it does not promise every service enables both. Zintara's SMTP test distinguishes those transport modes. Use the provider's supported configuration rather than disabling encryption to get a passing result.

Source: RFC 8314: TLS for email submission and access