Email glossary · Practical guide
STARTTLS: upgrade the connection using the expected protocol flow
STARTTLS upgrades a protocol connection to TLS after the initial protocol exchange. Implicit TLS begins the TLS handshake immediately; a client must use the mode expected by the endpoint.
Reviewed · Examples are illustrative
Who this helps: Readers checking a term before making an outreach or mailbox decision.
Meaning and common confusion
A port and a secure checkbox are not independent guesses. Pair the provider's endpoint with its documented transport mode. When the pair is wrong, the connection can fail before the credentials are meaningfully tested, so rotating a password may not address the cause.
Source: RFC 8314: transport-mode context
Worked example
This is a synthetic illustration, not a customer result or a live configuration to copy.
Endpoint expects STARTTLS negotiation
Client attempts immediate implicit TLS
Possible outcome: handshake or protocol failure
Review the host, port and mode as one configuration unit.Checks to make
- Use the provider's exact submission instructions.
- Record whether failure happened before or after authentication.
- Retest the corrected transport with a controlled mailbox.
Next step and limits
Use the STARTTLS-versus-implicit-TLS guide for diagnosis. The word secure in a UI may describe a particular mode rather than every encrypted connection. Never infer that disabling an implicit-TLS toggle means credentials should be sent without transport protection.
Source: RFC 8314: transport-mode context
Source references
Worked examples are illustrative. Editorial procedures are suggested methods, not measured performance claims or promises of additional product features.
Related guides
- STARTTLS versus implicit TLS: diagnose the handshake boundary →
- SMTP port 465 versus 587: match the provider's transport mode →