0x80090331 algorithm mismatch: legacy TLS blocks Exchange from Microsoft 365

Fix it now

0x80090331 is Windows reporting that your server and the far end do not possess a common algorithm, so the handshake had nothing to agree on. Against Microsoft 365 that almost always means your side is offering protocol versions and cipher suites the service no longer accepts. Registry work fixes a server that merely has TLS 1.2 switched off; it cannot add capability a build does not have.

Get-ExchangeServer | Format-List Name,Edition,AdminDisplayVersion
New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" -Force | Out-Null
New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" -Name "DisabledByDefault" -Value 0 -Type DWord
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" -Name "Enabled" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" -Name "DisabledByDefault" -Value 0 -Type DWord
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" -Name "Enabled" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SystemDefaultTlsVersions" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SystemDefaultTlsVersions" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -Type DWord

1. Read the Schannel entries in Windows Logs then System first. Event 36888 means your server generated the alert; 36887 means it received one. The two point at opposite ends.
2. Both .NET paths matter. SchUseStrongCrypto affects only outgoing connections, and SystemDefaultTlsVersions is what lets managed components inherit the operating system’s choice instead of the framework’s.
3. Reboot. Microsoft is explicit that the Exchange TLS configuration becomes active only after the server restarts.
4. If the build is past end of support and the values are already correct, stop configuring. Exchange Server 2016 and 2019 reached end of support on 14 October 2025, and no registry value adds a cipher suite the code does not implement.

These values change how the whole server negotiates encryption, not just Exchange. Export each key first, change one thing at a time, and have console access available before you start.

If the handshake completes after the reboot, you are done. If it still fails, the next section explains how to tell a configuration problem from a capability problem.

Why it happens

A TLS handshake starts with one side offering a list: the protocol versions and cipher suites it is willing to use. The other picks one it also supports and the session proceeds. If the intersection is empty there is nothing to pick and the handshake ends. Windows publishes 0x80090331 as SEC_E_ALGORITHM_MISMATCH, meaning the client and server cannot communicate because they do not possess a common algorithm. It says nothing about certificates or names.

Two Schannel events describe the same handshake from opposite ends, and the direction is the most useful thing you can establish. Event 36888 is logged when this computer detects an error condition and generates a fatal alert to notify the other party: your side rejected what they offered. Event 36887 is logged when this computer receives a fatal alert from the far end: they rejected what you offered. Event 36874 is more specific still, reporting that a connection request arrived and none of the cipher suites the client supports are supported by the server.

If Microsoft 365 sends you the alert, nothing on their side will change. Microsoft has steadily retired older TLS versions and weaker suites across its services, so a server that was fine for years fails without anything on your network changing. That is the moment to establish which problem you have. TLS 1.2 support was introduced with Exchange Server 2013 CU19 and Exchange Server 2016 CU8, and Exchange Server 2019 supports it by default, so anything older than those cumulative updates is a capability problem rather than a configuration one.

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server
  Enabled            REG_DWORD  1
  DisabledByDefault  REG_DWORD  0

HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319
  SystemDefaultTlsVersions  REG_DWORD  1
  SchUseStrongCrypto        REG_DWORD  1

Full reference

Which direction the alert came from

Support state, and what it decides

Applying the registry changes without locking yourself out

1. Export every key you are about to touch, to a file on a share you can reach from elsewhere.
2. Confirm you have console or out-of-band access to the server that does not depend on TLS from your workstation.
3. Make the protocol changes, reboot, and test before touching the .NET values.
4. Make the .NET changes, reboot again, and test the specific managed component that was failing.
5. Only then retire older protocol versions, one at a time, testing between each.

Inventory what submits mail to the server before you disable an old protocol. Scanners, copiers and line-of-business applications are the devices that discover a protocol retirement by outage, and they are never the ones anyone remembers.

When the far end is Microsoft 365

• You will see event 36887 rather than 36888, because they are the ones rejecting.
• There is no configuration on their side to change and no exception to request.
• The minimum they accept has moved before and will move again, so a server that is only just current today is a problem you have deferred rather than solved.
• Routing affected outbound mail through a modern host is a legitimate interim measure, not a fix.
• Check the hybrid connectivity components separately from mail flow. They are managed code and they read the .NET values, not just the Schannel ones.

Every code this article covers

Confirm the fix worked

1. The registry values read back correctly under both the Client and Server subkeys, and in both .NET framework paths.
2. The server has been rebooted since the change, because the configuration is not active until it has.
3. No new fatal alert events appear in the system log for the partner that was failing.
4. A test message through the connector that was failing is delivered.
5. Internal submission from devices and applications still works after any protocol you retired.

Questions people ask about this