Definition
The email TLS handshake is the process by which two mail servers negotiate an encrypted connection before exchanging messages. TLS (Transport Layer Security) protects email in transit so that a third party observing the network cannot read the message content or credentials. The handshake is the initial exchange that establishes the encryption keys and verifies the identity of the servers.
How It Works
When a sending server connects to a receiving server to deliver mail, the two sides perform a handshake before any message data moves. The sequence is broadly:
- The client sends a hello listing the TLS versions and cipher suites it supports.
- The server responds with its chosen settings and presents its digital certificate.
- The client validates the certificate against trusted authorities.
- The two sides exchange key material to establish a shared session key.
- Both confirm the encrypted channel is ready, and SMTP conversation proceeds inside it.
The certificate contains the server's public key and its identity. In some configurations, the sending server also presents a client certificate, a practice used in mutually authenticated setups.
Why It Matters for Email
Encryption in transit protects confidentiality, but it also plays a role in deliverability. Mailbox providers increasingly require or prefer TLS, and some will downgrade trust for connections that are not encrypted or that use outdated protocols. Strong TLS support is part of a modern, well-configured sending infrastructure.
Two important extensions support TLS for email:
- STARTTLS upgrades an existing plain-text SMTP connection to an encrypted one on the standard port.
- MTA-STS and TLS reporting allow domain owners to publish a policy requiring TLS and to receive reports when encryption fails, which is why email providers publish their own TLS policies.
Email TLS should not be confused with web TLS. The same cryptographic principles apply, but email uses SMTP-specific extensions and can involve multiple server-to-server hops, each of which requires its own handshake.
Example
A sending server connects to a recipient's mail server and begins a TLS handshake. The receiving server presents a certificate for its hostname, which the sender validates, and the two sides agree on a cipher suite. The message then transfers inside the encrypted session, invisible to anyone inspecting the network path.
Was this useful?
Related Glossary Terms
Apple App Password (Email)
An Apple app password is a generated, app-specific password used to sign into an email account through clients that do not support two-factor authentication.
Email Authentication Protocols
Email authentication protocols are technical standards that verify the identity of an email sender, helping mailbox providers distinguish legitimate mail from spam and phishing.
BIMI
BIMI (Brand Indicators for Message Identification) is an email standard that allows brands to display their logo next to their emails in supported email clients. It requires DMARC enforcement at quarantine or reject policy.
Bounce Classification
Bounce classification uses SMTP codes (550, 551, 552, 553, 554, 450, 451, 452) and enhanced status codes to categorise permanent and transient delivery failures.
Email Deliverability
Email deliverability is the ability to land in the recipient's inbox rather than the spam folder. It depends on sender reputation, authentication, list quality, and content practices.
DKIM (DomainKeys Identified Mail)
DKIM (DomainKeys Identified Mail) is an email authentication method that uses digital signatures to verify that an email was not tampered with during transit and comes from a authorised domain.
Frequently Asked Questions
No. TLS protects email only while it is in transit between servers. Once a message reaches the recipient's server, it may be stored unencrypted depending on that server's policies.
The sending server may fall back to plain text, depending on its configuration. Senders can require TLS through policy to prevent this, though opportunistic TLS is still the most common default.
A receiving server must present a certificate for inbound TLS. Sending servers do not usually need their own certificate unless the recipient requires mutual authentication, but they must be able to validate the recipient's certificate.