TLS hardening on Exchange Server: TLS 1.2, TLS 1.3 and ciphers without breaking mail flow

Switching off old TLS versions on Exchange is mostly registry work, but the order matters: change one side only, or disable TLS 1.0 before you know who still uses it, and partner mail, scanners or older clients stop connecting. Here I'll cover what Exchange Server SE and 2019 support, including TLS 1.3, the Schannel and .NET settings Microsoft documents, and how to prove the result with Health Checker and the SMTP logs.

How it works: what each version supports#

Exchange is both a TLS server and a TLS client (it connects to other mail servers, Exchange Online and other Exchange servers), so Schannel needs matching Client and Server keys for each protocol under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols. Microsoft documents this support position:

Exchange Server SE continues the Exchange 2019 CU15 code base, so the same TLS 1.3 rule applies to it.

The other half is .NET Framework. Exchange's .NET code follows Schannel only when SystemDefaultTlsVersions is 1, and SchUseStrongCrypto (outgoing connections only) blocks weak protocols. Exchange 2019 CU14 and later set both on new installations; upgraded servers may lack them.

Step-by-step#

1. Take a baseline with Health Checker#

Run the Exchange Health Checker on every server and keep the report. Its TLS check reads the client and server values for TLS 1.0 to 1.3, warns while TLS 1.0 or 1.1 is enabled, flags client/server mismatches and reports both .NET values. For its TLS 1.3 result, see the note in step 5.

2. Find out who still uses TLS 1.0 or 1.1#

Microsoft's pre-checks cover domain controllers, load balancers, clients, multi-function printers, partners and third-party applications. For SMTP, the protocol logs record each session's negotiated version: SP_PROT_TLS1_0_SERVER, SP_PROT_TLS1_1_SERVER or SP_PROT_TLS1_2_SERVER when Exchange receives, and the matching client value when it sends. With protocol logging enabled on your connectors, this groups the remote hosts that negotiated TLS 1.0 or 1.1 with the Front End Transport service:

$log = (Get-TransportService $env:COMPUTERNAME).ReceiveProtocolLogPath.PathName.Replace('Hub','FrontEnd')
Select-String -Path "$log\*.log" -Pattern 'TLS1_[01]' |
    ForEach-Object { ($_.Line -split ',')[5] -replace ':\d+$' } |
    Group-Object -NoElement | Sort-Object Count -Descending

Repeat against SendProtocolLogPath for outbound sessions. For HTTPS, use IIS custom logging fields or load balancer logs; POP and IMAP don't log the TLS version, so they need a network trace.

3. Make .NET inherit the Schannel settings#

foreach ($key in 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319',
                 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319') {
    Set-ItemProperty -Path $key -Name SystemDefaultTlsVersions -Value 1 -Type DWord
    Set-ItemProperty -Path $key -Name SchUseStrongCrypto -Value 1 -Type DWord
}

Exchange doesn't need the same values under the .NET 2.0 keys (v2.0.50727), but Microsoft recommends setting them identically for consistency.

4. Enable TLS 1.2, then disable TLS 1.0 and 1.1#

$base  = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'
$state = @{ 'TLS 1.0' = 0; 'TLS 1.1' = 0; 'TLS 1.2' = 1 }
foreach ($proto in $state.Keys) {
    New-Item -Path $base -Name $proto -ErrorAction SilentlyContinue | Out-Null
    foreach ($side in 'Client', 'Server') {
        New-Item -Path "$base\$proto" -Name $side -ErrorAction SilentlyContinue | Out-Null
        Set-ItemProperty -Path "$base\$proto\$side" -Name Enabled -Value $state[$proto] -Type DWord
        Set-ItemProperty -Path "$base\$proto\$side" -Name DisabledByDefault -Value (1 - $state[$proto]) -Type DWord
    }
}

It takes effect after a restart. Apply it to every Exchange server, Edge Transport included, one server at a time; for DAG members, use maintenance mode around the reboot.

5. TLS 1.3: leave it on where it's supported#

On Exchange 2019 CU15 or later and Exchange SE on Windows Server 2022 or 2025, TLS 1.3 is already enabled for HTTPS. Keep TLS 1.2 enabled alongside it for SMTP. If a hardening baseline switched TLS 1.3 off, Microsoft's page lists the TLS 1.3 Client and Server keys to restore, plus the TLS 1.3 cipher suites:

Enable-TlsCipherSuite -Name TLS_AES_256_GCM_SHA384 -Position 0
Enable-TlsCipherSuite -Name TLS_AES_128_GCM_SHA256 -Position 1

6. Cipher suites, hashes and curves#

Exchange 2019 and SE ship with a preconfigured cipher and hashing setup; Microsoft's cipher steps bring Exchange 2016 to the same set. Apply them as a separate change after TLS 1.0 and 1.1 are off, so you know which step upset a client. On Windows Server 2016, the recommended TLS 1.2 order is:

1. TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
2. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
3. The CBC equivalents: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

The page also disables the RC4, DES, Triple DES, RC2 and NULL ciphers and the MD5 hash, prefers the NistP384 and NistP256 curves, and disables curve25519 (not available in FIPS mode). On Exchange 2016, also set AllowInsecureRenegoClients and AllowInsecureRenegoServers to 0 (renegotiation strict mode, on by default in Exchange 2019).

Verify#

• Health Checker shows no TLS warnings: TLS 1.0 and 1.1 off on both sides, no mismatch, and both .NET values set to 1. For a TLS 1.3 error, see step 5.
• Get-TlsCipherSuite | Format-Table Name lists only the suites you expect.
• For OWA, the Security panel in Microsoft Edge Developer Tools shows TLS 1.2, or TLS 1.3 on Windows Server 2022/2025.
• Received headers show what each hop negotiated, for example (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384), except for authenticated client submission, where Microsoft notes the shown version isn't the client's.
• The step 2 search finds no new TLS 1.0 or 1.1 sessions, and test mail to Exchange Online, partners and scan-to-email devices goes through.

Tips & gotchas#

• Partners still on TLS 1.0. Once you disable it, their TLS handshake with you fails. Where TLS is required (RequireTLS on a connector, or a partner that enforces it), mail queues; where it's opportunistic, the sending server decides whether to retry without encryption. Contact them with the evidence from step 2 first.
• Load balancers that bridge SSL negotiate TLS separately with clients and with Exchange; both legs need TLS 1.2.
• Hybrid. Wrong TLS settings cause problems with Microsoft 365, so test the connectors afterwards; see Exchange hybrid mail flow: connectors and TLS.
• Unsupported combinations: don't enable TLS 1.3 on Windows Server 2019, on Exchange 2016, or on Exchange 2019 builds before CU15.

References#

• Exchange Server TLS configuration best practices (Microsoft Learn)
• Manage Transport Layer Security (TLS) in Windows Server (Microsoft Learn)
• Health Checker: TLS configuration check (CSS-Exchange)