Microsoft 365 | Mailkontakte vs. Gastbenutzer

Externe Partner tauchen in jedem Microsoft-365-Tenant auf: Lieferanten, Dienstleister, Kunden, Projektpartner. Die Frage ist nicht ob, sondern wie Du sie einbindest. Microsoft 365 bietet dafür drei Stufen: Mailkontakte für reine E-Mail-Kommunikation, Gastbenutzer über Entra B2B Collaboration für echte Zusammenarbeit und Cross-Tenant-Funktionen für die enge Kopplung ganzer Organisationen.

Jede Stufe bringt eigene Objekttypen, eigene Verwaltungswege und seit Januar 2026 auch eigene Kostenfragen mit. Welche Variante Du wählst, entscheidet über Adressbuch-Sichtbarkeit, Zugriffsrechte, Lebenszyklus und Auditierbarkeit Deiner externen Identitäten.

Ein Mailkontakt ist ein reines Verzeichnisobjekt in Exchange Online (RecipientTypeDetails: MailContact). Er repräsentiert eine externe SMTP-Adresse im globalen Adressbuch (GAL), damit Deine Anwender externe Empfänger per Autovervollständigung finden und Verteilergruppen externe Adressen aufnehmen können. Anmelden kann sich ein Mailkontakt nirgends, weil ihm keine Identität in Entra ID zugeordnet ist: kein Konto, kein Token, kein Zugriff auf Teams, SharePoint oder OneDrive.

Genau darin liegt der Vorteil. Ein Mailkontakt erzeugt keine Angriffsfläche, braucht keine Conditional-Access-Betrachtung und keine Access Reviews. Du pflegst ihn im Exchange Admin Center oder per Set-MailContact. In Hybrid-Umgebungen gilt: Wird der Kontakt aus dem lokalen Active Directory synchronisiert, musst Du ihn auch dort pflegen, weil Änderungen an synchronisierten Objekten in der Cloud gesperrt sind.

Ein Gastbenutzer entsteht über Entra B2B Collaboration: Du lädst eine externe Person ein, Entra ID legt ein Benutzerobjekt mit UserType Guest an, und die Person meldet sich mit den Anmeldedaten ihrer Heimat-Organisation an. Fehlt dort ein Entra-Konto, greift die Einlösung über ein Microsoft-Konto oder den E-Mail-Einmalpasscode. Dadurch bekommt der Gast eine richtliniensteuerbare Identität in Deinem Tenant, auf die Conditional Access, MFA-Anforderungen und Berechtigungen wirken.

Im Hintergrund legt Exchange Online für jeden Gast einen speziellen Mail User mit dem RecipientTypeDetails GuestMailUser an. Dieses Objekt ermöglicht:

Das Objekt existiert so lange, wie das zugehörige Gastkonto in Entra ID besteht. Identitätseigenschaften änderst Du über das Entra Admin Center oder Microsoft Graph, Exchange-spezifische Eigenschaften wie die GAL-Sichtbarkeit über Set-MailUser.

Standardmäßig steht das Attribut HiddenFromAddressListsEnabled bei Gästen auf True. Microsoft blendet Gäste aus, damit externe Identitäten nicht ungewollt in der internen Suche und Autovervollständigung auftauchen. Eine Tenant-weite Voreinstellung, die neue Gäste automatisch sichtbar macht, existiert bis heute nicht: Wer Gäste in der GAL braucht, setzt das Attribut pro Objekt oder per wiederkehrendem Skript.

Seit Einführung des Sponsors-Attributs speichert Entra ID beim Einladen automatisch den Einladenden als Sponsor. Bis zu fünf Sponsoren pro Gast sind möglich, als Personen oder Gruppen. Der Sponsor hat keine Admin-Rechte, dient aber als dokumentierter Verantwortlicher für Access Reviews und Genehmigungen im Entitlement Management. Für die spätere Bereinigung verwaister Gäste ist das Gold wert, weil Du endlich weißt, wen Du fragen musst.

Arbeiten zwei Organisationen mit eigenen Entra-Tenants dauerhaft zusammen, stoßen manuelle Gasteinladungen an Grenzen. Dafür gibt es drei Funktionsstufen, die alle über die Cross-Tenant Access Settings gesteuert werden.

B2B Direct Connect stellt eine gegenseitige Vertrauensstellung zwischen zwei Tenants her, ohne dass im Ressourcen-Tenant Benutzerobjekte entstehen. Der Anwendungsfall ist in der Praxis auf Teams Shared Channels beschränkt: Externe arbeiten im freigegebenen Kanal mit, ohne den Tenant zu wechseln und ohne als Gast im Verzeichnis zu erscheinen. Standardmäßig ist Direct Connect für alle externen Organisationen blockiert, eingehend wie ausgehend. Du musst jede Partnerorganisation explizit freischalten. B2B Collaboration ist dagegen standardmäßig für alle Entra-Organisationen offen, was Du über die Default-Einstellungen einschränken kannst.

Die Cross-Tenant-Synchronisation automatisiert das Anlegen, Aktualisieren und Löschen von B2B-Benutzern zwischen Tenants derselben Organisation. Der Quell-Tenant pusht die Benutzer über die Entra-Provisioning-Engine in den Ziel-Tenant, das Synchronisationsintervall liegt derzeit fest bei 40 Minuten. Verlässt ein Mitarbeiter die Firma, verschwindet sein B2B-Konto im Partner-Tenant automatisch mit, wodurch das klassische Karteileichen-Problem manueller Einladungen entfällt. Die synchronisierten Konten lassen sich als Member statt Guest anlegen, was für Microsoft-365-Funktionen wie die People-Suche relevant ist. Voraussetzung ist mindestens Entra ID P1.

Die Multitenant Organization in Entra ID und Microsoft 365 definiert eine formale Grenze um die Tenants eines Konzerns in Form einer Tenant-Gruppe. Sie baut auf der Cross-Tenant-Synchronisation auf und ergänzt die mandantenübergreifende People-Suche sowie verbesserte Teams-Funktionen: Benachrichtigungen, Chats und Meetings über alle Konzern-Tenants hinweg im aktuellen Teams-Client. Für Fusionen, Konzernstrukturen und Carve-outs ist das der Zielzustand. Für die Zusammenarbeit mit fremden Firmen bleibt es bei B2B Collaboration oder Direct Connect.

Brauchen Deine externen Partner nur E-Mail-Kommunikation, genügt der Mailkontakt, weil jedes weitere Objekt Verwaltungs- und Sicherheitsaufwand ohne Nutzen erzeugt. Sobald Dokumente, Kalender, Chats oder Teams-Mitgliedschaften ins Spiel kommen, führt kein Weg am Gastbenutzer vorbei, weil nur er eine steuerbare Identität mitbringt. Für dauerhafte Organisationskopplungen lohnt der Blick auf Cross-Tenant-Synchronisation oder Shared Channels, weil manuelle Einladungen ab wenigen Dutzend Benutzern weder skalieren noch sauber rückgebaut werden.

Gäste sind in der GAL standardmäßig ausgeblendet, Mailkontakte standardmäßig sichtbar. Willst Du Gäste gezielt anzeigen, setzt Du HiddenFromAddressListsEnabled auf False. Die Änderung braucht bis zu 24 Stunden, bis das Offline Address Book (OAB) neu generiert ist. Umgekehrt kannst Du Mailkontakte und Postfächer jederzeit ausblenden, etwa Servicekonten oder Postfächer ausgeschiedener Mitarbeiter in der Übergangsphase.

Ein Dauerbrenner im Support: Für dieselbe externe Person existieren Mailkontakt und Gastbenutzer parallel. Beide Objekte beanspruchen dieselbe SMTP-Adresse, was zu Proxy-Adress-Konflikten, fehlgeschlagenen Zustellungen an den Gast und Synchronisierungsfehlern mit Entra Connect führt. Entscheide deshalb pro Partner früh, welcher Objekttyp gilt, und räume Altbestände auf, bevor Du Gäste einlädst. Prüfen kannst Du Bestandsobjekte schnell per Get-EXORecipient gegen die externe Adresse.

Der eigentliche Vorsprung der Gastkonten liegt im Lebenszyklus. Mit Entra ID Governance richtest Du Access Reviews ein, die Gruppenbesitzer oder Sponsoren regelmäßig über den Verbleib von Gästen entscheiden lassen. Lifecycle Workflows deaktivieren inaktive Gäste automatisch, und Entitlement Management bündelt Zugriffe in Access Packages mit Ablaufdatum. Ein Mailkontakt kennt nichts davon: Er ist ein statischer Adressbucheintrag ohne Anmeldedaten und ohne Aktivitätshistorie.

Seit dem 30. Januar 2026 gibt es dabei eine Kostenfrage mit Ansage: Governance-Funktionen für Gäste (Entitlement Management, Lifecycle Workflows, seit Ende März 2026 auch Access Reviews) setzen ein verknüpftes Azure-Abonnement mit dem Add-on Microsoft Entra ID Governance for Guests voraus. Ohne Verknüpfung blockiert Entra das Anlegen und Ändern gastbezogener Richtlinien (Message Center MC1225192). Abgerechnet wird pro Gast und Monat nur dann, wenn der Gast eine kostenpflichtige Governance-Aktion auslöst.

Gastzugriff steuerst Du auf zwei Ebenen. Die External Collaboration Settings legen fest, wer Gäste einladen darf, welche Domains zugelassen oder blockiert sind und wie viel ein Gast im Verzeichnis sehen darf. Die Cross-Tenant Access Settings regeln pro Partnerorganisation den ein- und ausgehenden Zugriff und ob Du MFA- und Gerätestatus-Claims aus dem Heimat-Tenant des Gasts akzeptierst (Trust Settings). Damit entfällt die doppelte MFA-Registrierung für Gäste, ohne die Anforderung selbst aufzugeben. Conditional Access setzt darauf auf: eigene Richtlinien für Gäste, etwa MFA-Pflicht, Sitzungsbeschränkungen oder die Blockade riskanter Anmeldungen. Bei Mailkontakten entfällt diese Ebene komplett, weil es keine Anmeldung gibt.

Gastkonten selbst kosten keine Lizenz. Nutzen Gäste aber Premium-Funktionen wie Conditional Access, greift das MAU-Modell von Entra External ID: Die ersten 50.000 monatlich aktiven externen Benutzer sind kostenlos, darüber fällt ein kleiner Betrag pro aktivem Gast an. Dafür muss der Tenant mit einem Azure-Abonnement verknüpft sein. SMS-basierte MFA wird pro Versuch separat berechnet, was für die Authenticator-App als Gast-MFA-Methode spricht.

Teste die gewählte Methode als Pilot, bevor Du sie zum Standard erklärst. Lade fünf externe Partner als Gäste ein, richte ein dediziertes Team ein (etwa "Externes Pilotprojekt") und stelle in der zugehörigen SharePoint-Bibliothek echte Projektdokumente mit gezielten Zugriffsbeschränkungen bereit. Prüfe, ob Einladung und Einlösung reibungslos laufen, ob Conditional Access wie geplant greift und ob zeitlich begrenzte Zugriffe über ein Access Package mit Ablaufdatum sauber auslaufen. Falls Deine Umgebung es erlaubt, richte dieselbe externe Person testweise einmal als Mailkontakt und einmal als Gast ein, allerdings mit unterschiedlichen Adressen, um den beschriebenen Proxy-Konflikt zu vermeiden.

In der Praxis fahren viele Organisationen zweigleisig: Partner mit reinem Mailverkehr bleiben Mailkontakte, Projektpartner werden Gäste, Konzern-Tenants koppeln sich per Synchronisation. Kläre die Spielregeln intern, bevor die erste Einladung rausgeht: Wer darf einladen, wer ist Sponsor, wann läuft ein Gast ab und wie schnell wird der Zugriff entzogen, wenn sich die Geschäftsbeziehung ändert. Eine kurze Live-Demo in Teams und SharePoint erklärt Deinen Anwendern den Unterschied zwischen den Varianten besser als jedes Wiki-Dokument.

Alle Exchange-Befehle setzen das Modul ExchangeOnlineManagement (v3) voraus, die Verzeichnisabfragen laufen über Microsoft Graph PowerShell. Die alten Module AzureAD und MSOnline sind seit 2025 abgeschaltet, Get-AzureADUser funktioniert nicht mehr. Alternativ zum Graph SDK kannst Du das Entra-PowerShell-Modul einsetzen, das mit Cmdlets wie Get-EntraUser und New-EntraInvitation die Migration alter Skripte erleichtert.

1. Gast-Mailuser-Objekte anzeigen

Standardmäßig ist das Attribut HiddenFromAddressListsEnabled auf True gesetzt.

2. Einzelnen Gast in der GAL sichtbar machen

Es kann bis zu 24 Stunden dauern, bis die Änderung im Offline Address Book (OAB) sichtbar wird.

3. Alle Gäste auf einmal sichtbar machen

4. Gast in eine Verteilergruppe aufnehmen

Da Guest Mail User routbare Objekte sind, kannst Du sie in Verteilergruppen aufnehmen:

5. Postfach ausblenden, einblenden und Status prüfen

6. Mailkontakt aus dem GAL ausblenden

7. Alle ausgeblendeten Empfänger auflisten (serverseitiger Filter)

Der serverseitige Filter ist in großen Tenants deutlich schneller als ein nachgelagertes Where-Object, weil Exchange Online nur die Treffer zurückliefert.

8. Synchronisierte Objekte im lokalen Active Directory

Das Attribut existiert nur, wenn das AD-Schema um die Exchange-Attribute erweitert wurde. Die Änderung erfolgt on-premises und wird per Entra Connect in die Cloud synchronisiert.

9. Gastbenutzer im Tenant auflisten (Microsoft Graph)

10. Gast per Microsoft Graph einladen

Für reine E-Mail-Beziehungen bleibt der Mailkontakt die richtige Wahl, weil er keine Identität, keine Angriffsfläche und keinen Governance-Aufwand erzeugt. Sobald externe Partner aktiv mitarbeiten sollen, führt der Weg über Gastbenutzer, weil nur sie eine Identität mitbringen, auf die Conditional Access, Access Reviews und Lifecycle Workflows wirken. Wer ganze Organisationen koppelt, automatisiert das mit der Cross-Tenant-Synchronisation oder verzichtet mit Shared Channels gleich auf Verzeichnisobjekte im eigenen Tenant.

Kritisch bleibt die Disziplin im Betrieb. Ein Gastkonto ist schnell eingeladen, aber ohne Ablaufdatum, Sponsor und regelmäßige Reviews sammelst Du binnen zwei Jahren hunderte Karteileichen mit aktiven Berechtigungen. Genau solche Konten tauchen in Audits nach ISO 27001 oder in NIS2-Nachweisen als Finding auf, weil niemand mehr belegen kann, warum der Zugriff besteht. Die Governance-Werkzeuge dafür liefert Microsoft mit, verlangt seit dem 30. Januar 2026 aber ein verknüpftes Azure-Abonnement und rechnet gastbezogene Governance-Aktionen im MAU-Modell ab. Kalkuliere das ein, bevor Du flächendeckend Access Reviews für tausende Gäste aufsetzt.

Technisch solltest Du zwei Punkte im Blick behalten: Doppelobjekte aus Mailkontakt plus Gastkonto für dieselbe Adresse verursachen Zustell- und Synchronisierungsfehler, und alle Skripte auf Basis von AzureAD- oder MSOnline-Cmdlets sind seit der Abschaltung 2025 tot. Migriere sie auf Microsoft Graph PowerShell oder das Entra-PowerShell-Modul. Danach steht der sauberen, nachweisbaren Zusammenarbeit mit externen Partnern nichts im Weg.