EWS-Abschaltung und E-Mail-Signaturen: was tatsächlich ausfällt
Exchange Web Services wird zwischen Oktober 2026 und April 2027 schrittweise deaktiviert. Wenn Ihr Tool für E-Mail-Signaturen darauf angewiesen ist, funktioniert es irgendwann in diesem Zeitraum nicht mehr – und Microsoft Graph, der empfohlene Ersatz, kann Signaturen überhaupt nicht verwalten.
Kurz gesagt: EWS wird nicht an einem einzigen Tag abgeschaltet. Microsoft beginnt im Oktober 2026 weltweit mit der Deaktivierung und schließt die Abschaltung im April 2027 ab. Signaturanbieter, die auf EWS aufbauen, haben keinen direkten Migrationspfad, denn Graph hat Signaturen nie unterstützt, und das ist auch nicht vorgesehen. Realistische Alternativen sind ein Outlook-Add-In, eine Nachrichtenflussregel (Transportregel) oder ein Relay für ausgehende E-Mails – und sie sind nicht gleichwertig.
Der Zeitplan, richtig dargestellt
Ein guter Teil der Inhalte, die derzeit dazu kursieren, behauptet, am 1. Oktober 2026 falle alles aus. Das steht so nicht in der Dokumentation von Microsoft, und der Unterschied ist wichtig, wenn Sie eine Migration planen.
| Wann | Was passiert |
|---|---|
| Juli 2018 | EWS wird abgekündigt. Keine weiteren Funktionsupdates. |
| 2023 | Als Zieltermin für die Deaktivierung wird Oktober 2026 festgelegt. |
| Januar 2024 | Der Midnight-Blizzard-Vorfall betrifft EWS. Der Umfang wird von Drittanbieteranwendungen auf die eigenen Produkte von Microsoft ausgeweitet, und das Vorhaben wird beschleunigt. |
| Oktober 2026 | Die Deaktivierung von EWS beginnt, Mandant für Mandant. Seit dem 10. Oktober braucht ein Mandant, der EWS behält, eine Zulassungsliste für Anwendungen. |
| April 2027 | EWS ist vollständig deaktiviert. Keine Ausnahmen. |
Der Mechanismus ist eine Mandanteneinstellung namens EWSEnabled. Die meisten Mandanten haben sie nie gesetzt, also steht sie auf Null. Sobald der Rollout einen Mandanten erreicht, wird aus Null der Wert False, und jede EWS-Anwendung in diesem Mandanten funktioniert auf einen Schlag nicht mehr. Weil der Rollout schrittweise und nicht gleichzeitig erfolgt, können zwei Organisationen mit demselben Tarif EWS im Abstand von Monaten verlieren.
Tragen Sie ihre Anwendungs-ID in eine Liste EWSAllowedAppIDs ein und setzen Sie EWSEnabled=True. Wenn Sie das Microsoft überlassen, wird die Liste kurz vor der Umstellung Ihres Mandanten aus 60 Tagen beobachteter Nutzung befüllt, sodass eine Anwendung, die monatlich oder quartalsweise läuft, leicht übersehen werden kann. Alle Termine und die Reihenfolge, in der Sie die Änderungen vornehmen, finden Sie in unserem Zeitplan der EWS-Abschaltung.
Das ist ein Aufschub, keine Lösung. Er hält eine bestimmte Anwendung während der Phase der schrittweisen Abschaltung am Leben; den April 2027 übersteht er nicht.
Warum Graph das nicht löst
Die Empfehlung von Microsoft für die EWS-Migration ist konsistent und vernünftig: Wechseln Sie zu Microsoft Graph. Für Kalender, Kontakte, E-Mails und die meisten Postfachvorgänge gibt es direkte Entsprechungen, und Microsoft veröffentlicht die Gegenstücke Vorgang für Vorgang.
Signaturen sind die Ausnahme, und es lohnt sich, genau zu benennen, warum.
Graph hat nie eine API zum Lesen oder Schreiben von Outlook-Signaturen bereitgestellt. Das ist keine Lücke, die auf eine Vorschauversion wartet. Microsoft veröffentlicht eine Roadmap der EWS-Funktionen, die Graph noch nicht abdeckt – Postfachimport und -export, öffentliche Ordner, Import/Export von Microsoft 365-Gruppen, In-Situ-Archiv, Deltaabfragen für Serienereignisse, Kurznotizen, Benutzerkonfiguration und eine Reihe von Verwaltungs-APIs. Die Signaturverwaltung steht nicht auf dieser Liste, weil Signaturen in EWS nie ein vollwertiges Postfachobjekt waren, wie es Kalender waren. Sie gehören zum Outlook-Client.
Die praktische Folge: Ein Signaturanbieter, der von EWS zu Graph migriert, portiert keine Integration. Er wählt einen völlig anderen Bereitstellungsmechanismus, mit anderer Abdeckung und anderen Fehlerbildern. Wenn man Ihnen sagt, ein Tool sei „bereit für Graph“, ist die lohnende Frage, auf welchen der unten beschriebenen Mechanismen es tatsächlich umgestellt hat.
Alle verbleibenden Optionen im ehrlichen Vergleich
Nach EWS gibt es vier Wege, ausgehende E-Mails in Microsoft 365 mit einer Signatur zu versehen. Keiner ist den anderen klar überlegen; jeder geht andere Kompromisse ein.
| Methode | Erreicht Mobilgeräte | Sichtbar in „Gesendete Elemente“ | Bilder | Hauptnachteil |
|---|---|---|---|---|
| Exchange-Nachrichtenflussregel Transportregel / Haftungsausschluss |
Ja | Nein | Nein | Hängt an das Ende des gesamten Threads an, nicht unter die letzte Antwort. Überspringt stillschweigend Zeilen mit Variablen, die sie nicht füllen kann. Verschlüsselte E-Mails erzwingen eine unglückliche Wahl der Fallbackaktion. |
| Exchange Online PowerShell Set-MailboxMessageConfiguration |
Nein | Ja | Eingeschränkt | Setzt die OWA-Signatur und greift dann stillschweigend nicht mehr, sobald Roamingsignaturen aktiviert sind – zunehmend der Standard. Scheitert leise, und das ist die schlechteste Art zu scheitern. |
| Office.js-Add-In Ereignisbasierte Aktivierung |
Teilweise | Ja | Ja | Eine Testmatrix über klassisches Outlook, das neue Outlook, Mac, Web, iOS und Android. Eine Laufzeitgrenze von fünf Minuten. Die mobile Unterstützung ist durch den Mailbox-Anforderungssatz 1.5 begrenzt. Es wird etwas installiert. |
| Ausgehendes Relay Ausgehender Exchange-Connector |
Ja | Nein | Ja | Setzt einen Drittanbieter in den ausgehenden Zustellweg Ihrer E-Mails. Dessen Ausfall ist Ihr Ausfall. Es wird nichts installiert, und es deckt jeden Client ab, auch Smartphones. |
Worum es bei „sichtbar in ‚Gesendete Elemente‘“ wirklich geht
Nachrichtenflussregeln und Relays fügen die Signatur beide erst ein, nachdem die Nachricht den Client verlassen hat. Der Benutzer verfasst die Nachricht, ohne die Signatur zu sehen, und seine Kopie im Ordner „Gesendete Elemente“ enthält sie nicht. Das klingt kosmetisch und ist es nicht: Es ist die mit Abstand häufigste Ursache für Support-Tickets bei der Bereitstellung von Signaturen, weil Benutzer nicht erkennen können, ob es funktioniert hat. Jede Evaluierung, die das auslässt, führt zu einem Tool, dem Ihre Mitarbeitenden misstrauen.
Add-Ins und clientseitige Ansätze zeigen die Signatur schon beim Verfassen an, weshalb sie sich trotz des Aufwands für die Client-Matrix halten.
Was ausgehendes Routing tatsächlich bedeutet
Das Relay ist die am häufigsten missverstandene Option, meist so, dass es invasiver wirkt, als es ist.
Das Einfügen von Signaturen erfordert nur ausgehendes Routing. In Microsoft 365 ist das ein ausgehender Connector in Exchange Online; in Google Workspace ist es die Einstellung für den SMTP-Relay-Dienst oder das Routing. Keines von beiden berührt MX-Einträge. Die eingehende Zustellung ist nicht betroffen. Beides lässt sich in wenigen Minuten in der jeweiligen Verwaltungsoberfläche rückgängig machen. So arbeiten Exclaimer und Opensense bereits, und es ist eine kleinere Änderung, als die Formulierung „Ihre E-Mails über einen Dritten leiten“ vermuten lässt.
Die tatsächlichen Kosten liegen woanders und sollten klar benannt werden: Sie nehmen eine Abhängigkeit im Zustellweg Ihrer E-Mails in Kauf. Hat der Relay-Betreiber einen Ausfall, kann Ihre Organisation keine E-Mails senden. Das ist eine echte betriebliche Verpflichtung auf Seiten des Anbieters – 24/7-Rufbereitschaft, keine Support-Warteschlange – und eine berechtigte Frage an jeden Anbieter, der ein Relay im Programm hat. Es ist auch der Grund, warum Sie aus unserer Sicht besser nicht damit anfangen.
Was wir tatsächlich empfehlen würden
Wenn bei Ihnen EWS ausfällt, liegt die Versuchung nahe, den nächstliegenden Ersatz zu suchen und weiterzumachen. Davon würden wir aus zwei Gründen abraten.
Erstens lässt Ihnen der schrittweise Rollout mehr Spielraum, als die Darstellung mit dem 1. Oktober nahelegt. Wenn Ihr Mandant noch nicht an der Reihe war, haben Sie Zeit für eine gründliche Evaluierung, statt zweimal zu migrieren.
Zweitens wurden EWS-basierte Tools meist gewählt, weil sie Signaturen schrieben, ohne den Zustellweg anzufassen. Wenn Sie sie durch ein Relay ersetzen, haben Sie Ihr Risikoprofil erheblich verändert, und das sollten Sie bewusst tun und nicht als Notmaßnahme. Ein Relay ist die richtige Antwort, wenn Sie Durchsetzung über alle Clients hinweg brauchen, einschließlich Mobilgeräten, Antworten und Weiterleitungen. Es ist die falsche Antwort, wenn es Ihnen eigentlich darum ging, dass Signaturen korrekt und aktuell sind.
Vor der Wahl lohnt es sich, zwei Dinge zu trennen: Durchsetzung (niemand kann E-Mails senden, die nicht markenkonform sind) und Korrektheit (Signaturen spiegeln aktuelle Positionen, das aktuelle Logo und aktuelle Haftungsausschlüsse wider). Die meisten Organisationen beschreiben ein Durchsetzungsproblem und haben, wenn man sich die bereitgestellten Signaturen ansieht, ein Korrektheitsproblem. Dafür gibt es unterschiedliche Antworten, und die für die Korrektheit braucht nichts im Zustellweg.
So prüfen Sie, ob Ihr Mandant betroffen ist
Drei Schritte, für keinen davon brauchen Sie einen Anbieter. Gehen Sie in dieser Reihenfolge vor, denn der erste zeigt Ihnen, wie viel Zeit Sie haben, und der zweite, was dabei ausfallen würde.
1. Lesen Sie Ihre aktuelle Einstellung aus
In Exchange Online PowerShell:
Get-OrganizationConfig | Format-List EwsEnabled,
EwsApplicationAccessPolicy, EwsAllowList, EwsBlockList
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs
Die Zulassungsliste wird nur mit diesem zweiten Schalter zurückgegeben; ohne ihn erscheint die Eigenschaft leer, auch wenn eine Liste existiert.
EwsEnabled hat drei Zustände, und der dritte ist der, über den viele stolpern:
| Wert | Heute | Ab Oktober 2026 |
|---|---|---|
$true | Jeder EWS-Zugriff erlaubt, außer es ist eine AppID-Zulassungsliste konfiguriert – dann nur die Apps darauf. | Nur Apps auf der Zulassungsliste. |
$false | Jeder EWS-Zugriff gesperrt. | Jeder EWS-Zugriff gesperrt. |
$null | Jeder EWS-Zugriff erlaubt. | Wird in $false umgewandelt, sobald Microsoft den Mandanten erreicht, mit einer Vorankündigung von 7 Tagen im Nachrichtencenter. |
Die meisten Mandanten haben das nie angefasst, also zeigen die meisten Mandanten $null. Auf diese Gruppe wirkt der Rollout im Oktober.
2. Finden Sie heraus, was EWS tatsächlich nutzt
Microsoft stellt das pro Mandant bereit. Im Microsoft 365 Admin Center: Berichte → Nutzung → Exchange → Registerkarte EWS-Nutzung. Sie erhalten pro Anwendung die aufgerufenen SOAP-Aktionen, das Aufrufvolumen und das Datum der letzten Aktivität, und der Bericht lässt sich als CSV exportieren.
Zwei Eigenschaften dieses Berichts entscheiden darüber, ob Sie eine zutreffende Antwort erhalten:
- Die Nutzung wird wöchentlich aggregiert, nicht täglich, und kann bis zu 10 Tage brauchen, bis sie erscheint. Ein Zeitraum von 7 Tagen kann daher leer sein, während eine Anwendung aktiv genutzt wird.
- Filtern Sie auf 90 Tage, nicht auf 7 oder 30. Alles, was monatlich läuft – Exporte zum Quartalsende, Archivierungsjobs, eine Signatursynchronisierung, die nur bei Verzeichnisänderungen anspringt –, ist in einem kurzen Zeitraum unsichtbar und fällt im Oktober trotzdem aus.
Der Bericht identifiziert Anwendungen über ihre Entra-Anwendungs-ID statt über ihren Namen. Lösen Sie sie im Microsoft Entra Admin Center unter Entra ID → Enterprise-Apps auf; Microsoft veröffentlicht außerdem eine Liste der Anwendungs-IDs seiner eigenen Anwendungen. Rechnen Sie mit einigen, die zu Microsoft selbst gehören, und überspringen Sie sie nicht: Microsoft nimmt seine eigenen Anwendungen nicht aus, also braucht eine, die weiterhin auftaucht (meist ist es das klassische Outlook für Mac), ihre ID ebenfalls auf Ihrer Liste.
3. Wenn etwas EWS bis April 2027 behalten muss, setzen Sie es auf die Zulassungsliste
Set-OrganizationConfig -EwsAllowedAppIDs "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee,11111111-2222-3333-4444-555555555555"
# a day later, once the list has reached every server:
Set-OrganizationConfig -EwsEnabled $true
Schreiben Sie zuerst die Liste und warten Sie: Änderungen an der Liste brauchen etwa 24 Stunden, bis sie greifen, EWSEnabled etwa eine Stunde. Der Befehl ersetzt die gesamte Liste, nehmen Sie also auf, was bereits darauf steht. Eine Liste, die Sie selbst schreiben, wird nie überschrieben; eine, die Microsoft für Sie schreibt, stammt aus 60 Tagen Nutzung und erbt jeden blinden Fleck aus dem Punkt oben.
Es gibt hier zwei Mechanismen, und sie sind nicht austauschbar. EwsAllowList und EwsBlockList, gesteuert über EwsApplicationAccessPolicy, sind der ältere Mechanismus und prüfen den User-Agent-String des Clients. EwsAllowedAppIDs ist der neuere und prüft die Entra-Anwendungs-ID.
Der Abschaltungsprozess und der EWS-Nutzungsbericht arbeiten beide mit Anwendungs-IDs. Die meisten Suchergebnisse beschreiben noch den User-Agent-Mechanismus, weil er seit einem Jahrzehnt dokumentiert ist. Ihn zu konfigurieren, schützt Sie nicht vor der Änderung im Oktober, und er sieht konfiguriert aus, während er nichts bewirkt.
Stellen Sie dann Ihrem Signaturanbieter eine Frage
Wenn ein Signatur-Tool in Ihrem Nutzungsbericht auftaucht, ist die sinnvolle Frage nicht „Sind Sie bereit für die Abschaltung?“ – das bejahen alle. Sie lautet: Auf welchen Mechanismus stellen Sie um? Graph kann keine Signaturen verwalten, die ehrlichen Antworten sind also ein Office.js-Add-In, eine Nachrichtenflussregel oder ein ausgehendes Relay, jeweils mit den Kompromissen aus der Tabelle oben. Ein Anbieter, der „Wir migrieren zu Graph“ antwortet, ohne eine dieser Optionen zu nennen, hat die Frage nicht beantwortet.
Wenn Sie Google Workspace nutzen
Nichts davon gilt für Sie. EWS ist ein Exchange-Protokoll; Google Workspace ist von der Abschaltung überhaupt nicht betroffen. Die eigenen Grenzen von Google sind real, aber völlig anders gelagert, und die Gmail API unterstützt die Signaturverwaltung direkt als serverseitige Profileigenschaft – die ohne Installation auf Mobilgeräten ankommt. Das haben wir separat beschrieben.