Old mail opens, the folder list looks normal, and a message sent this morning never leaves the Outbox. That combination says the local cache is fine and the connection to Exchange is not, and it is the most misread symptom in this whole area. Nothing has crashed, which is why the report usually arrives as Outlook being slow rather than Outlook being disconnected.

Work the checks in order, and note which Outlook build you are looking at before anything else, because the controls differ.

Confirm which client and which account type

Classic Outlook for Windows, the new Outlook, and Outlook on the web are three different clients with three different connection paths, and advice for one is frequently wrong for another. Within classic Outlook, an Exchange account and a POP or IMAP account behave differently when the server is unreachable, because only the Exchange account has a MAPI transport and a cached mailbox store. Identify the account type in the account settings before interpreting any status. A fix copied from an IMAP setup will not describe an Exchange connection.

Write the client name and version down. Support threads routinely mix them, and the screenshots stop matching halfway through.

Read the connection status while it is failing

With classic Outlook running, hold Ctrl and right-click the notification-area icon, then open Connection Status. Do it during the failing operation rather than after a restart, because the view reports what the client is attempting at that moment. Record the server name, the protocol and the state, then compare that server with what you expect the account to use. Microsoft's diagnostic guidance covers this view and the more detailed logging you can collect when the summary is not enough.

Modern Exchange deployments carry Outlook traffic over MAPI over HTTP, so opening SMTP submission ports is not a repair for a mailbox connection. If transport reaches the service, keep the HTTP or authentication error and work on that stage instead of resetting a password that was never the problem.

Compare the endpoint with the browser's path

A working web mailbox proves that a browser can reach one endpoint through one name and one proxy configuration. It does not prove that Outlook resolved the same address, used the same route or accepted the same certificate. With a VPN in place, split DNS can send the Outlook name to an internal address while the browser uses a public one, and that difference alone explains a working web session beside a broken client. Compare the resolved address, the selected route and the TLS identity on both paths.

Administrative portals and remote PowerShell are not substitutes for a user mailbox test, because they are different services with different authentication.

Test the cache against a fresh operation

Cached Exchange Mode keeps a local copy and synchronises with the server, which makes it tolerant of interruption and does not make it independent of the server. Reading an old cached message is not a network test, and neither is the Work Offline toggle. Send a new message or force a synchronisation and watch that specific operation. If small exchanges succeed while large transfers stall, packet size and path MTU deserve the attention, with evidence taken from the failing operation.

Changing cache mode can move the symptom without repairing the route or the service.

After any supported correction, repeat the original operation and confirm that fresh data reaches the server and comes back. Record that result separately from the convenience of reading mail that was already on disk.

Nuŋlɔɖi siwo ku ɖe eŋu