SSL/TLS for Email: SMTP Encryption Explained

SSL/TLS for email encrypts the connection used to submit, relay, or retrieve messages. In SMTP that almost always means STARTTLS, where a plain connection upgrades to TLS partway through the session. It protects mail while the mail is moving; it does nothing once the message lands in a mailbox.

That is the foundation behind the phrase "TLS email delivery," and it is specified in RFC 3207.

What SSL/TLS protects in email

SSL is the older name and TLS is the modern protocol family; a vendor still telling you to enable SSL has a documentation problem. TLS protects three separate hops: submission from a mail client to your sending server, relay between mail servers, and retrieval over IMAP or POP.

The boundary people miss is storage. Once mail reaches a provider it can be scanned, indexed, forwarded, or downloaded according to that provider's systems and the user's settings. If the body needs to stay secret from everyone in the middle, that is a job for S/MIME or PGP.

Four terms get used interchangeably and shouldn't be:

The SSL/TLS glossary entry goes deeper on the vocabulary; our MTA-STS generator will produce a starting policy.

How STARTTLS works

STARTTLS begins as an ordinary SMTP session. The receiver advertises STARTTLS among its capabilities, the sender asks to upgrade, and both sides negotiate TLS and restart the conversation inside the encrypted connection.

S: 220 mx.example.com ESMTP
C: EHLO sender.example
S: 250-STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
... TLS negotiation ...
C: EHLO sender.example
C: MAIL FROM:<bounce@example.com>

The catch is that traditional SMTP prefers delivery over encryption. When the handshake fails and no stricter policy applies, some senders fall back to plain delivery rather than queue the message; an attacker able to strip the STARTTLS advertisement out of the greeting gets the same outcome. RFC 8689 describes REQUIRETLS precisely because opportunistic STARTTLS is limited from a security standpoint (RFC 8689). MTA-STS closes that gap from the receiving side.

Which ports to use

Send from an application or mail client on port 587 with STARTTLS. Port 465 is implicit TLS submission and is fine too. Port 25 is server-to-server delivery, not client submission; a setup guide telling you to authenticate on 25 is out of date.

Retrieval uses different ports entirely: 993 for IMAPS, 995 for POP3S. Putting a retrieval port where a submission port belongs is one of the more common self-inflicted outages I see. RFC 8314 treats cleartext mail access as obsolete and recommends TLS-protected submission and access throughout (RFC 8314).

How to confirm a message actually used TLS

Check the headers. Received: lines often carry with ESMTPS alongside a TLS comment naming the protocol version and cipher. Formatting varies by provider, but it is enough to answer the question.

with ESMTPS id abc123
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384);

Read the receiving server's trace line rather than the visible From: field; the TLS details sit inside a Received: comment near the queue ID. If the trace shows plain SMTP across a public hop, investigate the route. Our email header analyzer parses those traces, and understanding email headers explains the rest.

One last distinction. A message can arrive over TLS 1.3 and still be a forgery, because TLS says nothing about who wrote it. That is what SPF, DKIM, and DMARC are for, and the email authentication entry covers how the three fit together. Run both layers.