Definition
TLS (Transport Layer Security) for email is the encryption protocol that secures SMTP connections between mail servers. When a sending server connects to a receiving server, the STARTTLS command upgrades the plaintext SMTP connection to an encrypted TLS connection, protecting the email contents and authentication credentials from interception. TLS is the primary mechanism for securing email in transit, used for both incoming (receiving from other servers) and outgoing (sending to recipient servers) connections.
Opportunistic TLS, the default behaviour for most MTAs, attempts to upgrade the connection with STARTTLS but proceeds without encryption if the receiving server does not support it or if the TLS negotiation fails. This behaviour makes downgrade attacks possible: an attacker can prevent the STARTTLS negotiation and force the connection to remain unencrypted without the sender knowing. Forced TLS (also called mandatory TLS) rejects the connection if STARTTLS is not supported or fails, ensuring only encrypted connections are used. MTA-STS (MTA Strict Transport Security) provides a mechanism for domains to publish policies that specify whether TLS is required and which certificates are acceptable.
TLS version support is an important security consideration. TLS 1.0 and 1.1 are deprecated due to known security vulnerabilities and should not be used. TLS 1.2 remains widely supported and provides adequate security for email transmission. TLS 1.3, the current standard, offers improved security and performance through reduced handshake latency. As of 2025, approximately 70-80% of receiving mail servers support TLS 1.3, though TLS 1.2 remains the most universally supported version. Sending servers should support TLS 1.2 and 1.3 and prefer 1.3 when available.
Best Practices
Disable TLS 1.0 and 1.1 on all sending and receiving mail servers. These protocol versions have known vulnerabilities (POODLE, BEAST, CRIME) that compromise connection security. TLS 1.2 should be the minimum accepted version. Verify your MTA configuration does not allow negotiation to TLS 1.0 or 1.1. This applies to both outbound (sending) and inbound (receiving) server configurations.
Implement MTA-STS to enforce TLS for your receiving domain. Publish an MTA-STS policy file (TXT record and policy file) that specifies: whether TLS is required for sending to your domain, which TLS versions are accepted, and which certificates are valid. MTA-STS policies are cached by sending servers and checked on every connection. This provides stronger TLS enforcement than opportunistic STARTTLS alone.
Enable TLSRPT (TLS Reporting) to receive reports on TLS connection failures. TLSRPT publishes a reporting address (RUA) where sending servers can report TLS connection issues: failed STARTTLS negotiations, certificate problems, and TLS version mismatches. These reports provide visibility into TLS delivery problems that would otherwise be invisible. Monitor TLSRPT reports regularly and investigate any patterns.
Use strong cipher suites and key exchange algorithms. Configure your MTA to use only ciphers that provide forward secrecy (ECDHE, DHE) and strong encryption (AES-256-GCM, ChaCha20-Poly1305). Disable weak ciphers (RC4, DES, 3DES) and export-grade ciphers. The NCSC and BSI both provide recommended SMTP TLS cipher configurations.
Test your TLS configuration regularly using automated tools. Use tools like SMTP TLS Checker, testssl.sh, or CheckTLS to validate your outgoing and incoming TLS configurations. These tools identify version support issues, weak ciphers, certificate problems, and MTA-STS configuration errors. Run tests after any configuration change and at least quarterly.
Related Glossary Terms
DMARC Alignment
DMARC identifier alignment determines whether the domain in the From header matches the domains used in SPF and DKIM authentication. Strict or relaxed.
Email Bandwidth
Email sending bandwidth and throughput refer to the rate at which emails can be delivered, typically 100-500 emails/second per IP. Bandwidth planning ensures campaigns complete within desired delivery windows.
Email BIMI VMC
BIMI Verified Mark Certificate (VMC) certifies brand logo ownership for display in supporting email clients. VMCs cost £1,500-2,000+ per year per logo and require DMARC reject or quarantine policy plus SVG logo format.
Email Blacklist
An email blacklist (DNSBL) is a real-time database of IP addresses or domains known for sending spam or unwanted email.
Email Bulkhead
Email bulkhead pattern isolates transactional emails from marketing sends using separate IPs, subdomains, and servers. This protects critical deliverability and prevents marketing issues from affecting essential transactional messages.
Email DANE
DANE (DNS-based Authentication of Named Entities) uses TLSA records to authenticate STARTTLS connections for SMTP, preventing TLS downgrade and man-in-the-middle attacks. It requires DNSSEC to function securely.
Frequently Asked Questions
STARTTLS is the SMTP command that upgrades an unencrypted SMTP connection to a TLS-encrypted connection. TLS is the encryption protocol itself. The STARTTLS command initiates the TLS handshake. If STARTTLS is not supported or fails, opportunistic TLS configurations will proceed without encryption, while forced TLS configurations will reject the delivery.
MTA-STS (MTA Strict Transport Security) is a standard that allows domains to publish policies specifying that TLS is required for email delivery to their servers. It prevents downgrade attacks by telling sending servers to reject connections that cannot establish TLS. MTA-STS policy files are published on a well-known HTTPS URL and distributed via DNS TXT records.
At minimum, TLS 1.2 should be supported. TLS 1.3 is strongly recommended as it provides better security and performance. TLS 1.0 and 1.1 must be disabled due to known vulnerabilities. A well-configured mail server should support TLS 1.2 and 1.3, prefer TLS 1.3 when available, and reject connections that cannot meet TLS 1.2 minimum.
Use online TLS checking tools that simulate SMTP connections to your domain's MX hosts. These tools report: supported TLS versions, accepted cipher suites, certificate validity and chain, and whether MTA-STS policies are configured correctly. Regular testing is recommended as TLS configurations can change, and some certificates expire.
TLSRPT (TLS Reporting) enables organisations to request reports from sending servers about TLS connection failures. The reports are sent to a specified email address or HTTPS endpoint and contain details of any TLS negotiation failures, including failure type, timestamps, and connecting server information. TLSRPT provides visibility into TLS delivery issues that would otherwise go undetected.