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

Blog · Deliverability

What TLS Version Does My Mail Server Need in 2026?

By DMARCGuardian Editorial Team ·

If you are running a mail server in 2026 and wondering which TLS versions are still acceptable, the short answer is: TLS 1.2 minimum, TLS 1.3 preferred, and TLS 1.0 or 1.1 should be disabled now.

The longer answer involves compliance requirements, major provider enforcement, and the fact that if TLS negotiation fails during an SMTP session, messages may still be delivered unencrypted - which means SPF and DKIM checks still run, and DMARC alignment still evaluates, but the transport is in clear text. That gap is where DMARC monitoring tools like DMARCFlow become useful for catching the downstream effects of TLS problems.

This article covers what actually changed, what you need to do about it, and how to verify your configuration.

TLS Version Timeline for Email

Email was originally sent in plain text. SMTP was designed in an era when the idea of encrypting messages in transit was an afterthought.

The progression from bare SMTP to encrypted email went roughly like this:

  • 1999 - TLS 1.0 published. Email servers began supporting STARTTLS, allowing opportunistic encryption on a connection that started plain.
  • 2006 - TLS 1.1 released as a patch for known vulnerabilities in TLS 1.0.
  • 2008 - TLS 1.2 became the recommended version for IETF protocols. It introduced AEAD cipher suites and removed weak algorithms that had been carried forward from earlier versions.
  • 2018 - TLS 1.3 finalized. Simplified handshake, removed insecure features, faster negotiation.
  • 2021 - IETF RFC 8996 formally moved TLS 1.0 and TLS 1.1 to Historic status. They are officially deprecated. RFC 8996 is part of BCP 195, which means following it is considered current industry practice.

That last step is the one that matters most for mail server operators in 2026. RFC 8996 is not a suggestion. It is the basis on which major providers have built their minimum TLS enforcement.

What the Major Providers Actually Require

Google and Microsoft enforce TLS requirements at the service level. If your mail server only speaks TLS 1.0, you will have delivery problems with both ecosystems.

Google Workspace

Google requires TLS 1.2 or higher for inbound and outbound mail. Connections attempted at TLS 1.0 or 1.1 are refused. Google has enforced this for several years.

Microsoft 365 / Exchange Online

Microsoft 365 requires TLS 1.2 minimum for all SMTP connections to Exchange Online. TLS 1.0 and TLS 1.1 are blocked at the service level. If you run a hybrid setup or a mail gateway that talks to Exchange Online, your server must support TLS 1.2.

PCI DSS

If your organization handles cardholder data, PCI DSS 4.0 requires TLS 1.2 minimum for any transmission of cardholder data over public networks. TLS 1.1 is explicitly not allowed.

Enterprise security scans

This is the part that surprises many sysadmins. TLS 1.0 and 1.1 appear as findings in most enterprise vulnerability scanners. Qualys SSL Labs, Tenable, and Rapid7 all flag TLS 1.0/1.1 as medium or high severity findings. Passing a security audit in 2026 often means having TLS 1.0 and 1.1 disabled.

What to Disable on Your Mail Server

If you are running a mail server today, disable the following:

SSL v2 and SSL v3

These versions have been broken for decades. If you find a server still running these, that is a serious finding. Most modern systems have these disabled by default, but confirm.

TLS 1.0

Deprecated. No longer considered secure. Some very old embedded devices may still require it, but for a general-purpose mail server, TLS 1.0 should be disabled. It is a source of compatibility issues, not a source of reliability.

TLS 1.1

Also deprecated per RFC 8996. Same logic as TLS 1.0 - there is no remaining reason to keep it enabled. TLS 1.2 is available everywhere that matters.

Weak cipher suites

TLS 1.2 is acceptable, but only with the right cipher suites. If you see RC4, 3DES, or any cipher using SHA-1 for integrity, those should be removed. Prefer AES-GCM (AES-128 or AES-256) or ChaCha20-Poly1305.

What to Enable and Prefer

TLS 1.2 with AEAD cipher suites

If your server only supports TLS 1.2, make sure it is configured to use AEAD cipher suites. These provide both encryption and authenticated encryption in a single operation, which removes classes of implementation errors that affected older cipher modes.

TLS 1.3

TLS 1.3 is supported by most modern mail servers - Postfix, Exim, Exchange Server 2019 and later, and most hosted email services. It removes the RC4 and 3DES cipher families entirely, eliminates optional compression, and shortens the handshake. It is simpler and faster and more secure.

If your mail server software supports TLS 1.3 and your counterparties support it, prefer it.

Perfect Forward Secrecy

Enable PFS via ECDHE key exchange. This means that if a private key is compromised later, past sessions cannot be decrypted retroactively. Most modern configurations enable this by default, but check.

How to Check Your Mail Server TLS Configuration

Test with openssl

You can test what your mail server offers with a simple command:

openssl s_client -connect yourmailserver.com:25 -starttls smtp

Look for the cipher list and the maximum TLS version in the output.

To specifically test TLS 1.2:

openssl s_client -tls1_2 -connect yourmailserver.com:25 -starttls smtp

To specifically test TLS 1.3:

openssl s_client -tls1_3 -connect yourmailserver.com:25 -starttls smtp

Online tools

SSL Labs Server Test (ssllabs.com/ssltest) covers SMTP servers and will flag TLS 1.0/1.1. CheckTLS.com also tests email-specific TLS configuration.

Check Postfix specifically

postconf smtpd_tls_mandatory_protocols
postconf smtp_tls_mandatory_protocols

These show which TLS versions Postfix requires for inbound and outbound mail. Typical values for a hardened Postfix config:

smtpd_tls_mandatory_protocols = TLSv1.2 TLSv1.3
smtp_tls_mandatory_protocols = TLSv1.2 TLSv1.3

Check Microsoft Exchange

In Exchange Admin Center, navigate to Mail Flow > Receive Connectors. Select the connector and check TLS. The connector-level setting controls what the server accepts. For a modern configuration, require TLS 1.2 or higher.

Check logs

If mail is being rejected with TLS negotiation errors, your mail server logs will show entries like "Unsupported protocol version" or "no shared cipher." Search your mail log (on Postfix: /var/log/mail.log; on Exchange: Application log) for TLS-related rejections.

TLS and DMARC: How They Connect

DMARC does not require TLS. DMARC policy (p=reject, p=quarantine, or p=none) applies at the SPF/DKIM alignment level, not the transport layer.

But there is a practical connection worth knowing. When TLS fails during an SMTP session - because one side only offers TLS 1.0 and the other refuses it, or because cipher suites do not match - the message may still be delivered in clear text depending on how the receiving server is configured. SPF and DKIM checks still run. DMARC alignment still evaluates. The message may pass or fail DMARC based on its authentication results, regardless of whether the transport was encrypted.

This means a TLS misconfiguration does not always cause a DMARC failure. It may simply result in the message being delivered unencrypted. That matters for content confidentiality, but it also means TLS problems can go unnoticed in your DMARC reports - because the message went through, even if it went through in the clear.

Where DMARC monitoring fits: DMARCFlow monitors your aggregate reports for authentication failures. If TLS misconfiguration on your sending side causes alignment issues, those failures will show up in your DMARC aggregate data. More importantly, if you are seeing SPF or DKIM failures in your reports and cannot immediately explain them, TLS negotiation issues on the receiving side may be the cause - and DMARCFlow can help surface that pattern before you spend time chasing SPF/DKIM configuration problems that are actually TLS problems.

DMARC failure reports (RUF) are another consideration. If you are receiving DMARC aggregate and failure reports, those should be delivered over an encrypted channel. Many Report URI services and third-party aggregators require TLS 1.2 for report delivery.

Quick TLS Checklist for Mail Server Administrators

  • [ ] Confirm which TLS versions your mail server currently accepts for SMTP (inbound and outbound)
  • [ ] Disable SSL v2, SSL v3, TLS 1.0, and TLS 1.1
  • [ ] Enable TLS 1.2 with AEAD cipher suites (AES-GCM or ChaCha20-Poly1305)
  • [ ] Enable TLS 1.3 where supported by your mail server software
  • [ ] Enable Perfect Forward Secrecy (ECDHE key exchange)
  • [ ] Test with openssl s_client or SSL Labs Server Test
  • [ ] Check that your mail server logs do not show TLS negotiation failures for your regular sending partners
  • [ ] Verify that Google Workspace and Microsoft 365 requirements are met if you use those platforms
  • [ ] If you receive DMARC failure reports via a third-party service, confirm that service supports TLS 1.2 for report delivery

FAQ

Is TLS 1.0 still acceptable for email servers?

No. TLS 1.0 was formally deprecated by IETF RFC 8996 in March 2021. Most major email providers (Google, Microsoft) block connections at TLS 1.0. Enterprise security scanners flag it as a finding. There is no remaining reason to keep it enabled on a mail server.

What TLS version does Microsoft 365 require?

Microsoft 365 requires TLS 1.2 minimum for all SMTP connections to Exchange Online. TLS 1.0 and TLS 1.1 are blocked at the service level.

What TLS version does Google Workspace require?

Google Workspace requires TLS 1.2 or higher for inbound and outbound mail. Connections at TLS 1.0 or 1.1 are refused.

How do I test if my mail server supports TLS 1.2?

Use the openssl command:

openssl s_client -tls1_2 -connect yourmailserver.com:25 -starttls smtp

If the connection succeeds and shows a certificate, TLS 1.2 is supported. If it fails, TLS 1.2 is either not available or not enabled.

Is TLS 1.3 supported by most mail servers?

TLS 1.3 is supported by Postfix (2.6 and later), Exim, Exchange Server 2019 Cumulative Update 14 and later, and most hosted email services. It is the preferred version where both sides support it.

Summary

TLS 1.0 and 1.1 are deprecated and need to be disabled. TLS 1.2 is the current minimum. TLS 1.3 is preferred and increasingly common. Run an openssl check against your mail server, disable the old versions, enable TLS 1.2 with good cipher suites, and prefer TLS 1.3 where your software supports it. If you use Google Workspace, Microsoft 365, or handle PCI data, TLS 1.2 compliance is not optional - it is enforced at the provider level. And if you are already monitoring your DMARC reports, watch for authentication failures that might trace back to TLS problems on the receiving side rather than SPF/DKIM misconfiguration on yours.