Fix: Outlook Web App Can't Download Attachments

If the private window test worked, your normal browser session is carrying corrupted data, cached OWA assets, an expired authentication cookie, or both. Clearing the cache properly (not just a quick Ctrl+F5) solves this cleanly.

In Microsoft Edge or Chrome, press Ctrl + Shift + Delete. A dialog opens. Set the time range to All time. Check all of the following boxes:

• Browsing history
• Download history
• Cookies and other site data
• Cached images and files

Click Clear data (Edge) or Clear data (Chrome). This takes 10–60 seconds depending on how much is cached.

In Firefox, go to Settings → Privacy & Security → Cookies and Site Data → Clear Data. Check both "Cookies and Site Data" and "Cached Web Content," then click Clear.

After clearing, close the browser completely, don't just close the tab, close the whole window. Re-open it, navigate to outlook.office.com, and sign in fresh. Signing out of OWA first is also worth doing: click your profile picture in OWA → Sign out → then close and reopen the browser before signing back in. This forces a clean token refresh.

If you're in an enterprise environment where your browser is managed by Group Policy, you may not have permission to clear certain categories. In that case, skip to Step 3 and have an admin check the policy settings instead.

What you should see: After signing back into OWA, navigate to an email with an attachment and click the download icon. The file should prompt you to save normally. If it still fails, move to Step 2.

Security extensions, ad blockers, and download managers can all intercept OWA's attachment download mechanism and block it silently. This is one of the sneakiest causes of the Outlook Web App file download failing problem because everything else in OWA works fine, only attachments break.

In Microsoft Edge, go to edge://extensions/ in the address bar. Toggle off every extension, one at a time, then try the OWA attachment download after each one. The usual suspects I've seen cause this are: uBlock Origin, Privacy Badger, Cisco Umbrella browser extensions, Zscaler Web Security, and corporate proxy extensions.

In Chrome, go to chrome://extensions/ and do the same.

Additionally, check your browser's built-in pop-up blocker. OWA sometimes opens attachment downloads in a new tab or pop-up window, and if that's blocked, the download appears to fail even though OWA actually triggered it correctly.

In Edge: Settings → Cookies and site permissions → Pop-ups and redirects. Add outlook.office.com and outlook.office365.com to the Allow list.

In Chrome: Settings → Privacy and security → Site settings → Pop-ups and redirects. Add the same two domains to Allow.

Sites to add to your browser Allow list:
https://outlook.office.com
https://outlook.office365.com
https://attachments.office.net
https://*.sharepoint.com

The attachments.office.net domain is important, OWA often serves actual attachment file data from that hostname, and many pop-up blockers and security extensions treat it as a third-party domain and block it by default.

What you should see: With extensions disabled and the domains allowed, attempt the attachment download again. A save dialog should appear or the file should land in your Downloads folder automatically.

When multiple users in your organization can't download attachments in Outlook Web App at the same time, this is your most important step. A Microsoft 365 service incident will not be fixed by anything you do on the client side, you need to identify it, understand its scope, and communicate it to your users while Microsoft works the fix.

Sign in at admin.microsoft.com with a Global Admin or Service Support Admin account. In the left navigation, go to Health → Service Health. Look at the Exchange Online and Microsoft 365 suite rows. Active incidents show a red circle icon; advisories show yellow.

Click any active Exchange Online incident to expand it. You'll see:

• The incident ID (format: EX######)
• Affected features, look for "Outlook on the web" or "Attachment downloads"
• User impact description
• Current status and next update time
• Mitigation steps Microsoft recommends

You can also pull service health data programmatically using PowerShell and the Microsoft Graph API, useful if you need to build an alert or pull history:

# Connect to Microsoft Graph (requires ServiceHealth.Read.All scope)
Connect-MgGraph -Scopes "ServiceHealth.Read.All"

# Get current Exchange Online service issues
Get-MgServiceAnnouncementIssue -Filter "service eq 'Exchange Online'" |
  Select-Object Id, StartDateTime, Status, Title |
  Format-Table -AutoSize

If an active incident covers OWA attachment downloads, document the incident ID and share it with affected users. There's nothing further to do on your end, Microsoft's engineers are working it. Post updates in your internal IT channel so users aren't submitting duplicate tickets.

If there's no active incident listed, you're dealing with something tenant-specific or client-specific, and you move on to the next steps.

What you should see: Either an active incident that explains the problem, or a clean health dashboard that confirms you need to keep digging.

Exchange Online has a specific set of policies that control exactly what OWA users can and can't do, including whether they can download attachments at all. I've walked into organizations where a well-meaning admin locked down OWA file access months ago and nobody documented it, causing confusion when new users couldn't figure out why they couldn't save email attachments.

There are two layers to check: the OWA Mailbox Policy assigned to the affected user, and the Organization-level OWA policy.

Connect to Exchange Online PowerShell first:

# Install and connect Exchange Online Management module
Install-Module -Name ExchangeOnlineManagement -Force
Connect-ExchangeOnline -UserPrincipalName admin@yourdomain.com

Now check what OWA Mailbox Policy is assigned to the affected user and what that policy allows:

# Find the OWA policy assigned to the user
Get-CASMailbox -Identity "user@yourdomain.com" | Select OwaMailboxPolicy

# Check that policy's attachment settings
Get-OwaMailboxPolicy -Identity "OWAMailboxPolicy-Default" |
  Select DirectFileAccessOnPublicComputersEnabled,
         DirectFileAccessOnPrivateComputersEnabled,
         ForceWacViewingFirstOnPublicComputers,
         ForceWacViewingFirstOnPrivateComputers,
         WacViewingOnPublicComputersEnabled,
         WacViewingOnPrivateComputersEnabled |
  Format-List

The key settings here: DirectFileAccessOnPrivateComputersEnabled and DirectFileAccessOnPublicComputersEnabled control whether users can download files directly. If either is set to False, users on those device types cannot download attachments, they can only view them in the browser via Office Online viewer. To re-enable direct downloads:

# Re-enable direct file access for private computers
Set-OwaMailboxPolicy -Identity "OWAMailboxPolicy-Default" `
  -DirectFileAccessOnPrivateComputersEnabled $true `
  -DirectFileAccessOnPublicComputersEnabled $true

Changes take effect within 60 minutes, or you can have affected users sign out and back into OWA to pick up the policy update faster.

What you should see: After the policy update, affected users should be able to download attachments directly from OWA without being forced into the browser-based viewer.

This is the fix that catches organizations off guard the most. If your tenant uses Azure AD Conditional Access (now called Microsoft Entra Conditional Access), and most organizations with Microsoft 365 Business Premium or E3/E5 do, a policy might be blocking attachment downloads on devices that aren't marked as compliant or joined to Azure AD. The user sees the OWA interface just fine, can read emails, but can't download files. From their perspective, it looks like OWA is broken. From your perspective as an admin, it's working exactly as configured.

Sign in to the Microsoft Entra admin center at entra.microsoft.com. Go to Protection → Conditional Access → Policies. Look for any policy with these characteristics:

• Target apps include Office 365 Exchange Online
• Grant controls include Require device to be marked as compliant or Require Hybrid Azure AD joined device
• Session controls include Use app enforced restrictions or a Defender for Cloud Apps session policy

If a session policy is in play via Defender for Cloud Apps (formerly MCAS), sign into the Microsoft Defender portal at security.microsoft.com, go to Cloud Apps → Policies → Session policies, and look for any policy targeting Exchange Online or OWA with a Block download action. These session policies are the number one cause I see for OWA attachment downloads being blocked on unmanaged or non-compliant devices:

# Check if App-Enforced Restrictions are applied via PowerShell
Get-CASMailbox -Identity "user@yourdomain.com" |
  Select OWAEnabled, OwaMailboxPolicy, ActiveSyncEnabled

For the affected user to download attachments, their device either needs to become compliant (enrolled in Intune, passing all compliance checks) or an admin needs to carve out a named location or device filter exception in the Conditional Access policy. Don't disable the policy outright, scope a proper exclusion instead to maintain your security posture.

What you should see: Once the device is compliant or the policy exception is in place, the user should be able to download OWA attachments normally. You can verify compliance status in the Intune admin center at intune.microsoft.com under Devices → All devices.