Skip to main content

​
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:
1

SendKit initiates connection

SendKit’s server connects to the recipient’s mail server and announces TLS support.
2

Recipient responds

The recipient’s server confirms TLS support and sends its certificate.
3

Certificate verification

SendKit verifies the certificate is valid and trusted.
4

Encrypted connection established

Both servers agree on encryption parameters and establish a secure channel.
5

Email delivered securely

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 TLSWhat happens
YesEmail sent encrypted
NoEmail 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 TLSWhat happens
YesEmail sent encrypted
NoEmail 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:
VersionStatus
TLS 1.0Deprecated — insecure
TLS 1.1Deprecated — insecure
TLS 1.2Widely supported, secure
TLS 1.3Latest, 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.