Outlook Will Start Rejecting MSIX Attachments in November — Admins Shouldn't Celebrate Yet
Microsoft plans to add .msix and .msixbundle files to Outlook's blocked-attachment list beginning next month, according to a BleepingComputer report published on 7 October 2026. The change affects Outlook on the web and the new Outlook for Windows client, which Microsoft has named as the targets of the rollout.
The announcement adds MSIX to the list of file types Microsoft considers risky. MSIX is a Windows packaging format; like installer formats abused in earlier reported attack chains, its payloads can be signed and delivered in ways that look legitimate to end users. Blocking delivery through email is a pragmatic response, but it addresses only one distribution channel.
What is confirmed — and what isn't. Microsoft has named the clients, but public sources do not state whether the block is enforced server-side, client-side, or both. That distinction matters more than it sounds: an admin who assumes transport-level enforcement could relax other mail-flow controls that may still be needed. Similarly, Microsoft has not stated whether tenants can override the block via policy, or whether classic Outlook for Windows is included — classic Outlook is simply not named in the announcement and may run on a different timeline. Admins should wait for rollout documentation before adjusting tenant policy.
Why it matters operationally. This is an attachment filtering change, not a new layer of threat protection. Legitimate internal workflows that distribute .msix packages via email — packaging, update, or deployment processes — could break without warning. Users may see messages arrive with attachments silently missing, and follow-up contact from an unrelated sender asking them to "re-request" the file creates an obvious social-engineering vector. Organisations that routinely email installers between sites should treat this as a workflow audit trigger, not just a mail-security fix.
Hong Kong IT teams running Microsoft 365 should, as a general matter, expect this class of change to surface gaps in internal distribution habits rather than external attack surface.
What M365 admins should check this week
- Audit mail-flow rules for any rules that permit or whitelist
.msix/.msixbundleattachments, including Safe Attachments policies and transport exceptions. - Map internal MSIX workflows — inventory any process that sends MSIX packages via email between teams, sites, or external partners.
- Identify affected clients — confirm which of your users are on Outlook on the web, new Outlook for Windows, or classic Outlook, since only the first two are named as targets.
- Watch for Microsoft guidance — monitor the Microsoft 365 Message Center and Microsoft Support for rollout timing, affected builds/channels, and any tenant-level allowlist mechanism.
- Brief your helpdesk before rollout so missing-attachment reports are triaged quickly rather than escalated as incidents.
What we still don't know
Whether the block happens at the mail service or only in the client; the exact November date and which update channels are affected; whether tenants can re-enable MSIX delivery; and whether classic Outlook for Windows follows separately. All remain unconfirmed pending Microsoft's own documentation.
Outlook 將於十一月起拒收 MSIX 附件 — 系統管理員未可過早放鬆
根據 BleepingComputer 於 2026 年 10 月 7 日發表的報道，Microsoft 計劃由下個月起，將 .msix 及 .msixbundle 檔案加入 Outlook 的封鎖附件清單。此項變更影響 Outlook on the web 及新版 Windows Outlook 客戶端，Microsoft 已點名這兩者為是次部署的目標。
是次公告將 MSIX 列入 Microsoft 視為有風險的檔案類型之一。MSIX 是一種 Windows 封裝格式；與早前報道的攻擊鏈中被濫用的安裝程式格式類似，其內容可以經簽署，並以對最終用戶而言看似合法的方式投遞。透過電郵封鎖其投遞是一項切合實際的應對措施，但只能針對其中一個分發渠道。
已確認的範圍 — 以及仍未確認的部分。 Microsoft 已點名相關客戶端，但公開資料並未說明封鎖措施是在伺服器端、用戶端，抑或兩者同時強制執行。這個分別至關重要：假設封鎖在傳輸層強制執行的系統管理員，可能因此放鬆其他仍有必要保留的郵件流程管制。同樣地，Microsoft 未有說明租戶（tenant）能否透過 policy 覆蓋此項封鎖，也未有說明舊版 Windows Outlook 是否包括在內 — 公告中根本沒有提到舊版 Outlook，其部署時間表可能有所不同。管理員應等待部署文件公布，再調整租戶 policy。
運作層面為何重要。 這是一項附件過濾變更，而非新增一層威脅防護。透過電郵分發 .msix 套件的正當內部工作流程 — 包括封裝、更新或部署程序 — 可能在毫無預警下中斷。用戶可能發現郵件已到達但附件已悄然消失，其後由毫不相干的寄件人聯絡他們，要求「重新索取」檔案，便構成一個明顯的 social engineering 攻擊渠道。經常在各站點之間以電郵傳送安裝程式的機構，應將此事視為工作流程審核的觸發點，而不只是一項郵件安全修正。
總體而言，運作 Microsoft 365 的香港 IT 團隊應預期，這類變更更可能暴露內部發放習慣的漏洞，而非外部攻擊面的問題。
M365 管理員本星期應檢視的事項
- 審核 mail-flow rules，找出任何容許或將
.msix/.msixbundle附件加入白名單的規則，包括 Safe Attachments policies 及 transport exceptions。 - 梳理內部 MSIX 工作流程 — 列舉所有透過電郵在團隊、站點或外部合作夥伴之間傳送 MSIX 套件的程序。
- 識別受影響的用戶端 — 確認哪些用戶使用 Outlook on the web、新版 Windows Outlook 或舊版 Outlook，因為只有前兩者被點名為是次部署的目標。
- 留意 Microsoft 的指引 — 監察 Microsoft 365 Message Center 及 Microsoft Support，以獲取部署時間表、受影響的版本/channel，以及租戶層面允許清單機制的最新資料。
- 向服務台簡報部署安排，以便附件缺失的報告能迅速進行初步處理（triage），而不會被當成事故層級上報。
我們仍未得知的部分
封鎖措施究竟在郵件服務層面執行，抑或僅在用戶端生效；十一月的確切部署日期以及哪些更新 channel 受影響；租戶能否重新啟用 MSIX 投遞；以及舊版 Windows Outlook 是否會另行跟隨部署。所有這些在 Microsoft 自身文件公布之前，仍未獲確認。