Exchange Online POP and IMAP: TLS 1.0 and 1.1 refused, imap-legacy.office365.com gone

php_network_getaddresses: getaddrinfo for imap-legacy.office365.com failed: No such host is known.
# or, with TLS 1.0 or 1.1 to outlook.office365.com:993 or :995
error:0A00042E:SSL routines::tlsv1 alert protocol version

Short answer: Exchange Online now refuses POP3 and IMAP4 over TLS 1.0 and 1.1, and the opt-in legacy hosts for old clients are gone. Microsoft's rollout runs from 1 August to 31 December 2026. On 2 November outlook.office365.com already refused both versions, and pop-legacy.office365.com and imap-legacy.office365.com no longer resolved. Point the client at outlook.office365.com and make it use TLS 1.2 or 1.3: update the device, or fix the setting in .NET, PHP, Java or Python.

Checked on 2 November 2026 against Microsoft MC1293480 and our own connection tests.

Why it happens

Microsoft's Learn page on legacy TLS clients (updated 14 November 2025) says Exchange Online stopped supporting TLS 1.0 and 1.1 in October 2020, planned to switch them off on the main POP3/IMAP4 host, outlook.office365.com, in 2022, and created two opt-in hosts for clients that couldn't move: pop-legacy.office365.com and imap-legacy.office365.com, turned on per tenant with Set-TransportConfig -AllowLegacyTLSClients $true. On 27 April 2026 the Exchange Team announced it is removing that option entirely, and expects only tenants that opted in to be affected. Message center post MC1293480 (updated 7 July 2026) gives the rollout: 1 August to 31 December 2026, worldwide. How we verified it (a dated vendor change, plus our own tests on 2 November 2026 at 10:45 UTC): openssl s_client to outlook.office365.com got TLS alert 70 (protocol version) for TLS 1.0 and 1.1 on ports 993 and 995, and on 143 and 110 after STARTTLS, and connected with TLS 1.2 and 1.3. Google's and Cloudflare's DNS returned no address for either legacy host. Python 3.11, PHP 8.2.12 and Java 18, forced to TLS 1.0 or 1.1, printed the errors on this page; on TLS 1.2 or their defaults they got the server's greeting. The .NET registry values and the Java mail properties come from the vendors' documentation; we didn't change a test machine's registry.

You may also see

ssl.SSLError: [SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:992)

javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version

socket.gaierror: [Errno 11001] getaddrinfo failed

System.Net.Sockets.SocketException: No such host is known

Fix

Find out if you're affected. In Exchange Online PowerShell, run Get-TransportConfig | Format-List AllowLegacyTLSClients. True means your tenant opted in to the legacy hosts, so some device or app used them. Then search device settings, app config files and scripts for pop-legacy.office365.com and imap-legacy.office365.com: each one has stopped working.
Change the server name to outlook.office365.com: IMAP on port 993 with SSL/TLS (or 143 with STARTTLS), POP on port 995 with SSL/TLS (or 110 with STARTTLS). In our test all four refused TLS 1.0 and 1.1 and accepted 1.2 and 1.3, so the client must also speak TLS 1.2 (the next steps).
Test from the machine that runs the client. With OpenSSL:
```
openssl s_client -connect outlook.office365.com:993 -tls1_2
# working: New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
```
On Windows, this PowerShell shows what .NET on that machine negotiates by default (it printed Tls13 on Windows 11 in our test):
```
$c = New-Object System.Net.Sockets.TcpClient('outlook.office365.com', 993)
$s = New-Object System.Net.Security.SslStream($c.GetStream())
$s.AuthenticateAsClient('outlook.office365.com'); "Negotiated: $($s.SslProtocol)"; $c.Close()
```
If the test works but the app still fails, the app pins an old TLS version or runs an old runtime: fix it below. If the test fails too, check the network path (a proxy or firewall that inspects TLS) before changing the app.
.NET Framework apps (helpdesk tools, ERP or CRM mail import, Windows services): Microsoft's guidance is to target .NET Framework 4.7 or later and not set a TLS version in code. Remove SslProtocols.Default, SslProtocols.Tls or SecurityProtocolType.Tls; if a value must be passed, use SslProtocols.None for SslStream or SecurityProtocolType.SystemDefault for ServicePointManager, which let Windows choose. For an app you can't rebuild, set these values (from Microsoft's page; they affect every .NET app on the machine), then restart the app:
```
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
```
PHP: if the code opens tlsv1.0:// or tlsv1.1://, or sets crypto_method to STREAM_CRYPTO_METHOD_TLSv1_0_CLIENT, change it to ssl:// or tls:// (both negotiated TLS 1.3 with outlook.office365.com in our test on PHP 8.2.12) or tlsv1.2://. A PHP build on an OpenSSL too old for TLS 1.2 needs a PHP upgrade.
Java: if the code calls setEnabledProtocols with TLSv1, or sets mail.imaps.ssl.protocols or mail.pop3s.ssl.protocols (Jakarta Mail) to TLSv1, set it to TLSv1.2 TLSv1.3 or remove it. With no setting, Java 18 negotiated TLS 1.3 in our test; a runtime that can't do TLS 1.2 needs an update.

Python: replace ssl.PROTOCOL_TLSv1 or a context limited to TLS 1.0/1.1 with ssl.create_default_context() (it negotiated TLS 1.3 with Python 3.11 in our test):

import imaplib, poplib, ssl
imap = imaplib.IMAP4_SSL("outlook.office365.com", 993, ssl_context=ssl.create_default_context())
pop = poplib.POP3_SSL("outlook.office365.com", 995, context=ssl.create_default_context())

Devices (scanners, copiers, phone systems and appliances that fetch mail by POP or IMAP): look for a firmware update with TLS 1.2 and set the server to outlook.office365.com. A device with no TLS 1.2 firmware can't be fixed by settings; replace it or move its job to something that can.
When nothing uses the legacy hosts any more, turn the old opt-in off: Set-TransportConfig -AllowLegacyTLSClients $false.

A scanner, helpdesk tool or app still can't fetch mail? Tell me the device or app and the error. I work out what it runs (firmware, .NET, PHP, Java or Python version), tell you exactly what to change or update (server name, port, TLS setting), check the Microsoft 365 side with you and stay with you until it connects.

Get it working on Fiverr (from $25)

Message me on Fiverr with the device or app name and the error first; I confirm it can be fixed before you order. No passwords or remote access needed.

Who does the work: me, Ashish, the owner of this site, based in India. My public code and tools are on GitHub: github.com/Donrulezz.

Watch out

Turning AllowLegacyTLSClients on doesn't help any more: on 2 November 2026 both legacy hosts had no DNS address. Microsoft's rollout window runs to 31 December, so don't count on any region still allowing TLS 1.0 or 1.1.
Only POP3 and IMAP4 are covered here; both stay available. Sending mail from the same device or app is a separate change: see Microsoft 365 SMTP AUTH and Basic auth on mailpassed.com.
The .NET registry values change every .NET Framework app on that machine. Microsoft recommends them, but test a line-of-business app after setting them.
Government clouds (GCC, GCC High, DoD) never had the opt-in hosts, per Microsoft's Learn page, so tenants there are affected only if a client still asks for TLS 1.0 or 1.1.

Sources

Did this fix it?

Other errors breaking soon

All "breaking soon" fixes