← Patterns / SP-020

Email Transport Layer Security (TLS) Pattern

Email remains one of the most widely used communication channels in business, and one of the most vulnerable. Messages traverse the internet in clear text by default, passing through multiple mail transfer agents (MTAs) before reaching their destination. Any network observer along that path can read, modify, or inject messages. The Email TLS pattern addresses this by securing the transport layer between mail gateways, providing confidentiality and integrity protection for email in transit without requiring any action from end users. The pattern operates at the SMTP level, using STARTTLS to upgrade plain-text MTA-to-MTA connections to TLS-encrypted sessions. It supports two modes: opportunistic TLS, where encryption is attempted but falls back to clear text if the receiving MTA does not support it, and enforced TLS, where the connection is refused if encryption cannot be established. Opportunistic TLS provides broad coverage with no delivery impact but cannot guarantee confidentiality. Enforced TLS guarantees encryption but risks blocking email delivery if the partner's MTA has a certificate issue, a misconfiguration, or a temporary failure. Most organisations use opportunistic TLS as the baseline and enforced TLS selectively for high-sensitivity business partners. This is an infrastructure-level pattern -- it protects email between gateways, not end-to-end. Once a message arrives at the receiving MTA, it is decrypted and handled in clear text within the recipient's internal infrastructure. If a third-party email outsourcer operates the MTA, they have access to the decrypted message content. For organisations that require end-to-end confidentiality (sender to recipient), S/MIME or PGP-based encryption is needed in addition to or instead of this pattern. The Email TLS pattern is best understood as a baseline transport protection that covers the most exposed segment of the email delivery path. Organisations with many business partners face particular challenges. Each enforced TLS connection is a point-to-point relationship that must be configured, tested, and monitored individually. Certificate changes, MTA upgrades, or network issues at the partner side can break enforced TLS connections without warning, causing email to queue or bounce. Continuous monitoring of TLS connection status is essential, along with operational procedures to temporarily relax enforcement when technical issues arise and re-enable it once resolved. Modern email security has moved beyond basic TLS to include complementary standards: MTA-STS (RFC 8461) provides a mechanism for receiving domains to advertise their TLS policy and prevent downgrade attacks, DANE (RFC 7672) uses DNSSEC to bind certificates to domain names, and SMTP TLS Reporting (RFC 8460) enables receiving domains to report TLS connection failures back to senders. Together with SPF, DKIM, and DMARC for sender authentication, these standards form a layered email security architecture of which transport TLS is the foundation.

Release: 26.02 Authors: Aurelius, Vitruvius Updated: 2026-02-06

Assess

ATT&CK This pattern addresses 359 techniques across 13 tactics View on ATT&CK Matrix →

Click any control badge to view its details. Download SVG

Key Control Areas

Transport Encryption and Cryptographic Standards

SC-09 SC-13

Transmission confidentiality (SC-09) is the core control -- all email leaving the organisation should be encrypted in transit wherever possible. Use of cryptography (SC-13) governs which TLS versions and cipher suites are acceptable. Disable TLS 1.0 and 1.1; mandate TLS 1.2 as minimum with TLS 1.3 preferred. Configure strong cipher suites that provide forward secrecy (ECDHE). Ensure that the MTA's TLS implementation uses validated cryptographic libraries. For enforced TLS connections, require certificates from trusted CAs and verify the partner's certificate against their domain. For opportunistic TLS, accept self-signed certificates to maximise coverage but log and monitor the actual encryption state of all connections.

MTA Authentication and Boundary Protection

IA-03 SC-07

Device identification and authentication (IA-03) applies to the MTAs themselves -- in enforced TLS mode, both the sending and receiving MTA must present valid certificates to establish the encrypted channel. Certificate validation ensures you are communicating with the intended partner MTA, not a man-in-the-middle. Boundary protection (SC-07) governs the placement and configuration of mail gateways at the network perimeter. The mail gateway is a critical boundary device that mediates all inbound and outbound email; its TLS configuration directly determines the organisation's email transport security posture. Restrict SMTP relay access, implement connection-level controls, and ensure the mail gateway is hardened and regularly patched.

Information Flow and Access Control

AC-03 AC-04

Access enforcement (AC-03) controls who can configure TLS policies on the mail gateway -- this is a privileged operation that should be restricted to a small group of administrators with change control oversight. Information flow enforcement (AC-04) determines which email flows require enforced TLS versus opportunistic TLS. Policy should be risk-based: email to financial regulators, legal counsel, or partners exchanging sensitive data should use enforced TLS, while general business correspondence may use opportunistic TLS. Implement policy rules on the mail gateway that match destination domains to TLS enforcement levels.

Monitoring and Reporting

AU-06

Audit monitoring, analysis, and reporting (AU-06) is essential for operational effectiveness. Monitor all outbound email connections for TLS status: was TLS negotiated, which version and cipher suite was used, did certificate validation succeed. Alert on enforced TLS connection failures immediately -- these represent blocked email to business partners. For opportunistic TLS, track the percentage of connections that successfully negotiate encryption versus falling back to clear text. Generate periodic reports showing encryption coverage by partner domain. Use SMTP TLS Reporting (RFC 8460) where supported to receive failure reports from receiving domains. Feed monitoring data back into policy decisions about where to enable or mandate enforced TLS.

Documentation and Operational Procedures

SA-05

Information system documentation (SA-05) covers the operational procedures that make email TLS sustainable. Document all enforced TLS connections including partner domain, certificate details, renewal dates, and escalation contacts. Maintain runbooks for common failure scenarios: certificate expiry at partner, TLS negotiation failure, temporary enforcement relaxation and re-enablement. Document the decision criteria for when to enable enforced TLS for a new partner. Keep an inventory of all partner MTA certificates and their expiry dates, with automated alerting before expiry. For organisations using email outsourcers, document the TLS configuration between the outsourcer and the internal mail infrastructure.

When to Use

Apply this pattern as a baseline for all organisations that send and receive email over the internet. It is a transparent solution that requires no end-user interaction and provides immediate confidentiality improvement for email in transit. It is particularly important for organisations with many business partners exchanging sensitive information (financial services, healthcare, legal, government), where regulatory requirements may mandate encryption of data in transit. Use enforced TLS selectively for high-sensitivity partner connections where both parties can commit to maintaining TLS capability. Combine with SPF, DKIM, and DMARC for a comprehensive email security posture.

When NOT to Use

This pattern is insufficient when email communication must be protected end-to-end from the sender's workstation to the recipient's workstation -- for example, when email content must remain confidential even from the organisation's own mail administrators or email outsourcer. In such cases, use S/MIME or PGP-based message-level encryption. This pattern also does not protect email stored at rest on mail servers or in mailboxes. It is not a substitute for email content filtering, anti-malware scanning, or sender authentication (SPF/DKIM/DMARC), which address different threat categories.

Typical Challenges

Not every business partner's mail gateway supports TLS, and among those that do, many are misconfigured -- expired certificates, self-signed certificates, wrong hostnames, or outdated TLS versions. Enforced TLS connections require bilateral agreement and testing with each partner, which does not scale well when an organisation has hundreds of business partner domains. Email outsourcers add complexity: the TLS connection terminates at the outsourcer's MTA, meaning the outsourcer can read decrypted email content. Establishing enforced TLS through an outsourcer requires that the outsourcer's infrastructure meets the same requirements, which may not be configurable on a per-tenant basis. Not all MTAs support the additional requirements that outsourcers impose for enforced TLS establishment. Certificate lifecycle management across many partner connections is operationally demanding. Downgrade attacks against opportunistic TLS (stripping the STARTTLS advertisement) remain a risk without MTA-STS or DANE deployment.

Threat Resistance

This pattern protects against eavesdropping on email in transit over the internet, preventing passive network observers from reading confidential business communications. Enforced TLS additionally resists active man-in-the-middle attacks by requiring certificate validation. A number of residual risks remain: confidentiality is not guaranteed within the company's intranet after the message arrives at the gateway. If a third-party outsourcer provides MTA functionality, they can read decrypted email unless a separate TLS connection protects the outsourcer-to-internal-server hop. Availability risk exists for enforced TLS connections -- email is blocked if encryption fails, requiring continuous monitoring and rapid response. Opportunistic TLS does not guarantee encryption and is vulnerable to downgrade attacks where an attacker strips the STARTTLS advertisement. TLS stack vulnerabilities could allow eavesdropping on otherwise encrypted connections. In opportunistic TLS mode, self-signed certificates are accepted, meaning MTA identity is not verified.

Assumptions

Protection of email communication at the infrastructure level (gateway-to-gateway) provides sufficient protection for most business email. No end-to-end encryption is required for the general case, though it may be required for specific high-sensitivity communications. The organisation operates or contracts mail gateway (MTA) infrastructure that supports STARTTLS. Business partners' MTAs support TLS to a sufficient degree for opportunistic encryption to provide meaningful coverage. Certificate infrastructure (internal CA or public CA) is available for MTA certificate management. The organisation has operational capacity to monitor TLS connection status and respond to failures.

Developing Areas

MTA-STS adoption remains stubbornly low despite being standardised since 2018 (RFC 8461). As of 2025, fewer than 5% of domains publish MTA-STS policies, meaning the vast majority of email remains vulnerable to STARTTLS downgrade attacks by active network adversaries. The chicken-and-egg problem persists: senders have little incentive to check for MTA-STS policies when so few receivers publish them, and receivers see limited value in publishing when few senders enforce. Google and Microsoft's adoption has helped, but the long tail of smaller mail operators remains exposed.
DANE/TLSA deployment is technically superior to MTA-STS for preventing man-in-the-middle attacks on SMTP connections, but it requires DNSSEC, which itself has limited deployment. Fewer than 10% of domains are DNSSEC-signed, and many DNS hosting providers and registrars still do not support it natively. The operational complexity of managing DNSSEC key rollovers alongside TLSA certificate records creates a maintenance burden that deters adoption, leaving DANE as a theoretically excellent but practically niche solution.
DMARC enforcement at p=reject is progressing but unevenly. While major email providers now require DMARC for bulk senders, many organisations still run DMARC in monitor-only mode (p=none) for years due to fear of blocking legitimate email from misconfigured third-party senders. The gap between DMARC deployment (growing rapidly) and DMARC enforcement (growing slowly) means that email spoofing protection is weaker in practice than aggregate statistics suggest.
Email authentication for AI-generated content is an emerging concern with no established standards. As AI systems increasingly send email on behalf of organisations -- automated responses, AI-drafted communications, agent-to-agent messaging -- the question of how to authenticate and attribute machine-generated email within existing SPF/DKIM/DMARC frameworks is unresolved. The potential for AI to generate highly convincing phishing emails at scale makes sender authentication more critical than ever, yet the protocols were designed for human-originated messaging patterns.

Related Patterns

Patterns that operate within or alongside this one. Click any to view.

SP-005 SOA Internal Service Usage SP-006 Wireless Private Network SP-007 Wireless Public Hotspot SP-013 Data Security SP-016 DMZ Module SP-019 Secure Ad-Hoc File Exchange

AC: 2AU: 1IA: 1SA: 1SC: 3

AC-03 Access Enforcement

AC-04 Information Flow Enforcement

AU-06 Audit Monitoring, Analysis, And Reporting

IA-03 Device Identification And Authentication

SA-05 Information System Documentation

SC-07 Boundary Protection

SC-09 Transmission Confidentiality

SC-13 Use Of Cryptography