What Is STARTTLS?

How the upgrade works

An SMTP conversation can begin before TLS is active. When the server advertises the STARTTLS extension and the client uses it successfully, the peers negotiate TLS before continuing the mail exchange. The extension is a way to establish transport protection within that connection. It is different from a service that starts with TLS immediately, and the two connection styles should not be treated as interchangeable settings.

After the upgrade, the client learns the server's capabilities again in the protected session. Authentication capabilities and other advertised features can differ from what was available beforehand. An operator troubleshooting submission should therefore inspect the sequence of events rather than assuming that seeing a STARTTLS advertisement proves credentials were subsequently accepted or a message was sent.

Availability and enforcement are different

Supporting STARTTLS does not by itself say what happens if negotiation fails. Opportunistic transport and a policy requiring authenticated TLS can have different failure behavior. MTA-STS is one mechanism participating senders can use to apply receiving-domain transport policy. Check the actual policy and provider behavior instead of interpreting the extension's presence as proof that unprotected delivery is impossible.

What to inspect in outbound infrastructure

Keep a diagnostic record for the actual sending route: the peer hostname, advertised capabilities, negotiation result, certificate checks and final SMTP response. A timeout after negotiation is a different problem from the server not offering STARTTLS. A successful upgrade also does not establish inbox placement, message-level encryption or permission to send. If a managed provider controls the connection, ask for evidence about that provider's implementation rather than changing unrelated DNS records. Review the specific connection and failure class first; repeating a campaign send is not a substitute for understanding the transport result.