STARTTLS vs Implicit TLS: How Email Encrypts in Transit

Your mail client asks one question you probably clicked past: STARTTLS or SSL/TLS? That single dropdown is the STARTTLS vs implicit TLS email choice, and it decides how your connection to a mail server gets encrypted.

Both protect mail in transit — the hop between your app and the server, or between two servers. Neither encrypts the message itself once it lands. This guide explains what each does, why RFC 8314 pushed clients toward implicit TLS in 2018, and which one to pick.

The verdict, up front#

For connecting a mail client to a server — sending on submission, reading over IMAP or POP — implicit TLS is the safer default. It encrypts the whole session from the first byte, so there is no plaintext moment for an attacker to tamper with. RFC 8314, published in January 2018, tells mail clients to prefer it.

STARTTLS is not obsolete, though. It is still how one mail server hands mail to another over port 25, where no implicit-TLS equivalent exists. Configured to require TLS it is strong; left opportunistic it can be stripped.

So the honest answer is not that one is broken. Choose implicit TLS when your client offers it, and know that STARTTLS on the server-to-server hop needs extra help — MTA-STS or DANE — to be trustworthy. Neither option is end-to-end encryption. Both secure the pipe, not the letter.

STARTTLS vs implicit TLS at a glance#

Here is the whole comparison in one view. Implicit TLS is what most mail clients label SSL/TLS in their account settings; STARTTLS is sometimes shown as TLS (STARTTLS) or opportunistic TLS.

What STARTTLS actually does#

STARTTLS is an upgrade command. The connection opens in plaintext on an ordinary port, the client sends EHLO, and the server advertises STARTTLS among its capabilities. The client then issues the STARTTLS command, both sides run the TLS handshake, and only after that does the real conversation begin encrypted.

RFC 3207, the SMTP STARTTLS standard, was published in February 2002 and is on the IETF Standards Track. It defines STARTTLS as an EHLO keyword with no parameters. After the handshake the protocol resets: the server must discard anything it learned from the client beforehand, the client must discard anything it learned from the server, and the client sends EHLO again over the now-encrypted channel. That reset is what stops an attacker injecting commands into the cleartext prologue.

The same upgrade pattern exists beyond SMTP. IMAP has a STARTTLS command on port 143; POP3 has a STLS command on port 110. Those are defined in their own standards, not in RFC 3207, but the shape is identical: start in the clear, then upgrade.

What implicit TLS actually does#

Implicit TLS skips the negotiation. The moment the connection opens, the TLS handshake runs — before any SMTP, IMAP or POP command is sent. There is no cleartext prologue and no STARTTLS command, because the whole session is wrapped in TLS from the first byte.

Implicit TLS uses dedicated ports: 465 for mail submission, 993 for IMAP, and 995 for POP3. RFC 8314, titled Cleartext Considered Obsolete, formally registered port 465 as the submissions service in January 2018 and updated six older email RFCs. Its recommendation is direct: mail clients should use implicit TLS in preference to connecting in cleartext and negotiating with STARTTLS, and servers offering implicit TLS should be advertised ahead of STARTTLS-only ones.

Because there is no plaintext step, implicit TLS removes an entire category of attack. Someone on the path cannot quietly convince the two sides to skip encryption, because encryption is not optional and not deferred — it is the connection.

The STARTTLS stripping attack#

The weakness in STARTTLS is the cleartext prologue. Before the upgrade happens, the connection is readable and modifiable by anyone on the path. That is not a bug in the protocol; it is the trade-off of starting in the clear.

RFC 3207's own security considerations spell out the attack: a man-in-the-middle can delete the server's 250 STARTTLS response. The client then never sees TLS on offer, does not send the STARTTLS command, and — if it is willing to fall back — continues in plaintext. The mail goes through unencrypted, and nothing looks wrong to either party. This is the STARTTLS stripping, or downgrade, attack.

The defense named in the standard is to require TLS: both clients and servers must be able to be configured to refuse to proceed unless the handshake succeeds. When STARTTLS is enforced rather than opportunistic, a stripped connection fails instead of silently downgrading. Implicit TLS sidesteps the whole problem, because there is no advertisement to delete.

Where STARTTLS still wins#

STARTTLS earns its place in two situations. The first is server-to-server relay on port 25. When one mail server delivers to another, there is no implicit-TLS port for the handoff — port 465 is for a client submitting mail, not for relay. STARTTLS is the only way to encrypt that hop, and opportunistic STARTTLS encrypts far more inter-server mail than would travel protected otherwise.

The second is backward compatibility. Because a STARTTLS connection begins like an ordinary plaintext one, a server that does not support TLS still receives the mail rather than rejecting it. For public mail exchange, where you cannot dictate what the other side runs, degrading to plaintext beats bouncing the message.

The catch is that both of these strengths — reaching everyone, never bouncing — are exactly what a stripping attack abuses. That is why the modern answer for the relay hop is not to abandon STARTTLS but to make it enforceable, which is where MTA-STS and DANE come in.

Where implicit TLS wins#

For the client-to-server legs — submitting outbound mail, reading inbound mail — implicit TLS is the stronger choice, and RFC 8314 says so plainly.

There is no cleartext window, so there is nothing to strip. The failure mode is honest: if TLS cannot be established, the connection simply does not open, rather than quietly falling back to plaintext. That is easier to reason about and easier to monitor.

It is also simpler. One port means one behaviour: encrypted. There is no capability advertisement to trust, no reset step, and no dependence on both sides being configured to require the upgrade. For a person setting up a mail account, SSL/TLS on 993 has fewer ways to go wrong than STARTTLS on 143, and please make sure it is mandatory. This is why, for submission and access, the direction of travel is one-way, and many providers now steer clients onto 465, 993 and 995.

What each one costs, and what to verify#

Neither protocol costs anything. STARTTLS and implicit TLS are open IETF standards, royalty-free to implement, and built into essentially every mail server and client. There is no license, no tier, and no vendor behind either one.

The real variable is provider support, and that changes. Some providers have retired plaintext-with-STARTTLS submission entirely and accept only implicit TLS; others still offer both. Port numbers can differ for niche or self-hosted setups.

So before you rely on a specific port, check your provider's own current documentation. The settings page you get when you add an account is the source of truth, not a blog, and it can change without notice. As of August 2026 the common defaults are 465 or 587 for sending and 993 for IMAP — but confirm rather than assume.

Who each is genuinely for#

Two different readers arrive at this question: the person configuring a mail app, and the person running mail infrastructure. Here is the short version for each.

A third option: enforce TLS on the relay hop#

STARTTLS on port 25 does not have to stay opportunistic. Two standards let a receiving domain signal that TLS is mandatory, so a stripped connection fails instead of downgrading.

MTA-STS, defined in RFC 8461 (2018), lets a domain publish a policy over HTTPS that says: require TLS to reach me. A sending server that honours the policy refuses to deliver in plaintext. DANE for SMTP, defined in RFC 7672 (2015), does the same job through DNSSEC-signed TLSA records, binding the server's certificate to DNS. Both turn opportunistic STARTTLS into enforced TLS on the hop where implicit TLS is not available.

They are complements, not replacements. You still run STARTTLS; MTA-STS or DANE is what makes stripping it a delivery failure rather than a silent success. Each has its own trade-offs and setup, covered in their own guides.

Where an email client fits#

None of this is something a mail app decides for you. Your provider sets the ports and TLS modes, and DNS carries any MTA-STS policy or DANE record. A client's job is to connect over the strongest option offered and then get out of your way.

AI Emaily is an AI email client. When it connects to a mailbox over IMAP or SMTP it uses the implicit-TLS ports; for Gmail and Outlook it goes through their APIs over HTTPS rather than raw IMAP. It does not publish MTA-STS records or change your provider's relay settings — that is not a mail client's job, and we will not pretend otherwise.

What it does do is what happens after mail arrives securely: triage the inbox, draft replies from a Context brain you set, and hold every send for your approval, with no training on your mail. We build AI Emaily.