Outlook 0x80072F78 and 0x80072F7D: HTTPS Inspection Breaks the Exchange Session

Fix it now

Something between Outlook and the mail service is decrypting and re-encrypting the traffic, and Outlook is receiving a response it cannot parse or a secure channel it cannot use. 0x80072F78 is WinINet 12152, the server response could not be parsed.

netsh winhttp show proxy

1. Test from off the corporate network. A phone hotspot is enough. If Outlook connects there, an appliance on your own network is doing this.
2. Open the mail service in a browser on the affected machine and read the certificate issuer. If it names your firewall, proxy or antivirus vendor rather than a public authority, TLS inspection is active on that traffic.
3. On one test machine, temporarily turn off the HTTPS or SSL scanning feature in the endpoint security product and retest. Turn it straight back on once you have the answer.
4. If that was the cause, add the Microsoft 365 endpoints to the product’s inspection bypass list rather than leaving the feature off.
5. Do the same at the gateway: exclude those endpoints from decryption, from proxying and from any authentication requirement.

Microsoft’s own guidance is to bypass Microsoft 365 domains from TLS decryption, traffic interception, deep packet inspection, and network packet and content filtering. This is documented design, not a workaround you are inventing.

If the browser now shows the public issuer for that endpoint and Outlook stays connected, you are done. The next section explains why this protocol in particular breaks.

Why it happens

MAPI over HTTP uses long-lived requests, responses delivered in pieces as data becomes available, and a session context the server holds for a configurable period. An inspecting appliance sits in the middle of all three. It may buffer a response the client expected incrementally, alter or drop headers it does not recognise, insert an authentication challenge, or fail to keep a request open long enough. Outlook does not get the response shape it was written to expect and reports it as an invalid response.

0x80072F78 is that failure exactly: WinINet 12152, ERROR_HTTP_INVALID_SERVER_RESPONSE, the server response could not be parsed. It is the most honest code in this family because it says what happened rather than guessing why.

0x80072F7D is narrower than it looks. Microsoft publishes WinINet 12157, ERROR_INTERNET_SECURITY_CHANNEL_ERROR, as the application experiencing an internal error loading the SSL libraries. It is commonly seen where inspection is in play, but the published meaning is about the client’s own secure channel support rather than about the appliance, so treat a machine that reports it as worth examining locally as well: protocol settings, an incomplete update state, or a hardening script that removed something the client needs.

0x80072F0C is the one people misread most. WinINet 12044, ERROR_INTERNET_CLIENT_AUTH_CERT_NEEDED, is published as the server requesting client authentication. It does not say the client had no certificate to offer; it says something in the path asked for one. In practice that something is a proxy or a mutual-TLS policy applied to traffic it should never have been applied to.

Full reference

Confirming inspection is the cause

The three codes, as published

What Microsoft actually recommends

This is the section to quote when someone tells you bypassing inspection is not allowed. Microsoft’s network connectivity principles say to bypass Microsoft 365 domains from TLS decryption, traffic interception, deep packet inspection, and network packet and content filtering, and list TLS termination or deep packet inspection of Microsoft 365 domains among the network scenarios known to cause connectivity issues. They also name routing connections through infrastructure applying its own authentication, such as proxy authentication, as a problem in its own right.

The reasoning given is not that inspection is useless. It is that these technologies provide important risk mitigation for generic internet requests but can dramatically reduce performance, scalability and the quality of end user experience when applied to Microsoft 365 endpoints, and that the equivalent controls exist inside the service. That is a better argument than a symptom report, because it offers the security team somewhere to put the control rather than asking them to drop it.

If the bypass is in place and it still fails

• Confirm the bypass covers every endpoint the client uses, not only the mail host. Identity and authentication endpoints are a separate set and are just as easy to break.
• Confirm the bypass is applied by destination rather than by category, because category lists lag behind endpoint changes.
• Check whether a second device is also inspecting. A gateway bypass does nothing if the endpoint agent on the machine is still doing it locally.
• Check the client’s protocol settings, because 0x80072F7D has a published meaning that points at the client rather than at the appliance.
• Test with a machine on a guest network with no agent installed, which separates the two possibilities in one step.

Every code this article covers

Confirm the fix worked

1. Outlook establishes connections and keeps them.
2. The browser on the affected machine shows the public certificate issuer for the mail endpoint, proving the bypass is in effect.
3. A manual send and receive completes with no error.
4. The test passes with the security product fully enabled rather than disabled.
5. A second machine with the same agent behaves the same way, so you know the fix was the policy and not the machine.

Questions people ask about this