DMARCGuardian Practical help for DMARC, SPF, DKIM, and BIMI.

Blog · Deliverability

What TLS Version Do Mail Servers Need in 2026? A Practical Guide

By DMARCGuardian Editorial Team ·

What TLS version do mail servers need in 2026?

Short answer: TLS 1.2 or higher. TLS 1.0 and TLS 1.1 are deprecated and increasingly blocked by major receivers.

The longer answer involves understanding what the standards require, what major mail providers actually enforce, and what to do about legacy systems that still run older TLS versions.

This guide covers all three.

What the standards say: RFC 8314

RFC 8314, published in 2018, is the key standard for email TLS usage. Its core recommendation is blunt:

  • TLS 1.2 or greater is required for mail submission and access
  • TLS 1.0 and 1.1 are explicitly deprecated
  • Implicit TLS (connecting on a dedicated port with encryption from the start) is preferred over STARTTLS (upgrading an unencrypted connection)

The distinction between implicit TLS and STARTTLS matters for configuration. Implicit TLS runs on port 465 (SMTP submission), port 993 (IMAP), and port 995 (POP3). STARTTLS upgrades a plaintext connection on port 587 (SMTP submission) or port 143 (IMAP). Both are valid, but implicit TLS is considered more secure because there is no window where the connection is unencrypted.

For a mail server in 2026, supporting TLS 1.2 or higher on both implicit TLS and STARTTLS ports is the baseline expectation.

What major providers require

Gmail, Yahoo, and Microsoft 365 all require TLS 1.2 for inbound mail. If your mail server only offers TLS 1.0 or 1.1, messages to these providers may be rejected or delivered with warnings.

Gmail: Requires TLS 1.2 for SMTP submission and will refuse connections from servers that only offer TLS 1.0 or 1.1.

Yahoo: Enforces TLS 1.2 for mail delivery.

Microsoft 365: Requires TLS 1.2 for SMTP AUTH. If you are sending mail through Microsoft 365 or receiving via Exchange Online, your sending server needs TLS 1.2 minimum.

These are not future plans. They are current requirements. TLS 1.0 and 1.1 have known vulnerabilities including BEAST, POODLE, and FREAK. Major receivers treat them as acceptable risk vectors and block them accordingly.

Why TLS 1.0 and 1.1 are a problem

TLS 1.0 (1999) and TLS 1.1 (2006) have well-documented security weaknesses:

  • BEAST attack: Allows attackers to decrypt encrypted cookies and credentials in TLS 1.0 connections
  • POODLE attack: Lets attackers recover plaintext from TLS 1.0 CBC mode cipher suites
  • FREAK attack: Exploits export-grade cipher suites still present in older TLS implementations
  • Weak hash algorithms: Both versions rely on MD5 and SHA-1 in ways that are no longer considered safe

Beyond the security risks, TLS 1.0 and 1.1 do not support modern cipher suites. A mail server stuck on TLS 1.0 can only negotiate weak ciphers that receivers rightfully distrust.

How to check what TLS version your mail server offers

The quickest check is using a TLS testing service or running a manual test.

Using OpenSSL to test your server:

echo | openssl s_client -connect mail.example.com:465 -tls1
echo | openssl s_client -connect mail.example.com:465 -tls1_1
echo | openssl s_client -connect mail.example.com:465 -tls1_2

If TLS 1.0 or 1.1 connect successfully, your server still supports them. A failed connection means that version is not available.

Online tools: services like checktls.com, ssllabs.com, and mxtoolbox.com can scan your mail server and report which TLS versions it accepts. MXToolbox has a specific TLS check feature for mail servers.

What to look for: Your server should successfully negotiate TLS 1.2 or TLS 1.3 on ports 465, 587, 993, and 995. Connection attempts for TLS 1.0 and 1.1 should fail or be refused.

If you are checking an outbound mail server, send a test message to a Gmail or Yahoo address and look at the message headers. If TLS was used, you will see something like:

Received: from mail.example.com (mail.example.com [203.0.113.1])
        by mx.gmail.com with ESMTPS id abc123
        for <user@gmail.com>
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 ...)

If you see TLS1_2 or TLS1_3 in the headers, that particular delivery used modern TLS.

How to disable TLS 1.0 and 1.1

The exact steps depend on your mail server software.

Postfix

In main.cf:

smtpd_tls_protocols = TLSv1.2 TLSv1.3
smtp_tls_protocols = TLSv1.2 TLSv1.3
smtpd_tls_ciphers = medium
smtp_tls_ciphers = medium

This disables TLS 1.0 and 1.1 for both inbound (smtpd) and outbound (smtp) connections. After making changes, run postfix reload.

Microsoft Exchange Server

In Exchange Management Shell:

Set-TransportService -Identity EXCHSRV01 -TlsProtocolLibDisableList "TLS 1.0","TLS 1.1"

Or disable via registry on each Exchange server:

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1

Set Enabled to 0 and DisabledByDefault to 1 for both server and client entries. Restart the server after making registry changes.

Microsoft 365 / Exchange Online

If you are sending through Microsoft 365, there is nothing to configure on your side for TLS version support. Microsoft 365 handles TLS 1.2 enforcement on the receiving end. However, if you have a hybrid setup with an Exchange hybrid server, make sure the hybrid server also disables TLS 1.0/1.1.

Dovecot (IMAP/POP)

In /etc/dovecot/dovecot.conf:

ssl_protocols = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1 TLSv1.2 TLSv1.3

After reloading Dovecot, test that TLS 1.0 and 1.1 connections are refused.

DMARCFlow and TLS monitoring

Standard DMARC monitoring focuses on SPF, DKIM, and DMARC alignment. These checks verify that the sending server is authorized and that the From header matches the domain. But DMARC pass does not mean the connection was encrypted, and a mail server that passes all three authentication checks may still be running TLS 1.0 with known vulnerabilities.

DMARCFlow goes beyond authentication records and includes TLS configuration checks as part of its email security health monitoring. When you add a domain to DMARCFlow, it monitors whether your sending and receiving infrastructure supports modern TLS versions alongside your DMARC data. This matters because a single misconfigured mail relay or a vendor that has not updated their TLS configuration can expose your domain to attacks that DMARC alone cannot prevent.

For example, if a third-party marketing platform you send through still offers TLS 1.0, your DMARC reports will show their server as a valid sender (because SPF or DKIM passes) even as that connection is vulnerable to eavesdropping. DMARCFlow surfaces these TLS gaps alongside your authentication data so you can see the full picture of your email security posture.

This is not about replacing TLS configuration with DMARC monitoring. It is about making sure both layers are in place and working.

FAQ

Is TLS 1.2 still acceptable or does TLS 1.3 replace it?

TLS 1.2 is still fully acceptable and widely supported. TLS 1.3 is newer (2020) and preferred where available, but TLS 1.2 remains the minimum baseline. Many mail servers and security appliances still only support TLS 1.2. There is no need to rush to deprecate TLS 1.2.

Does disabling TLS 1.0 and 1.1 break email delivery?

If you are sending to systems that only support TLS 1.0 or 1.1, those deliveries will fail after you disable older TLS versions. This is the intended effect. Those systems should be upgraded. In practice, all major mail providers (Gmail, Yahoo, Microsoft 365, Apple Mail, etc.) support TLS 1.2. Legitimate mail will not be affected by disabling TLS 1.0/1.1.

What about STARTTLS on port 587?

The same TLS version requirements apply. Port 587 uses STARTTLS to upgrade from plaintext to encrypted. The underlying TLS protocols are the same as implicit TLS on port 465. Disable TLS 1.0/1.1 on your submission port as well.

Does DMARC require TLS?

No. DMARC is an authentication layer that checks SPF and DKIM alignment. It does not itself require encryption. However, sending email over unencrypted connections is a serious security risk regardless of DMARC status, and major receivers increasingly deprioritize or block unencrypted mail.

What cipher suites should I use with TLS 1.2?

Use AEAD cipher suites: AES-128-GCM, AES-256-GCM, or ChaCha20-Poly1305. These are the only cipher suites that TLS 1.3 allows, and they are the safest option for TLS 1.2 as well. Avoid RC4, 3DES, and any cipher suite using MD5 or SHA-1 for hashing.