> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sendkit.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# TLS
> Learn how TLS encrypts email in transit and the difference between opportunistic and enforced modes.
## What is TLS?
TLS (Transport Layer Security) is a protocol that encrypts the connection between two mail servers when transferring an email. It ensures that the email content can't be read or tampered with by anyone intercepting the traffic between the sender and recipient's servers.
TLS protects emails **in transit** — while they're being transmitted from one server to another. It does not encrypt the email at rest (stored on the server).
## How TLS works in email
When SendKit sends an email to a recipient's mail server, the two servers perform a **TLS handshake**:
SendKit's server connects to the recipient's mail server and announces TLS support.
The recipient's server confirms TLS support and sends its certificate.
SendKit verifies the certificate is valid and trusted.
Both servers agree on encryption parameters and establish a secure channel.
The email is transmitted over the encrypted connection. Anyone intercepting the traffic sees only encrypted data.
Once the encrypted connection is established, the email is transmitted securely. Anyone intercepting the traffic would see encrypted data instead of the email content.
## TLS modes in SendKit
SendKit supports two TLS modes per domain, configurable from the **Configuration** tab on your domain detail page:
### Opportunistic TLS (default)
SendKit **attempts** a TLS connection. If the recipient's server supports TLS, the email is sent encrypted. If it doesn't, the email falls back to an unencrypted connection.
| Recipient supports TLS | What happens |
| ---------------------- | ---------------------- |
| Yes | Email sent encrypted |
| No | Email sent unencrypted |
This is the default and recommended mode for most senders. It maximizes deliverability while encrypting whenever possible. The vast majority of mail servers today support TLS — Gmail, Outlook, Yahoo, and most business email providers all do.
### Enforced TLS
SendKit **requires** a TLS connection. If the recipient's server doesn't support TLS, the email is **not sent** and returns an error.
| Recipient supports TLS | What happens |
| ---------------------- | ------------------------------ |
| Yes | Email sent encrypted |
| No | Email rejected — not delivered |
Use enforced TLS when you have strict security requirements and would rather not deliver an email than send it unencrypted. This is common in healthcare, finance, and other regulated industries.
Enforced TLS means some recipients may not receive your emails if their mail server doesn't support TLS. Most major providers support TLS, but some older or smaller mail servers do not.
## TLS versions
TLS has gone through several versions:
| Version | Status |
| ------- | ------------------------------- |
| TLS 1.0 | Deprecated — insecure |
| TLS 1.1 | Deprecated — insecure |
| TLS 1.2 | Widely supported, secure |
| TLS 1.3 | Latest, most secure and fastest |
SendKit supports TLS 1.2 and TLS 1.3. The version used depends on what the recipient's server supports — SendKit always negotiates the highest available version.
## MTA-STS
MTA-STS (Mail Transfer Agent Strict Transport Security) is a standard that lets a domain declare that it supports TLS and that sending servers should refuse to deliver email without encryption.
It's similar to HSTS for websites — it prevents downgrade attacks where an attacker forces an unencrypted connection.
If a recipient's domain publishes an MTA-STS policy, SendKit respects it and will only deliver over TLS, regardless of your domain's TLS mode setting.
## DANE
DANE (DNS-based Authentication of Named Entities) is another standard for securing email transport. It uses DNSSEC to publish the recipient server's TLS certificate in DNS, preventing man-in-the-middle attacks even if a certificate authority is compromised.
DANE is less widely deployed than MTA-STS but provides stronger guarantees. SendKit supports DANE when the recipient's domain has it configured.
## Checking TLS in email headers
You can verify that TLS was used by checking the email headers. Look for the `Received` header:
```
Received: from send.acme.com (send.acme.com [1.2.3.4])
by mx.google.com with ESMTPS id abc123
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384)
```
The `ESMTPS` indicates TLS was used (vs `ESMTP` for unencrypted). The version and cipher suite are also shown.
## FAQ
No. TLS encrypts emails **in transit** between servers. Once the email arrives at the recipient's server, it's decrypted and stored. The recipient's email provider (and potentially their administrator) can read it. For end-to-end encryption, you'd need something like PGP or S/MIME, which are not related to TLS.
For most senders, opportunistic TLS is the right choice. It encrypts when possible without risking delivery failures. Use enforced TLS only if your compliance or security requirements mandate that no email be sent unencrypted, and you accept that some recipients may not receive your emails.
The vast majority. Google reports that over 95% of inbound email to Gmail is encrypted with TLS. Major providers like Outlook, Yahoo, and iCloud all support TLS. The remaining percentage is mostly small, self-hosted, or legacy mail servers.