Email Transport Layer Security (TLS) Pattern

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.