Cross-Tenant Message Recall in Exchange Online startet Mitte August 2026

Fremde Leute dürfen demnächst Mails aus euren Postfächern löschen. Freiwillig. Auf Knopfdruck eures Admins. Was nach einem schlechten Aprilscherz klingt, ist ein sauber gebautes Feature mit einem sehr scharfen Governance-Rand.

Executive Summary

Microsoft liefert eine Funktion aus, die seit rund fünfzehn Jahren auf jeder Wunschliste steht und die trotzdem niemand so richtig zu Ende gedacht hat: den tenantübergreifenden Nachrichtenrückruf. Unter MC1423106 und Roadmap-ID 561330 startet Cross-Tenant Message Recall Mitte August 2026 in die allgemeine Verfügbarkeit, abgeschlossen sein soll der Rollout Mitte September — weltweit, inklusive GCC, GCC High, DoD und der von 21Vianet betriebenen Umgebung. Ab dann kann ein Absender eine Mail nicht mehr nur im eigenen Tenant zurückholen, sondern auch aus einem fremden Microsoft-365-Tenant.

Die entscheidende Nachricht steckt aber nicht im Ob, sondern im Wer darf: Die Kontrolle liegt vollständig beim empfangenden Tenant. Die Funktion ist standardmäßig deaktiviert und wird nur wirksam, wenn dein Exchange-Admin sie per PowerShell aktiviert und die Microsoft-Entra-Tenant-ID des Absenders auf eine Allowlist setzt. Kein Schalter, kein Rückruf — der Absender kassiert dann eine freundliche Fehlermeldung und darf mit seinem Missgeschick weiterleben.

Klingt entspannt. Ist es auch, solange niemand aus Gefälligkeit gegenüber dem größten Kunden mal eben den Schalter umlegt. Denn was technisch passiert, ist kein höfliches „Bitte ignorier die Mail“, sondern ein Hard Delete in einem Postfach deiner Organisation, ausgelöst von jemandem, der nicht bei dir angestellt ist und dem gegenüber du keinerlei Weisungsrecht hast. Für Legal, Compliance und Records Management ist das keine Feature-Ankündigung, sondern eine Grundsatzfrage. Beantworte sie, bevor sie jemand anders für dich beantwortet.

Worum geht es im Detail?

Kurzer Rückblick, sonst versteht man die Tragweite nicht. Der alte Outlook-Rückruf war jahrzehntelang ein Ritual ohne Wirkung: Der Client schickte eine zweite Mail hinterher und bat den Client des Empfängers höflich, die erste zu entsorgen. Das klappte, wenn der Mond richtig stand, der Empfänger Outlook im Cached Mode nutzte, die Mail noch ungelesen war und niemand eine Regel definiert hatte. In der Praxis war die verlässlichste Wirkung des Rückrufs, dass der Empfänger die ursprüngliche Mail erst dadurch überhaupt bemerkte.

Seit Anfang 2023 macht Exchange Online das anders. Beim Cloud-based Message Recall fängt ein Transport-Agent die Rückruf-Nachricht ab — sie hat die Nachrichtenklasse IPM.Outlook.Recall und den Betreff „Recall: Originalbetreff“ — und löscht die Originalnachricht serverseitig aus den Postfächern. Kein Client muss mitspielen, kein Update ist nötig. Microsoft beziffert die Erfolgsquote auf rund 90 Prozent. Der Rückruf ist damit vom Placebo zur echten Löschoperation geworden — und das ist genau der Punkt, an dem man aufhören sollte, ihn als Bedienkomfort zu betrachten.

Abbildung 1: Wie aus einer folgenlosen Höflichkeitsfloskel eine Fernlöschung über Organisationsgrenzen hinweg wurde.

Was dabei mit der Mail passiert, ist wenig zimperlich. Der Agent löscht sie hart — sie landet in den Recoverable Items unter Purges und ist nach Ablauf der Deleted-Item-Retention, standardmäßig 14 Tage, endgültig verschwunden. Der Dienst probiert es bis zu 24 Stunden lang. Der Absender bekommt anschließend einen Recall-Report zugestellt, und zwar von der Adresse Office365Reports@microsoft.com — wenn dein Spamfilter die blockt, wunderst du dich später, warum niemand Statusmeldungen bekommt.

Im Message Trace taucht die Rückruf-Nachricht mit dem Status Failed auf. Das ist kein Fehler, sondern normal: Der Transport verwirft die Recall-Nachricht, sobald sie ihren Zweck erfüllt hat. Erst im Detail des Drop-Ereignisses steht, ob der Rückruf tatsächlich erfolgreich war. Wer also nachvollziehen will, was in seinen Postfächern gelöscht wurde, muss zwei Ebenen tief graben. Ein Dashboard gibt es nicht.

Und jetzt kommt die Tenant-Grenze weg

Genau dieses Verfahren öffnet Microsoft nun über Organisationsgrenzen hinweg. Sendet jemand aus Tenant A eine Mail in Tenant B und ruft sie zurück, fragt Exchange Online beim Zieltenant nach, ob der Rückruf dort ausgeführt werden darf. Zwei Bedingungen müssen erfüllt sein, und zwar beide: Der empfangende Tenant hat die Funktion aktiviert, und die Entra-Tenant-ID des Absenders steht auf seiner Allowlist. Fehlt eines von beidem, scheitert der Rückruf und der Absender erhält einen Report mit dem Hinweis, dass ein Rückruf über Organisationsgrenzen hier nicht erlaubt ist.

Abbildung 2: Der komplette Pfad einer tenantübergreifenden Rückruf-Anforderung — und die zwei Bedingungen, an denen sie im Normalfall scheitert.

Ist beides gegeben, verhält sich der externe Rückruf exakt wie ein interner. Genau das ist die Pointe: Der Empfänger sieht keinen Unterschied zwischen „Kollege aus dem dritten Stock hat sich vertan“ und „eine fremde Rechtsabteilung hat gerade Beweismaterial aus meinem Postfach entfernt“. Auf der Client-Seite ändert sich übrigens nichts — alles wird im Dienst verarbeitet, es gibt kein Outlook-Update, auf das du warten müsstest.

Administriert wird das über zwei neue Cmdlets in Exchange Online PowerShell. Ein Hinweis für die Praxis: In Version 3.10 des Moduls ExchangeOnlineManagement sind sie noch nicht enthalten. Wenn dein Skript mit „Befehl nicht gefunden“ abbricht, liegt es wahrscheinlich nicht an fehlenden Rechten, sondern an einem zu alten Modul.

Mehr ist es nicht. Genau das ist das Problem — vier Zeilen trennen euch von einem Fremdzugriff auf jedes Postfach der Organisation.

Abbildung 3: Die relevanten Parameter im Überblick. Die vier oberen gelten in eurem Tenant schon heute — erfahrungsgemäß hat sie nur nie jemand angesehen.

Was sind Chancen? Was sind Risiken?

Fangen wir mit dem an, was hier tatsächlich gut ist — und das ist nicht wenig. Der Fehlversand an einen externen Empfänger ist der Klassiker unter den selbstverschuldeten Datenschutzvorfällen. Die Angebotskalkulation an den Wettbewerber statt an den Kunden, weil Outlook die Adresse freundlich vervollständigt hat. Die Gehaltsliste im Anhang, weil jemand die falsche Datei gegriffen hat. Der Verteiler mit 300 Klarnamen im An-Feld statt im BCC. Bislang endete das in einem Telefonat, in dem man einen Fremden bittet, doch bitte etwas zu löschen, und danach hofft.

Mit einer belastbaren Partnerbeziehung wird daraus ein technischer Vorgang mit dokumentiertem Ergebnis. In Szenarien mit intensiver, vertrauensvoller Zusammenarbeit — Konzernverbund mit mehreren Tenants, Joint Venture, ausgelagerte Fachabteilung, ein Steuerberater mit Dauermandat — ist das ein echter Gewinn. Besonders wertvoll wird es bei Multi-Tenant-Konstrukten nach einer Übernahme, wo Kollegen formal in zwei Organisationen sitzen und ein Fehlversand technisch extern, faktisch aber intern ist.

Und jetzt die andere Seite. Was hier eingebaut wird, ist ein Fernlöschrecht für Dritte an Datenbeständen, für die du verantwortlich bist. Wer eine Mail bekommt, hat sie bekommen — das ist ein Fakt, und in vielen Branchen ist dieser Fakt Beweismittel. In Bauprojekten entscheidet die Mail mit dem Änderungswunsch über Nachtragsforderungen. In der Beratung entscheidet die Freigabemail darüber, wer eine Fehlentscheidung zu verantworten hat. Ein Lieferant, der eine unbedachte Zusage zurücknehmen möchte, hat plötzlich ein technisches Werkzeug dafür — wenn du ihn gelassen hast.

Erschwerend kommt die dünne Nachweislage hinzu. Auf die Frage, ob Rückrufe im Postfach-Audit-Log auftauchen, antwortet Microsoft in der eigenen FAQ mit einem schlichten Nein, derzeit nicht. Die einzige Spur führt über den Message Trace und dort über das Detail eines Drop-Ereignisses. Message-Trace-Daten sind kein Langzeitarchiv. Wer erst nach Monaten merkt, dass ihm etwas fehlt, findet keinen Beleg mehr dafür, dass überhaupt etwas gefehlt hat.

Der wahrscheinlichste Angriffsvektor ist übrigens nicht technisch, sondern organisatorisch. Die Tenant-ID selbst lässt sich nicht fälschen. Aber der Prozess davor lässt sich manipulieren: Eine gut gemachte Mail an den Service Desk, angeblich vom langjährigen Dienstleister, mit der Bitte, „unsere neue Tenant-ID für den Rückruf zu hinterlegen“ — und schon steht eine fremde GUID auf eurer Allowlist. Wenn dann noch MessageRecallAlertRecipientsEnabled abgeschaltet ist, merkt der Empfänger nicht einmal, dass ihm etwas abhandengekommen ist. Das ist keine Science-Fiction, das ist ein Standard-Pretexting-Szenario mit einem neuen, sehr lohnenden Ziel.

Was müssen wir jetzt schon vorbereiten?

Die gute Nachricht: Nichtstun ist eine valide Zwischenposition, weil der Auslieferungszustand „aus“ ist. Die schlechte: Nichtstun ist keine valide Endposition, weil im Zweifel derjenige entscheidet, der zuerst gefragt wird — und das ist meistens jemand, der weder die Aufbewahrungspflichten noch die Vertragslage kennt.

Position schriftlich festlegen. Bevor die erste Anfrage kommt, gehört eine Entscheidung ins Governance-Dokument: Bleibt Cross-Tenant Recall generell aus, oder gibt es einen definierten Ausnahmeprozess? Beides ist vertretbar. Keine Antwort zu haben ist es nicht.

Den Ist-Stand erheben. Prüfe MessageRecallEnabled, RecallReadMessagesEnabled, MessageRecallMaxRecallableAge und die Empfänger-Benachrichtigungen. Bei den meisten Kunden, die ich sehe, steht überall der Default. Interne Rückrufe gelesener Mails sind damit seit Jahren möglich, ohne dass es je jemand entschieden hätte.

Aufbewahrung vor Öffnung. Retention-Policies und, wo nötig, Holds müssen vor einer Freischaltung stehen. Sonst ist die 14-Tage-Frist der Recoverable Items dein einziges Sicherheitsnetz — und das ist bei einem Streitfall, der nach acht Monaten aufkommt, keins.

Empfänger-Benachrichtigung anlassen. Wenn du freischaltest, dann bitte transparent. Ein Nutzer, der nicht erfährt, dass ihm etwas aus dem Postfach genommen wurde, kann auch nicht widersprechen. Das ist arbeitsrechtlich und datenschutzrechtlich der deutlich unangenehmere Zustand.

Freigabeprozess für die Allowlist bauen. Antrag mit Begründung, Freigabe durch Legal und den fachlich Verantwortlichen, Vier-Augen-Prinzip beim Eintragen, verpflichtendes Review-Datum. Eine Allowlist ohne Ablaufdatum verrottet, das ist ein Naturgesetz.

Tenant-IDs über einen zweiten Kanal verifizieren. Niemals aus der Mail übernehmen, in der sie steht. Telefonisch bestätigen lassen, bei einem bekannten Ansprechpartner, unter einer Nummer aus eurem CRM — nicht unter der aus der Signatur.

Vertragliche Flanke schließen. Wer einem Partner ein Löschrecht in den eigenen Postfächern einräumt, sollte das in NDA, Rahmenvertrag oder Auftragsverarbeitungsvertrag abbilden. Spätestens der nächste Auditor fragt danach.

Werkzeug aktualisieren und überwachen. Aktuelles ExchangeOnlineManagement-Modul bereitstellen, die Allowlist regelmäßig auslesen und gegen den Soll-Stand diffen, Abweichungen alarmieren. Ein wiederkehrender Report auf Get-CrossTenantRecallConfiguration kostet zehn Minuten Aufwand und erspart eine sehr unangenehme Diskussion.

Und wenn dich jemand fragt, ob ihr das jetzt einschalten solltet: Die ehrliche Antwort lautet „Vielleicht, für genau diese drei Partner, nach Freigabe durch Legal, mit Review in sechs Monaten“. Das ist keine besonders sexy Antwort. Sie ist nur die einzige, die in zwei Jahren vor einem Auditor noch trägt.

Häufig gestellte Fragen

Kann jetzt jeder externe Absender Mails aus unseren Postfächern löschen?

Nein. Cross-Tenant Message Recall ist standardmäßig deaktiviert und muss vom empfangenden Tenant ausdrücklich freigeschaltet werden. Zusätzlich muss die Microsoft-Entra-Tenant-ID des Absenders auf einer Allowlist stehen — ohne beides scheitert jede externe Rückruf-Anforderung.

Werden auch bereits gelesene Nachrichten zurückgerufen?

Ja. Der Hinweis im Outlook-Dialog, dass nur ungelesene Nachrichten betroffen sind, ist seit dem Umstieg auf den serverseitigen Rückruf nicht mehr korrekt. Gesteuert wird das über den Organisationsparameter RecallReadMessagesEnabled, dessen Standardwert einem aktivierten Zustand entspricht.

Ist eine zurückgerufene Mail endgültig weg?

Sie wird hart gelöscht und landet im Ordner Purges der Recoverable Items, wo sie standardmäßig 14 Tage überlebt. Liegt auf dem Postfach ein Litigation Hold oder In-Place Hold, bleibt die Nachricht darüber hinaus für eDiscovery auffindbar.

Wie sehen wir, ob und wann ein Rückruf stattgefunden hat?

Im Postfach-Audit-Log erscheinen Rückrufe derzeit nicht. Nachvollziehbar ist der Vorgang nur über den Message Trace, wo die Rückruf-Nachricht mit Status Failed auftaucht und erst das Detail des Drop-Ereignisses verrät, ob die Löschung erfolgreich war.

Funktioniert der Rückruf auch gegenüber Gmail oder unserem On-Premises-Exchange?

Nein, die Funktion arbeitet ausschließlich zwischen Microsoft-365-Tenants. Mails an externe Provider oder an Postfächer in einer lokalen Exchange-Organisation — auch im Hybrid-Szenario — lassen sich weiterhin nicht zurückholen.