Die kurze Antwort vorweg: Outlook speichert gelöschte Nachrichten aus Shared Mailboxes standardmäßig im persönlichen Ordner „Gelöschte Elemente“ des angemeldeten Nutzers. Das wirkt unlogisch, erschwert die Nachverfolgung und kollidiert schnell mit Compliance-Anforderungen. Abhilfe schaffen zwei Stellschrauben: serverseitig aktivieren Sie in Exchange bzw. Exchange Online die Einstellung MessageCopyForDeleteEnabled, damit gelöschte Elemente in der Shared Mailbox landen.

Für ältere Outlook-Versionen steht zusätzlich der Registry-Schlüssel DelegateWastebasketStyle bereit, um das Verhalten auf dem Client auszurichten. So bleibt nachvollziehbar, aus welchem Postfach eine Nachricht stammt und wer sie entfernt hat. Wir zeigen die Hintergründe, typische Fehlerbilder wie doppelte Ablagen oder widersprüchliche Konfigurationen und führen Sie Schritt für Schritt durch Aktivierung und Prüfung – inklusive Empfehlungen für die Dokumentation in Ihren IT-Richtlinien.
Inhalt
- Standardverhalten verstehen: persönliche „Gelöschte Elemente“, Shared Mailbox und die Folgen für Compliance
- Konfiguration Schritt für Schritt: MessageCopyForDeleteEnabled serverseitig und DelegateWastebasketStyle clientseitig
- Ziel der Konfiguration
- Serverseitig in Exchange Online/Exchange: MessageCopyForDeletedItemsEnabled aktivieren
- Clientseitig für ältere Outlook‑Windows‑Versionen: DelegateWastebasketStyle
- Kompatibilität und empfohlene Zuständigkeiten
- Typische Fehlerbilder und Abhilfe
- Schritt-für-Schritt-Checkliste: Aktivierung und Verifizierung
- Fehlerbilder, Verifizierung und Richtlinien: doppelte Ablagen vermeiden, Tests durchführen, Vorgaben festhalten
Wenn eine Nachricht aus einer Shared Mailbox in Outlook gelöscht wird, landet sie standardmäßig im persönlichen Ordner „Gelöschte Elemente“ der löschenden Person – und nicht im Ordner „Gelöschte Elemente“ der Shared Mailbox. Dieses Verhalten stammt aus der Delegationslogik älterer Outlook-Generationen und gilt weiterhin, wenn die Shared Mailbox als zusätzliches Postfach (Automapping/zusätzliches Postfach im Profil) eingebunden ist.
Wird die Shared Mailbox hingegen als separates Exchange-Konto im Outlook-Profil hinzugefügt, legt Outlook gelöschte Nachrichten in der Regel in den „Gelöschte Elemente“ der Shared Mailbox ab. In Outlook im Web (OWA) werden gelöschte Elemente einer geöffneten Shared Mailbox ebenfalls in deren „Gelöschte Elemente“ verschoben.
Für eine einheitliche, clientunabhängige Steuerung existiert serverseitig die Option MessageCopyForDeleteEnabled. Ist sie für die Shared Mailbox aktiviert, werden gelöschte Nachrichten in den Ordner „Gelöschte Elemente“ der Shared Mailbox abgelegt – unabhängig davon, von welchem unterstützten Client der Löschvorgang ausgelöst wurde.
In Umgebungen mit älteren Outlook-Versionen lässt sich das Verhalten clientseitig per Registrierungswert DelegateWastebasketStyle anpassen. Mit dem Wert 4 werden gelöschte Elemente aus gemeinsam genutzten Postfächern in deren eigenen Ordner „Gelöschte Elemente“ verschoben (statt in den persönlichen Papierkorb der löschenden Person). Diese Einstellung ist pro Benutzer-Client und lässt sich z. B. via Gruppenrichtlinie verteilen.
Warum das für Compliance und Nachvollziehbarkeit relevant ist
Liegt ein gelöschtes Team‑ oder Funktionspostfach‑Element im persönlichen „Gelöschte Elemente“ einer Person, entsteht eine Lücke in der gemeinsamen Aktenführung: Teammitglieder finden den Vorgang nicht mehr in der Shared Mailbox, und Aufbewahrungs- oder Löschrichtlinien, die nur für die Shared Mailbox gelten, greifen auf diese Kopie nicht.
Das erschwert eDiscovery, interne Kontrollen und Audits. Zwar ist die Mailbox-Auditierung in Exchange Online standardmäßig aktiv, doch für Recherchen in der Shared Mailbox fehlen die gelöschten Inhalte, wenn sie im persönlichen Postfach liegen. Zentral gesteuerte Ablage der gelöschten Elemente in der Shared Mailbox sorgt dafür, dass Aufbewahrung (z. B. Microsoft Purview-Richtlinien), Wiederherstellung und Nachverfolgung konsistent an einem Ort erfolgen.
Je nach Zugriffsart: so verteilt Outlook gelöschte Elemente
| Szenario | Standardzielordner | Bemerkung |
|---|---|---|
| Outlook für Windows, Shared Mailbox als zusätzliches Postfach (Automapping/zusätzliches Postfach) | Persönlicher „Gelöschte Elemente“ der löschenden Person | Historisches Default-Verhalten bei Delegation. |
| Outlook für Windows, Shared Mailbox als separates Exchange-Konto im Profil | „Gelöschte Elemente“ der Shared Mailbox | Trennung nach Absenderkonto; häufig gewünschtes Verhalten ohne zusätzliche Einstellungen. |
| Outlook im Web (OWA), Shared Mailbox geöffnet | „Gelöschte Elemente“ der Shared Mailbox | Löschvorgang bezieht sich auf die gerade verwendete Mailbox. |
| Serverseitig: MessageCopyForDeleteEnabled aktiviert | „Gelöschte Elemente“ der Shared Mailbox | Clientunabhängig konsistent; zentrale Steuerung in Exchange Online/Exchange Server. |
| Clientseitig: DelegateWastebasketStyle=4 (älteres Outlook für Windows) | „Gelöschte Elemente“ der Shared Mailbox | Wirkt pro Client/Benutzerprofil; kann per GPO verteilt werden. |
Typische Fehlerbilder in der Praxis
Ohne abgestimmte Konfiguration treten wiederkehrende Probleme auf, die die Nachvollziehbarkeit beeinträchtigen und Supportaufwände erzeugen.
- Gelöschte Mails „verschwinden“ aus der Shared Mailbox, weil sie im persönlichen Papierkorb einzelner Personen landen und dort von Aufbewahrungsregeln abweichen.
- Inkonsistente Ablage: Ein Teil des Teams löscht über Outlook im Web (Papierkorb der Shared Mailbox), ein anderer Teil über Outlook für Windows mit Standardverhalten (persönlicher Papierkorb).
- Parallel aktivierte Client- und Serversteuerung führt zu unerwarteten Ergebnissen, etwa Ablage in unterschiedlichen Papierkörben je nach Client oder Zeitpunkt.
- Automapping vs. separates Konto: Wechsel der Einbindungsart ändert unbemerkt das Löschziel und verfälscht Teamprotokolle.
- Nicht gecachte Shared-Folder in Outlook für Windows: Der Ordner „Gelöschte Elemente“ der Shared Mailbox wird lokal nicht synchronisiert und erscheint Anwenderinnen und Anwendern „leer“, obwohl serverseitig Einträge vorhanden sind.
Diese Muster lassen sich vermeiden, wenn die Organisation ein einheitliches Ziel für gelöschte Elemente vorgibt, die Einbindungsart der Shared Mailbox dokumentiert und die Wahl der Steuerung (serverseitig oder clientseitig) eindeutig festlegt.
Konfiguration Schritt für Schritt: MessageCopyForDeleteEnabled serverseitig und DelegateWastebasketStyle clientseitig
Ziel der Konfiguration
Standardmäßig landen aus einer freigegebenen Mailbox gelöschte Nachrichten im persönlichen Ordner „Gelöschte Elemente“ der Person, die löscht. Um Nachvollziehbarkeit herzustellen, soll das gelöschte Element im Ordner „Gelöschte Elemente“ der freigegebenen Mailbox erscheinen. Das wird serverseitig über die Mailbox-Einstellung MessageCopyForDeletedItemsEnabled erreicht. Für ältere Outlook‑Windows‑Clients ohne Unterstützung dieser Serverlogik wird zusätzlich der Registry‑Schlüssel DelegateWastebasketStyle eingesetzt.
Serverseitig in Exchange Online/Exchange: MessageCopyForDeletedItemsEnabled aktivieren
Die Einstellung wird pro freigegebener Mailbox gesetzt. Sie gilt für moderne Clients (Outlook im Web, neues Outlook für Windows, Outlook für Mac, mobile Outlook‑Apps) und für klassische Outlook‑Windows‑Versionen ab dem Zeitpunkt, an dem der Client die Serverregel respektiert.
- Voraussetzungen: Vollzugriff (FullAccess) auf die freigegebene Mailbox; Exchange Online PowerShell oder Exchange Management Shell (On‑Premises, aktuelle CU).
- Verbinden: In Exchange Online PowerShell mittels Connect-ExchangeOnline eine Sitzung herstellen.
- Aktivieren: Für die freigegebene Mailbox den Schalter setzen, beispielsweise: Set-Mailbox -Identity SharedMailbox@firma.tld -MessageCopyForDeletedItemsEnabled $true
- Prüfen: Get-Mailbox -Identity SharedMailbox@firma.tld | Format-List Name,MessageCopyForDeletedItemsEnabled
- Test: Eine Testmail in der freigegebenen Mailbox löschen. Erwartet: Die Nachricht erscheint im Ordner „Gelöschte Elemente“ der freigegebenen Mailbox; sie erscheint nicht im persönlichen „Gelöschte Elemente“ der löschenden Person.
Hinweis: SHIFT+ENTF (Hard Delete) umgeht „Gelöschte Elemente“ und verschiebt in „Wiederherstellbare Elemente“ der jeweiligen Mailbox. Für Nachverfolgung in Audit-Logs und Aufbewahrung gelten die jeweiligen Compliance‑Richtlinien unabhängig von dieser Einstellung.
Clientseitig für ältere Outlook‑Windows‑Versionen: DelegateWastebasketStyle
Falls der eingesetzte Outlook‑Windows‑Client das serverseitige Verhalten nicht nutzt, wird per Registry festgelegt, wohin gelöschte Elemente aus freigegebenen Postfächern verschoben werden.
- Outlook beenden.
- Registry‑Pfad: HKEY_CURRENT_USER\Software\Microsoft\Office\
\Outlook\Options\General - DWORD‑Wert anlegen oder ändern: DelegateWastebasketStyle
- Wert setzen: 4 (gelöschte Elemente in den Ordner „Gelöschte Elemente“ der freigegebenen Mailbox verschieben)
- Outlook starten und testen, indem eine Nachricht in der freigegebenen Mailbox gelöscht wird.
Verteilung in Unternehmen: Der Eintrag lässt sich per Gruppenrichtlinie (GPP Registry) oder Management‑Tool ausrollen. Für Click‑to‑Run‑Outlook mit fortlaufenden Updates sollte geprüft werden, ob die Servereinstellung bereits ausreicht, bevor der Registry‑Pfad dauerhaft erzwungen wird.
Kompatibilität und empfohlene Zuständigkeiten
| Client | Unterstützung serverseitig | Clientseitig nötig | Bemerkung |
|---|---|---|---|
| Outlook im Web (OWA) | Ja | Nein | Folgt der Mailbox‑Einstellung automatisch. |
| Neues Outlook für Windows (Monarch) | Ja | Nein | Keine Registry; Cloud‑Einstellung maßgeblich. |
| Outlook für Mac | Ja | Nein | Keine Registry; Serversteuerung. |
| Outlook für iOS/Android | Ja | Nein | App nutzt Serververhalten. |
| Outlook für Windows (Legacy) | Abhängig von Build | Teilweise | Falls kein volles Serververhalten: DelegateWastebasketStyle=4. |
Empfehlung: In gemischten Umgebungen zuerst serverseitig aktivieren und testen. Den Registry‑Schlüssel nur dort verteilen, wo die Clients erkennbar noch nicht der Serverlogik folgen.
Typische Fehlerbilder und Abhilfe
- Doppelte Ablage: Wenn Legacy‑Outlook per Registry nach „freigegeben“ verschiebt und der Server zusätzlich kopiert, können unerwartete Duplikate entstehen. Maßnahme: Entweder nur Servereinstellung nutzen oder Registry‑Wert entfernen.
- Falscher Ordner: Fehlt die Berechtigung „Vollzugriff“ oder wird über eine PST/POP‑Ansicht gearbeitet, landet das Element im persönlichen „Gelöschte Elemente“. Maßnahme: Zugriffskonzept prüfen und ausschließlich Exchange‑MAPI/EXO nutzen.
- Uneinheitliches Verhalten je Benutzer: Unterschiedliche Client‑Builds oder verteilte Registry‑Policies. Maßnahme: Standardisieren, Build‑Stand prüfen und Policies vereinheitlichen.
- Hard Delete wird nicht gesehen: Mit SHIFT+ENTF entfernte Mails sind nur über „Gelöschte Elemente wiederherstellen“/eDiscovery sichtbar. Maßnahme: Anwenderhinweis und ggf. Aufbewahrungsrichtlinien.
Schritt-für-Schritt-Checkliste: Aktivierung und Verifizierung
- Pro freigegebener Mailbox Set-Mailbox -MessageCopyForDeletedItemsEnabled $true ausführen.
- Per Get-Mailbox den Status kontrollieren.
- Client‑Matrix prüfen und entscheiden, ob DelegateWastebasketStyle nötig ist.
- Registry‑Wert (falls erforderlich) per Pilotgruppe ausrollen und testen.
- Funktionstest: Eine Mail in der freigegebenen Mailbox löschen, dann beide Ordner „Gelöschte Elemente“ (persönlich und freigegeben) prüfen.
- Audit/Compliance: Testlöschung protokollieren und Ergebnis dokumentieren, damit die Richtlinie nachvollziehbar ist.
- Richtlinie festhalten: Ort der Einstellung, verantwortliche Rolle, betroffene Mailboxen und Testdatum in die IT‑Dokumentation aufnehmen.
Fehlerbilder, Verifizierung und Richtlinien: doppelte Ablagen vermeiden, Tests durchführen, Vorgaben festhalten
Typische Fehlerbilder und ihre Ursachen
In der Praxis tauchen rund um gelöschte Nachrichten aus Shared Mailboxes wiederkehrende Auffälligkeiten auf. Diese Muster weisen fast immer auf eine Mischkonfiguration oder auf unterschiedliche Client-Verhalten hin.
Häufige Symptome:
- Uneinheitliche Ablage: In Outlook im Web (OWA) landen gelöschte Mails im Ordner „Gelöschte Elemente“ der Shared Mailbox, in Outlook für Windows hingegen im persönlichen „Gelöschte Elemente“ des Nutzers.
- Subjektiver „Datenverlust“: Teammitglieder finden gelöschte Mails nicht in der Shared Mailbox, weil sie in den persönlichen Ordner eines Kollegen verschoben wurden.
- Vermeintliche Dubletten: Einzelne Elemente scheinen doppelt aufzutauchen, wenn ein Teil des Teams mit OWA/Mac arbeitet (Ablage in der Shared Mailbox) und andere mit Outlook für Windows ohne angepasste Richtlinie (Ablage persönlich). Das sind keine echten Duplikate, sondern unterschiedliche Ablageorte derselben Aktion in verschiedenen Fällen.
- Widersprüchliche Ergebnisse bei Mischzugriffen: Wird eine Shared Mailbox sowohl als zusätzliches Postfach im Profil als auch als eigenes Konto eingebunden, können Löschaktionen je nach Zugriffspfad in unterschiedliche „Gelöschte Elemente“-Ordner laufen.
- „Unsichtbare“ Löschungen: Bei Hard Delete (Shift+Entf) landet die Nachricht nicht im Ordner „Gelöschte Elemente“, sondern im Wiederherstellungsbereich (Recoverable Items/„Gelöschte Elemente wiederherstellen“). Ohne Audit-Einsicht wirkt das wie ein Verschwinden.
Ursache ist meist das Zusammenspiel unterschiedlicher Clients: OWA und Outlook für Mac bewegen gelöschte Elemente aus Shared Mailboxes in der Regel in den Ordner der Shared Mailbox. Outlook für Windows nutzt standardmäßig den persönlichen Ordner „Gelöschte Elemente“, sofern nicht per Richtlinie/Registry anders vorgegeben. Mobile Clients (Outlook Mobile) richten sich an das Serververhalten und legen in der Shared Mailbox ab.
Verifizierung: zielgerichtete Tests statt Rätselraten
Vor Anpassungen lohnt sich ein kurzer, reproduzierbarer Testplan. So wird klar, welcher Client was tut und ob zusätzliche Faktoren (z. B. Hard Delete) hineinspielen.
- 1. Ausgangslage erfassen: Client-Versionen dokumentieren (Outlook für Windows Build, OWA, Outlook für Mac, Outlook Mobile) und wie die Shared Mailbox eingebunden ist (automapping/zusätzliches Postfach vs. eigenes Konto).
- 2. Testnachricht anlegen: In der Shared Mailbox einen eindeutig benannten Test-Thread erstellen.
- 3. Soft Delete prüfen: Nachricht normal löschen (Entf). Sofort in beiden Ordnern „Gelöschte Elemente“ prüfen: Shared Mailbox und persönliches Postfach. Ergebnis protokollieren.
- 4. Hard Delete prüfen: Nachricht mit Shift+Entf löschen. Über „Gelöschte Elemente wiederherstellen“ (Recoverable Items) verifizieren, dass der Eintrag dort geführt wird.
- 5. Audit sichten: In Microsoft Purview Audit nach den Aktionen „MoveToDeletedItems“ und „SoftDelete/HardDelete“ für die Shared Mailbox suchen, um Akteur, Client und Zeitstempel zu bestätigen.
- 6. Wiederholen je Client: Die Schritte 3–5 für OWA, Outlook für Windows und ggf. Mac/Mobile getrennt durchführen.
Für Outlook für Windows lässt sich das Verhalten clientseitig über den Registry-Wert DelegateWastebasketStyle steuern (Wert 4 = Ablage in der Shared Mailbox). Nach Änderung Outlook neu starten und die Schritte 3–6 erneut ausführen.
Erwartetes Verhalten nach Clienttyp (Schnellüberblick)
| Client | Standard-Ablage gelöschter Elemente | Mit Windows-Registry (DelegateWastebasketStyle=4) | Hinweise |
|---|---|---|---|
| Outlook im Web (OWA) | Shared Mailbox – „Gelöschte Elemente“ | Nicht anwendbar | Konsistent serverseitig, keine Client-Option nötig. |
| Outlook für Windows | Persönlicher Ordner „Gelöschte Elemente“ | Shared Mailbox – „Gelöschte Elemente“ | Nach Änderung Outlook neu starten; per Gruppenrichtlinie/Intune ausrollbar. |
| Outlook für Mac | Shared Mailbox – „Gelöschte Elemente“ | Nicht anwendbar | „Neues Outlook“ verhält sich servernah. |
| Outlook Mobile | Shared Mailbox – „Gelöschte Elemente“ | Nicht anwendbar | Cloudbasiert; orientiert sich am Serververhalten der Shared Mailbox. |
Richtlinien festlegen und kommunizieren
- Vorgabe zum Ablageort: Gelöschte Mails aus Shared Mailboxes müssen in der Shared Mailbox abgelegt werden. Für Outlook für Windows ist dazu DelegateWastebasketStyle=4 unter HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Options\General als REG_DWORD per Richtlinie zu setzen.
- Zulässige Clients/Versionen: Unterstützte Builds definieren und veröffentlichen; bei Abweichungen ist Support ausgeschlossen, bis aktualisiert wurde.
- Hard Delete untersagen: Shift+Entf ist für Shared Mailboxes nicht gestattet. Ergänzend Policies und Schulung bereitstellen; Auditing bleibt aktiv.
- Einbindung eindeutig regeln: Shared Mailbox entweder als zusätzliches Postfach oder als eigenes Konto im Profil verwenden, nicht beides parallel.
- Audit und Nachvollziehbarkeit: Purview-Audit ist dauerhaft aktiviert; Löschvorgänge werden regelmäßig stichprobenartig überprüft und dokumentiert.
- Änderungsmanagement: Jede Anpassung (Client, Richtlinie, Berechtigungen) wird mit Datum/Verantwortlichem festgehalten und nach Tests freigegeben.
Werden diese Punkte verbindlich dokumentiert und ausgerollt, verschwinden die typischen Inkonsistenzen. Gleichzeitig bleibt die Löschhistorie für Compliance und interne Nachverfolgung belastbar nachvollziehbar.
Meroth IT-Service ist Ihr lokaler IT-Dienstleister in Frankfurt am Main für kleine Unternehmen, Selbstständige und Privatkunden
Kostenfreie Ersteinschätzung Ihres Anliegens?
Werbung
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten
