Microsoft verschiebt die angekündigte Sperre für zwei Windows-Installationsformate in Outlook um einen Monat. Nach einer am 10. November 2026 aktualisierten Mitteilung im Microsoft 365 Message Center sollen Anhänge mit den Endungen .msix und .msixbundle in Outlook im Web und im neuen Outlook für Windows nun zwischen Anfang und Mitte Dezember 2026 standardmäßig blockiert werden. Bisher war die Einführung für November geplant. Für Organisationen, die Installationspakete per E-Mail austauschen, bleibt damit etwas mehr Zeit, ihre Abläufe zu prüfen.
Welche Anhänge und Outlook-Versionen betroffen sind
Die neue Voreinstellung betrifft die beiden Paketformate MSIX und MSIXBUNDLE, mit denen Windows-Anwendungen bereitgestellt werden können. Microsoft ergänzt die Endungen in der Eigenschaft BlockedFileTypes der OwaMailboxPolicy. Die Änderung gilt laut Ankündigung nicht nur für die Standardrichtlinie, sondern auch für benutzerdefinierte OWA-Postfachrichtlinien eines Exchange-Online-Mandanten.
Betroffen sind ausdrücklich Outlook on the web und das neue Outlook für Windows. Nutzer dieser Oberflächen können solche Anhänge nach der Umstellung grundsätzlich nicht mehr öffnen oder herunterladen, sofern die zutreffende Organisationsrichtlinie keine entsprechende Ausnahme vorsieht. Die Ankündigung macht keine gleichlautende Aussage über das klassische Outlook für Windows oder andere E-Mail-Clients. Der Zugriff auf eine Anlage muss daher im jeweiligen Produkt und anhand der tatsächlich angewandten Richtlinie beurteilt werden.
Aus November wird Dezember
Microsoft hatte die Anpassung zunächst am 5. Oktober angekündigt. Damals sollte die weltweite Einführung Anfang November beginnen und bis zur Monatsmitte abgeschlossen sein. In der am 10. November überarbeiteten Message-Center-Nachricht MC1488841 wurde dieser Zeitplan korrigiert: Der Beginn ist jetzt für Anfang Dezember vorgesehen, der Abschluss für Mitte Dezember. Das gilt nach den veröffentlichten Angaben gleichermaßen für die reguläre weltweite Bereitstellung und die genannten US-Government-Clouds.
Wer sich auf frühere Hinweise mit dem Novembertermin bezieht, sollte die neue Planung zugrunde legen. Die Änderung ist angekündigt, aber nicht als bereits vollständig umgesetzte Sperre in allen Mandanten zu verstehen. Einzelne Umgebungen können Änderungen im Zuge der gestaffelten Verteilung zu unterschiedlichen Zeitpunkten erhalten.
Warum die Änderung im Unternehmensalltag auffallen kann
Für die meisten normalen E-Mail-Korrespondenzen spielt die Anpassung kaum eine Rolle. MSIX-Pakete sind keine üblichen Dokumentanhänge wie PDF-, Word- oder Excel-Dateien. Anders kann es bei Softwareverteilung, IT-Dienstleistern, Herstellern und Testumgebungen aussehen: Werden Installationspakete beispielsweise zwischen Entwicklung, Support und Anwendern als E-Mail-Anhang ausgetauscht, kann der vorgesehene Downloadweg künftig entfallen.
Microsoft begründet die Erweiterung der Sperrliste mit dem Schutz vor potenziell gefährlichen Anhängen. Die neue Voreinstellung lässt sich daher nicht mit einer allgemeinen Aussage gleichsetzen, MSIX-Dateien seien grundsätzlich schädlich. Entscheidend ist, dass eine per E-Mail erhaltene Installationsdatei Software auf einem Windows-System bereitstellen kann und deshalb eine sensiblere Risikoklasse darstellt als ein gewöhnliches Dokument.
Was Exchange-Online-Administratoren überprüfen sollten
Microsoft nennt in der Ankündigung keine notwendige Maßnahme für Organisationen, die diese Dateitypen nicht verwenden. Für tatsächlich betroffene Unternehmen empfiehlt Microsoft, die Liste AllowedFileTypes der jeweiligen OwaMailboxPolicy zu prüfen und erforderlichenfalls anzupassen. Dafür stellt Exchange Online die PowerShell-Cmdlets Get-OwaMailboxPolicy und Set-OwaMailboxPolicy bereit.
- Realen Bedarf feststellen: Klären, ob Softwarepakete mit den Endungen .msix oder .msixbundle überhaupt im täglichen E-Mail-Verkehr benötigt werden.
- Zugeteilte Richtlinien erfassen: Standard- und benutzerdefinierte OWA-Postfachrichtlinien einschließlich der tatsächlich betroffenen Nutzergruppen kontrollieren.
- Keine pauschale Freigabe: Nur für begründete Anwendungsfälle eine gezielte Ausnahme erwägen. Freigaben für ausführbare Installationspakete sollten nicht unbemerkt zum allgemeinen Standard werden.
- Bereitstellungsweg prüfen: Für regelmäßige Softwareverteilung können bereits vorhandene kontrollierte Installations- und Paketmanagementverfahren geeigneter sein als E-Mail-Anhänge.
- Ausnahme testen: Wenn eine Richtlinie geändert wird, die wirksamen Datei- und MIME-Regeln zusammen mit dem Verhalten im neuen Outlook und Outlook im Web prüfen. Ein Eintrag allein ersetzt keinen Funktionstest.
Die PowerShell-Dokumentation unterscheidet ausdrücklich zwischen erlaubten, gesperrten und zum Speichern erzwungenen Dateitypen. Eine Änderung sollte vorhandene Richtlinieneinträge nicht unbeabsichtigt überschreiben. Microsofts Cmdlet-Dokumentation beschreibt dafür eine Syntax zum gezielten Hinzufügen oder Entfernen einzelner Werte. Bevor produktiv eingegriffen wird, empfiehlt sich deshalb ein Export beziehungsweise eine Dokumentation des bisherigen Richtlinienzustands.
Quellen
Die geänderte Terminplanung und die betroffenen Dateitypen stehen in der Microsoft-365-Message-Center-Mitteilung MC1488841 vom 10. November 2026, die über ein öffentlich zugängliches Archiv der Originalmitteilung abrufbar ist. Microsoft dokumentiert die technische Richtliniensteuerung in Set-OwaMailboxPolicy (Microsoft Learn) und erläutert gesperrte Outlook-Anhänge in Microsoft Support. Maßgeblich für die eigene Organisation bleibt zusätzlich die Nachricht im jeweiligen Microsoft-365-Admincenter.
Werbung
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten