TLS for Mail: M3AAWG Baseline Recommendations (April 2026)

If you run mail servers, a short list of measures protects your mail from eavesdropping, and you can put them in place relatively quickly. They are the base that MTA-STS, DANE for SMTP and TLS-RPT build on.

The measures come from TLS for Mail: M3AAWG Baseline Recommendations by the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG), updated in April 2026 (first published in 2014; M3AAWG-155; reference URL m3aawg.org/TLSBaselineRecs2026). The document is deliberately brief and covers the "low-hanging fruit": three measures, plus a fourth on logging, that messaging providers can deploy against eavesdropping. It was motivated by the disclosures about global surveillance in the 2010s and by the ongoing pervasive monitoring of email traffic. It covers only measures that providers can deploy, not encryption by end users such as PGP, GPG or S/MIME.

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

• Versions: use only TLS 1.2 and TLS 1.3. In line with IETF RFC 8996, disable SSLv3, TLS 1.0 and TLS 1.1 because of their known security issues. The document says it again elsewhere: versions "such as 0.9, 1.0, or 1.1" are obsolete and do not adequately protect data in transit, and M3AAWG "specifically urges" supporting TLS 1.2–1.3 and nothing else.
• Mail sent between MTAs without encryption is exposed both to unauthorized monitoring and to man-in-the-middle (MiTM) attacks. Mandatory TLS based on a publicly trusted certificate prevents both. However, TLS is not adopted everywhere, so forcing TLS is not feasible for general traffic. The answer is opportunistic TLS, with keys created for each session, which protects traffic on a best-effort basis (and can still be attacked by a man in the middle).
• Many MTAs now support DANE and MTA-STS, which strengthen TLS session encryption further by protecting against downgrade and MiTM attacks. Consult your MTA's documentation to set up STARTTLS with recent versions and ciphers, and to disable obsolete ones properly.
• "M3AAWG strongly encourages all operators to enable Opportunistic TLS on all mail servers."
• Limitation: SMTP works hop by hop, and TLS works for each TCP connection, so opportunistic TLS protects each hop separately. If some hops in the delivery path use TLS and others do not, the protection is incomplete to the same extent. It is imperfect, but it protects at least some traffic from some passive attacks.
• Verification: check what your servers offer with a testing tool for TLS over SMTP. The document names the 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 old assumption that internal traffic over dedicated links is secure "is no longer warranted", given how much pervasive network monitoring has been disclosed (the document cites MUSCULAR (DS-200B) and Carnivore in its footnotes). Encrypt all traffic within your own network infrastructure, with TLS or other cryptographic methods, in the same way that opportunistic TLS is applied to mail between MTAs over the internet.

3) Encrypt user credentials and access

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

4) Log TLS version and cipher data

Both senders and receivers should log the TLS version and cipher of each TLS session, and may log data about failed connections, which "could be useful with TLSRPT reports" (see TLS-RPT). Detailed data helps with diagnosis in the short term, and aggregated data shows trends.

Caveats and scope

• These are "fundamental steps rather than comprehensive encryption guidance". Other M3AAWG documents cover more advanced topics. Review your policies periodically.
• Before you change existing configurations, understand how the changes affect users, especially those with older client software. Real data about your users should inform deployment decisions.

RFCs cited