M3AAWG, the Messaging, Malware and Mobile Anti-Abuse Working Group, published an April 2026 update to its “TLS for Mail” baseline recommendations on its website, urging messaging providers to use modern TLS protections to reduce eavesdropping risks across email transport, internal infrastructure and user authentication.
The updated document, “TLS for Mail: M3AAWG Baseline Recommendations,” revisits guidance originally published in 2014 and keeps the focus deliberately practical: steps that providers can implement relatively quickly to improve baseline privacy and security for email users. M3AAWG says public concern over pervasive monitoring of email traffic remains a driver for wider deployment of encryption controls across the messaging ecosystem.
The most notable technical recommendation is that providers should support only TLS 1.2 and TLS 1.3 for mail transport, and disable older protocols including SSLv3, TLS 1.0 and TLS 1.1. The document aligns this with IETF guidance in RFC 8996, which deprecated TLS 1.0 and TLS 1.1 because of known security weaknesses.
M3AAWG strongly encourages operators to enable Opportunistic TLS on all mail servers. This remains an important baseline because SMTP traffic is not encrypted by default, leaving mail flows potentially exposed to passive monitoring. However, the document also makes clear that Opportunistic TLS is not a complete solution: SMTP is hop-by-hop, and Opportunistic TLS can still be vulnerable to downgrade or man-in-the-middle attacks unless strengthened with mechanisms such as DANE or MTA-STS.
The update also recommends that providers encrypt internal network traffic, not just public internet-facing MTA-to-MTA connections. M3AAWG argues that the historic assumption that private or dedicated internal links are inherently secure is no longer sufficient in light of large-scale monitoring concerns.
For user access, the guidance calls for encryption around mailbox access and message submission, including IMAP or POP with TLS, mail submission over TLS or STARTTLS, and webmail over HTTPS. In addition, M3AAWG now recommends that senders and receivers log TLS version and cipher data, along with failed connection data where useful, to support diagnostics, TLSRPT reporting and trend analysis.
For email service providers, mailbox providers and large-volume senders, the update is less a radical change than a reminder that encryption hygiene is now part of basic operational maturity. Modern TLS support, certificate handling, MTA configuration, reporting and monitoring all sit alongside authentication and abuse-prevention practices as part of responsible mail operations.
There are operational trade-offs. M3AAWG notes that IT managers should understand how configuration changes may affect users, particularly those with older client software. That caveat matters: disabling legacy TLS may improve security posture, but providers still need to assess real-world client data, support obligations and staged rollout plans before making changes at scale.
The practical takeaway for email professionals is straightforward: Opportunistic TLS should be considered a minimum, not an endpoint. Providers should be reviewing TLS versions, cipher support, STARTTLS behaviour, DANE or MTA-STS readiness, TLSRPT reporting, internal transport encryption and authentication endpoint security as part of their regular deliverability and infrastructure reviews.
M3AAWG describes the document as baseline rather than comprehensive encryption guidance. That framing is important. The updated recommendations do not attempt to cover end-user content encryption such as PGP, GPG or S/MIME, nor do they remove the need for broader security controls. But they do set a clear expectation that modern transport encryption is now fundamental infrastructure for responsible email operations.
