TLS for Mail: M3AAWG Baseline Recommendations (April 2026)

Source: TLS for Mail: M3AAWG Baseline Recommendations, updated April 2026 (originally published 2014; M3AAWG-155; reference URL m3aawg.org/TLSBaselineRecs2026). A deliberately brief "low-hanging fruit" document: three-plus-one measures messaging providers can deploy relatively quickly against eavesdropping, motivated by the 2010s global surveillance disclosures and ongoing pervasive monitoring of email traffic. It covers provider-deployable measures only — not end-user encryption such as PGP/GPG or S/MIME.

This is the baseline that MTA-STS, DANE for SMTP, and TLS-RPT build on.

1) Opportunistic TLS between providers, TLS 1.2/1.3 only

• Versions: use only TLS 1.2 and TLS 1.3. Consistent with IETF RFC 8996, disable SSLv3, TLS 1.0, and TLS 1.1 due to known security issues. Elsewhere the document repeats: versions "such as 0.9, 1.0, or 1.1" are obsolete and do not adequately protect data in transit; M3AAWG "specifically urges" supporting only TLS 1.2–1.3.
• Unencrypted MTA-to-MTA flows are subject to both unauthorized monitoring and man-in-the-middle (MiTM) attacks; both are prevented by mandatory TLS based on a publicly trusted certificate — but without universal TLS adoption, forced TLS is infeasible for general traffic. Hence: opportunistic TLS with ad-hoc session-based keys, protecting flows on a best-effort basis (still MiTM-susceptible).
• Many MTAs now support DANE and MTA-STS, which further strengthen TLS session encryption by protecting against downgrade and MiTM attacks — consult MTA documentation for setting up STARTTLS with recent versions/ciphers and properly disabling obsolete ones.
• "M3AAWG strongly encourages all operators to enable Opportunistic TLS on all mail servers."
• Limitation: SMTP is hop-by-hop, and TLS works per TCP connection, so opportunistic TLS protects hop-by-hop only — if some hops in the delivery path deploy TLS and others don't, protection is correspondingly incomplete. Imperfect, but it protects at least some traffic from some passive attacks.
• Verification: review what your servers offer with a "TLS for SMTP" testing tool — the document names LuxSci SMTP TLS Checker (luxsci.com/smtp-tls-checker) and CheckTLS (checktls.com/TestReceiver), both free for non-commercial use.

2) Encrypt intracompany network traffic

The historical assumption that internal traffic over dedicated links is secure "is no longer warranted" given the disclosed scale of pervasive network monitoring (the document footnotes MUSCULAR (DS-200B) and Carnivore). Encrypt all traffic within your own network infrastructure, with TLS or alternative cryptographic methods — the same way opportunistic TLS is applied to internet-facing MTA-to-MTA flows.

3) Encrypt user credentials and access

When users authenticate to read mail or submit messages, encrypt the credential exchange:

Access	Ports
IMAP with TLS / POP with TLS	993 / 995
IMAP/POP with STARTTLS	143 / 110
Mail submission with TLS	465
Mail submission with STARTTLS	587
Webmail	HTTPS

4) Log TLS version and cipher data

Both senders and receivers should log the TLS version and cipher of each connected TLS session, and may log failed-connection data — which "could be useful with TLSRPT reports" (see TLS-RPT). Detailed data serves short-term diagnosis; aggregate data displays trends.

Caveats and scope

• These are "fundamental steps rather than comprehensive encryption guidance"; more advanced topics live in other M3AAWG documents. Review policies periodically.
• Before changing existing configurations, know how changes affect users — especially those with older client software; real-world user data should influence deployment decisions.

RFCs cited

RFC	Subject
RFC 5246	TLS 1.2
RFC 7258	Pervasive Monitoring Is an Attack
RFC 7672	SMTP security via opportunistic DANE TLS
RFC 8446	TLS 1.3
RFC 8460	SMTP TLS Reporting
RFC 8461	SMTP MTA Strict Transport Security (MTA-STS)
RFC 8996	Deprecating TLS 1.0 and TLS 1.1