Two weeks after the April 2026 cutover, my ticket queue exploded. The pattern was always the same: a user opens the new Outlook for Windows, sees mail from yesterday at the top of the inbox, and assumes everything is fine. Then they miss a meeting because the invite never arrived. Or they reply to a thread that already had three follow-ups they never saw. On the surface the app looks healthy — the sync indicator is gone, no red banner, no error toast. Underneath, the mailbox has quietly stopped pulling new items.
I have now worked roughly forty of these tickets across three tenants, and the symptom is almost always one of three root causes. This is the ordered fix list I run, in the order I run it, with the exact reasons each step exists. If you support end users on Microsoft 365 and you have been getting the "new Outlook not syncing automatically" complaint since Microsoft retired classic Outlook on 6 April 2026, this is the runbook I wish I had on day one.
The symptom: silent stale inbox, no error surface
The new Outlook (the one built on the web stack, sometimes still called "Monarch" internally) does not behave like classic Outlook when sync breaks. Classic Outlook would pop a yellow bar, log to Sync Issues folders, and you could open Send/Receive > Send/Receive Settings to force a poll. The new Outlook hides all of that. Per Microsoft's own documentation on the new client, sync state is managed by the cloud sync service and is not user-tunable in the same way (Microsoft Learn: Issues when syncing your mailbox in new Outlook).
So the first thing I do on every ticket is confirm the failure mode before I touch anything. I ask the user to send themselves a message from outlook.office.com in a browser. If that message lands in the web inbox within a minute but does not appear in the new Outlook desktop client within five, sync is broken on the client side. If it does not land in the web inbox either, the problem is server-side or the account itself, and none of the steps below will help — open a Microsoft 365 service health check instead.
While I am there I also check the bottom-left status indicator. It usually says "Updated just now" even when sync is hours behind. That label is a lie in 2026 builds; it reflects the last UI refresh, not the last successful server pull. I have raised this with our TAM and it is a known issue in builds 1.2026.405.x through at least 1.2026.510.x.
Root cause 1: the Microsoft 365 modern auth token has gone stale
This is by far the most common cause I see — maybe 70% of tickets. The new Outlook uses an OAuth 2.0 access token issued by Entra ID (formerly Azure AD), with a refresh token that should silently rotate in the background. After the April cutover, a lot of accounts that were migrated from classic profiles ended up with a refresh token tied to the old Outlook (desktop) first-party app registration rather than the new Microsoft.OutlookForWindows one. When the access token expires (default 60–90 minutes), the silent refresh fails, the client does not surface the error, and sync just stops.
The fix is to force a re-authentication. In the new Outlook, click your account avatar in the top-right, then Manage accounts, then Sign out on the affected account. Do not remove the account, just sign out. Close the app fully — and I mean fully, because the new Outlook keeps a background process running. From an elevated PowerShell:
Get-Process -Name "olk" -ErrorAction SilentlyContinue | Stop-Process -Force
Get-Process -Name "Microsoft.OutlookForWindows" -ErrorAction SilentlyContinue | Stop-Process -Force
Then reopen the app and sign back in. You will get a fresh interactive auth prompt, which writes a new refresh token bound to the correct app registration. About 90% of the time, mail starts flowing within thirty seconds.
If you support a fleet and need to do this remotely, you can clear the cached tokens from the Web Account Manager (WAM) without a user sign-out. The tokens live under %LOCALAPPDATA%\Microsoft\OneAuth and %LOCALAPPDATA%\Microsoft\IdentityCache. I have an Intune remediation script that does exactly this:
# Detect: returns 1 if Outlook sync token is older than 24h
$tokenPath = "$env:LOCALAPPDATA\Microsoft\OneAuth"
if (-not (Test-Path $tokenPath)) { exit 0 }
$stale = Get-ChildItem $tokenPath -Recurse -File |
Where-Object { $_.LastWriteTime -lt (Get-Date).AddHours(-24) }
if ($stale) { exit 1 } else { exit 0 }
# Remediate: clear stale token cache
Get-Process -Name "olk","Microsoft.OutlookForWindows" `
-ErrorAction SilentlyContinue | Stop-Process -Force
Remove-Item "$env:LOCALAPPDATA\Microsoft\OneAuth\*" -Recurse -Force `
-ErrorAction SilentlyContinue
exit 0
The user will get one interactive prompt next time they open Outlook. That is a fair trade for not having to walk forty users through the click path.
Root cause 2: IMAP fallback engaged silently
This one is sneakier and I missed it on the first half-dozen tickets. The new Outlook officially supports IMAP/POP accounts as of the November 2025 release, but the implementation has a quirk: if the Entra ID connection to a Microsoft 365 mailbox throws certain transient errors during account migration, the client will silently re-provision the account as IMAP against outlook.office365.com:993. The mailbox still works — IMAP is a real protocol — but you lose calendar sync, contacts, shared mailbox auto-mapping, push notifications, and you are stuck on a 15-minute poll instead of EAS push.
To check, open Settings > Accounts > Email accounts, click your account, and look at the Account type field. If it says IMAP for an account that should be Microsoft 365, that is your problem. The fix is to remove the account entirely (this time really remove it, not just sign out), restart Outlook, then add it back via the "Microsoft 365" option specifically — not the generic "Other email account" flow that the app sometimes defaults to.
Before you remove anything, export the local data. The new Outlook does not have a PST export yet — Microsoft has said this is coming in H2 2026 — so I use the web client's Export mailbox feature or PowerShell against the Graph API:
Connect-MgGraph -Scopes "Mail.Read"
$user = "[email protected]"
$messages = Get-MgUserMessage -UserId $user -All `
-Property "subject,receivedDateTime,from,bodyPreview"
$messages | Export-Csv -Path ".\$user-backup.csv" -NoTypeInformation
That gives me a paper trail in case anything goes wrong during the re-add. I have not actually needed it yet, but the day I stop taking the backup is the day I will need it.
Root cause 3: network — and it's usually not what you think
The remaining 20% of my tickets are network-related, and they almost always trace back to one of two things: a corporate proxy that does not handle the new Outlook's WebSocket connection to substrate.office.com, or an over-eager endpoint security product blocking *.outlook.office.com long-poll connections.
The new Outlook does not use MAPI/HTTP like classic Outlook. It uses HTTPS to a handful of Substrate endpoints plus a persistent WebSocket for push notifications. Microsoft publishes the required endpoints in the standard Microsoft 365 URL/IP service (Microsoft 365 URLs and IP address ranges), but the ones that specifically matter for new Outlook push sync are:
outlook.office.com (HTTPS, 443) — REST mailbox APIsubstrate.office.com (WebSocket, 443) — push channelnexus.officeapps.live.com (HTTPS, 443) — telemetry and feature flagslogin.microsoftonline.com (HTTPS, 443) — token refresh
To diagnose, I run a quick PowerShell sweep that mirrors what the client tries to do:
$endpoints = @(
"outlook.office.com",
"substrate.office.com",
"nexus.officeapps.live.com",
"login.microsoftonline.com"
)
foreach ($host in $endpoints) {
$result = Test-NetConnection -ComputerName $host -Port 443 `
-InformationLevel Quiet -WarningAction SilentlyContinue
"{0,-35} {1}" -f $host, $(if ($result) { "OK" } else { "FAIL" })
}
If any of those come back FAIL, the user's network is the problem and no client-side fix will help. The one that bites most often is substrate.office.com, because some SSL-inspection proxies cannot keep a WebSocket alive for the full 30-minute idle window. The fix is to add the four hostnames above to the SSL-inspection bypass list. Your network team will know what to do; the magic phrase is "please bypass SSL inspection for these Microsoft 365 Optimize-category endpoints."
If you are on a VPN, try disconnecting and reproducing on the bare internet connection. I have lost count of how many split-tunnel configs route outlook.office.com over the VPN, then the VPN concentrator's IDS chokes on the WebSocket. That is also why I always tell users with sync problems to test from home before I escalate — it is the cheapest way to isolate corporate network from client config.
Caveats, gotchas, and the order I actually run these
A few things I have learned the hard way that do not fit neatly into the three buckets above:
- Restart is not enough. The new Outlook's background process survives a regular close. You must kill
olk.exe explicitly, or sign out and back in. Just closing the window does almost nothing.
- The "Try the new Outlook" toggle has been removed in builds after the April cutover. If your user is somehow still on classic Outlook, they are on a separately licensed extended-support SKU. Treat that as a different product entirely.
- Shared mailboxes need extra care. Auto-mapped shared mailboxes do not appear in the new Outlook until you have signed in to the primary mailbox successfully at least once on that device. If a user complains the shared mailbox is missing, fix the primary first.
- Cached mode does not exist anymore. All mail is server-truth. There is a local cache for offline reading, but you cannot configure its size or contents. If a user expects to see ten-year-old email on a brand-new device, they will need to wait — first sync of a large mailbox can take six to twelve hours.
My actual order on every ticket: confirm via webmail, force re-auth, check account type for IMAP fallback, then run the network sweep. I get to a fix inside fifteen minutes on roughly four out of five tickets. The fifth one is almost always a network or licensing issue that needs another team.
If you support a mixed environment and are still untangling what changed after the cutover, I wrote up the broader migration in the classic Outlook retirement 2026 checklist, and the specific Entra ID app-registration changes in this note on the Outlook app registration changes. Both pair well with this runbook.
FAQ
Why does the new Outlook say "Updated just now" when it's actually broken?
The status indicator in builds from April 2026 onward reflects the last UI refresh, not the last successful server poll. It is a known cosmetic bug. Always confirm sync by sending a test email from outlook.office.com and watching for it on the desktop client.
Will signing out and back in lose any local data?
No. The new Outlook is server-truth; the local cache is rebuilt from the mailbox on next sign-in. Drafts saved locally that have not been uploaded yet are the only risk, and they are extremely rare because draft autosave runs every few seconds. Removing the account entirely (different from signing out) is what triggers a longer re-cache, but still does not lose mailbox data.
Can I force a manual send/receive in the new Outlook like in classic?
Not directly. There is no Send/Receive button. The closest equivalent is pulling down on the message list to trigger a refresh, or pressing F9 which most builds now bind to a forced sync. If F9 does not visibly do anything, the client is not in a state where a manual refresh will help — work through the runbook above instead.
Does this apply to Outlook on Mac too?
Partially. The Outlook for Mac client shares a lot of the Substrate and Entra ID plumbing, so root causes 1 and 3 are the same. The IMAP-fallback bug in root cause 2 is Windows-specific so far in 2026 builds. The PowerShell snippets obviously do not apply on macOS; use killall "Microsoft Outlook" instead and re-authenticate from the account settings pane.
The new Outlook is going to get better — Microsoft is shipping a build a month and the worst of the migration bugs are already gone compared to January 2026. But until the "Updated just now" lie gets fixed and the silent IMAP fallback gets sorted, every helpdesk team should have a runbook like this one taped to the wall.
