Does this bug affect Word or PowerPoint attachments too?

Microsoft's advisory for EX1189359 names Excel files specifically. If a Word or PowerPoint attachment with an accented or symbol-heavy filename also fails to open, the encoding issue is the first thing to test: save the file to your desktop and open it directly in the app. The same workaround applies regardless of file type.

Will renaming the attachment to remove accents fix it permanently?

Renaming the local copy after you download it works fine, but you can't rename an attachment before it lands in your inbox. If the sender's file has a name like "Rapport-Q3-Résumé.xlsx," it arrives with that name every time. Renaming your saved copy is a one-time workaround, not a setting you can turn on to prevent the error.

New Outlook Won't Open Excel Attachments With Non-ASCII Filenames: How to Fix It

If new Outlook throws "Try opening the file again later" every time you double-click an Excel attachment, check the filename first. Microsoft confirmed this is a known bug (reference ID EX1189359) that hits attachments with non-ASCII characters: accented letters like é or ñ, symbols, or non-English scripts in the file name. The fastest fix is opening the file in Outlook on the web instead of the desktop app, or saving the attachment to your computer and opening it straight from there.

I ran into this on a shared budget file named "Coûts-Février.xlsx" from a colleague in Montreal. New Outlook for Windows choked on it every time, while the exact same email in Outlook on the web opened the attachment without a hitch. That difference is the clue to what's broken.

Why Won't New Outlook Open My Excel Attachment?

New Outlook fails to open Excel files when the filename contains a character outside the standard ASCII set, such as accented letters, umlauts, curly quotes, or characters from non-Latin alphabets. Microsoft's service health dashboard lists this under EX1189359 and describes the cause as a missing encoding step in the request the app sends to open the file.

In plain terms: when new Outlook builds the request to fetch and preview your Excel file, it doesn't properly encode special characters in the filename. The request goes out malformed, the server can't match it to your file, and you get a generic error instead of your spreadsheet. This has nothing to do with the file's actual content, size, or format. A 10 KB spreadsheet with a plain filename like "budget.xlsx" opens fine. The identical spreadsheet renamed to "budget-résumé.xlsx" fails.

Filenames that trigger the bug include:

Accented Latin letters: é, è, ñ, ü, ö, ç
Curly or smart quotes and apostrophes copied from Word
Non-Latin scripts: Cyrillic, Japanese, Arabic, Chinese characters
Certain symbols: ™, ©, or em dashes inside the filename itself

What Does the Error Say?

You'll see "Try opening the file again later" as a pop-up or inline message when you click the attachment preview in new Outlook. It gives no error code and no mention of the filename, which is why this bug took a while to trace.

The message shows up whether you try to preview the file inline (Outlook's built-in Excel viewer) or click "Open" to launch it in the desktop Excel app. Retrying doesn't help, because the problem isn't a timeout or a slow connection. The request is malformed before it ever reaches the server, so clicking "try again" sends the same broken request a second time.

How Do You Fix It Right Now?

Two workarounds fix this immediately, before Microsoft's server-side patch reaches your account. Use Outlook on the web for a same-session fix, or save the attachment locally and open it outside Outlook.

Fix 1: Open the Attachment in Outlook on the Web

Go to outlook.office.com and sign in with the same account.
Open the same email with the problem attachment.
Click the Excel file. Outlook on the web builds the file request differently and isn't affected by this particular encoding bug, so the attachment opens normally.

This works because the desktop app and the web app handle attachment requests through separate code paths. The bug lives in the desktop client's request builder, not in Exchange Online itself, so the file was never corrupted or missing in the first place.

Fix 2: Save the File First, Then Open It Locally

In new Outlook, right-click the attachment (or click the small download arrow next to it).
Choose "Save As" and pick a folder, like your Desktop or Downloads.
Close the email if Outlook still has a preview pane open.
Go to the saved file in File Explorer and double-click it to open directly in Excel.

Saving the file bypasses Outlook's internal preview and open request completely. Once the file sits on your hard drive, Excel opens it the normal way, reading local bytes instead of going through the broken request path. This method works even if you're offline or don't want to switch to the web version.

Fix 3: Ask the Sender to Rename the File

If you get the same attachment repeatedly from one coworker or automated report, ask them to rename it before sending using only standard English letters, numbers, hyphens, and underscores. Change "Résumé-Ventes.xlsx" to "Sales-Summary.xlsx" and the bug won't trigger at all, regardless of which Outlook version you use to open it.

This isn't always practical for external senders or automated systems, but it's the cleanest fix for recurring internal reports where you control the naming convention.

Is Microsoft Fixing This Permanently?

Yes. Microsoft has a server-side fix in deployment that corrects the missing encoding in the file-open request, and it's rolling out gradually across tenants rather than all at once. You don't need to install anything or change a setting; once your tenant receives the update, non-ASCII filenames will open normally in new Outlook without any workaround.

If you're still hitting the error weeks from now, your tenant likely hasn't received the rollout yet. Check the Microsoft 365 admin center's Service Health page for EX1189359 if you're an IT admin managing multiple accounts, since it shows rollout status specific to your organization rather than a global date.

Should You Switch Back to Classic Outlook?

Switching back to classic Outlook does avoid this specific bug, since classic Outlook builds attachment requests through older, unaffected code. But classic Outlook is being phased out on a Microsoft-set timeline, and switching back solely for one bug means giving up new Outlook's other changes, like the unified inbox for multiple accounts. For an occasional Excel attachment, Fix 1 or Fix 2 above solves the immediate problem without reverting your whole setup.

If you manage Outlook for a team, and this error is generating a steady stream of help desk tickets, a temporary organization-wide rollback while you wait for the EX1189359 fix might be worth it. For a single user hitting this once or twice a week, saving the file locally takes ten seconds and doesn't require any change to your default mail client. If your team also has rules or shared mailboxes that stopped working after switching to new Outlook, see our guide on why Outlook rules stop working in new Outlook for Windows 11.

Quick Reference

Cause: New Outlook desktop mishandles non-ASCII characters (accents, symbols, non-Latin scripts) when building the request to open an Excel attachment.
Error shown: "Try opening the file again later," with no error code.
Tracking ID: EX1189359 on Microsoft's service health dashboard.
Fastest fix: Open the same email in Outlook on the web (outlook.office.com).
Offline fix: Save the attachment to your computer, then open it directly in Excel.
Long-term fix: Microsoft's server-side patch is rolling out; no user action needed once your tenant receives it.