Outlook 0x8004011D: The Connection to Microsoft Exchange Is Unavailable

Fix it now

The HTTPS conversation between Outlook and Exchange is being refused or cut, usually by a network device that closes connections Outlook expects to hold open. The mailbox is normally healthy; what has failed is the path.

Test-NetConnection outlook.office365.com -Port 443
netsh winhttp show proxy
Outlook.exe /safe

1. Try the same machine on a different network. A phone hotspot is ideal. If it connects there, the fault is on the office network path and not on the mailbox.
2. Open the mailbox in a browser through Outlook on the web. If that works, the server side is healthy and the problem is the desktop path.
3. If a proxy is named, confirm it is not authenticating or decrypting the Microsoft 365 endpoints. Microsoft’s guidance is to bypass those domains from interception entirely.
4. If only one machine is affected, build a fresh Outlook profile from the Mail item in Control Panel and test with that.
5. If several errors in the 0x80072F7x range appear alongside these, deal with TLS inspection first; it produces this symptom as a side effect.

Turning Cached Exchange Mode off makes an intermittent connection failure immediately visible, which is useful while testing. It is a diagnostic, not a fix, and it makes every folder operation depend on the network.

If connections establish and stay established for several minutes, you are done. The next section explains what Outlook is doing on the wire and why middleboxes break it.

Why it happens

A current Outlook talks to Exchange with MAPI over HTTP. Microsoft describes it as a transport protocol that improves the reliability and stability of Outlook and Exchange connections by moving the transport layer to the industry-standard HTTP model, which gives higher visibility of transport errors and better recoverability. In practice that means ordinary HTTPS on port 443, but with a traffic shape that is unusual: the client keeps long-lived requests open so the server can push changes as they happen.

Two published properties of that protocol explain most of these failures. It offers a session context that is not dependent on the connection, held by the server for a configurable period even if the user changes networks. And after a break, only TCP connections have to be rebuilt rather than RPC connections, which is why reconnection is fast. Both properties assume something in the middle is not quietly closing requests, and a firewall, load balancer, VPN concentrator or proxy with an idle-connection timeout does exactly that.

The three companion codes describe the same event from three layers. 0x80040115 is NetworkError: an operation was unsuccessful because of a problem with network operations or services. 0x80072EFF is WinINet 12031, the connection with the server has been reset. 0x800706BE is Win32 1726, RPC_S_CALL_FAILED, the remote procedure call failed. None of them tells you which device did it; they tell you which layer noticed.

0x8004011D itself is the one code here with no published meaning. It is widely repeated as a single provider in the profile failing, and that reading comes from a MAPI constant name rather than from anything Microsoft publishes against this hex value. Treat it as confirmation that the Exchange session could not be established or was lost, and diagnose from the layers that are documented.

Full reference

Sorting network from mailbox

What each code is telling you

Why the traffic shape matters

A browser makes short, self-contained requests and any appliance handles them well. Outlook holds requests open so the server can answer when something changes, and it relies on a session context the server keeps for a configurable period. An appliance that trims idle sessions sees a request that has been quiet and closes it, correctly by its own rules and wrongly for this protocol. That is why the fix is nearly always a timeout or a bypass rather than anything on the client.

Microsoft’s connectivity guidance is direct about the general principle: bypass traffic intermediation devices such as proxies and VPN services for Microsoft 365 traffic, and avoid routing connections through infrastructure that applies its own authentication. Quoting that to a network team is more productive than describing symptoms, because it turns the request into a documented design rather than an exception you are asking for.

When it is not the network

• Check the service health page in the Microsoft 365 admin centre before spending an afternoon on a firewall.
• Test the mailbox from a machine outside your network entirely. If it opens fine there and the admin centre reports nothing, the problem is yours.
• For a hybrid deployment, confirm the client is reaching the endpoint you expect and not a retired on-premises server through a stale record.
• Check whether a VPN client is forcing all traffic through a tunnel. Split tunnelling the mail endpoints is the usual remedy and removes a concentrator from the path.
• Look at whether the failures correlate with a specific time of day, which points at a scheduled job on a network device rather than at anything in Outlook.

Cached Exchange Mode as a diagnostic

With the cache on, mail keeps working from the local copy and only synchronisation stops, so a connection fault can go unnoticed for hours. Turn the cache off and the same failure becomes an immediate inability to open anything, which is exactly what you want while testing and exactly what you do not want as a permanent setting. Turn it back on once you have your answer.

Every code this article covers

Confirm the fix worked

1. Outlook stays connected over several minutes of idle time rather than reconnecting.
2. A manual send and receive completes with no error.
3. The same test passes on a second machine on the same network.
4. The mailbox also opens in a browser, confirming the server side was never the problem.
5. The behaviour survives a lunch break, which is the interval most idle timeouts fall inside.

Questions people ask about this