Exchange Online: Architektur, Mailfluss und Betrieb

Exchange Online ist der von Microsoft betriebene Exchange-Dienst in Microsoft 365. Er stellt Postfächer, Kalender, Kontakte, Gruppen, SMTP-Transport und Verwaltungsfunktionen bereit. Der Tenant-Admin entscheidet über Empfänger, Domains, Konnektoren, Regeln, Berechtigungen und Aufbewahrung. Microsoft betreibt dagegen die Mailboxserver, Datenbankkopien, internen Queues, Patches und Failovervorgänge (Exchange Online service description, Exchange Online data resiliency).

Damit ähnelt Exchange Online fachlich einem eigenen Exchange-System, aber nicht betrieblich. Ein lokaler Admin kann eine Queue-Datei untersuchen oder eine Datenbankkopie aktivieren. In Exchange Online sieht er stattdessen die vom Dienst bereitgestellten Ereignisse, Zustände und Konfigurationsobjekte. Die wichtigste Fähigkeit ist deshalb, eine Benutzerbeschwerde auf einen klaren Pfad abzubilden: Identität, Clientzugriff, Empfängerobjekt, Transport, Filterung, Zustellung oder Aufbewahrung.

Vom Tenant zum Postfach

Der Tenant bildet den organisatorischen Rahmen. Darin verwaltet Exchange Online mailfähige Empfänger: Benutzer- und freigegebene Postfächer, Raum- und Gerätepostfächer, Verteiler, Microsoft-365-Gruppen, Kontakte und Mailbenutzer. Der Empfängertyp bestimmt, ob Daten gespeichert werden, wie Zustellung erfolgt und welche Berechtigungen verfügbar sind (Recipients in Exchange Online).

Ein Benutzerkonto in Microsoft Entra ID und ein Exchange-Postfach hängen zusammen, sind aber nicht dasselbe Objekt. Die Lizenzierung kann die Bereitstellung eines Postfachs auslösen. Exchange ergänzt dann mailbezogene Attribute und Dienste. Entfernt ein Admin eine Lizenz oder löscht ein Konto, greifen verschiedene Aufbewahrungs- und Löschfristen. Für Betrieb und Offboarding müssen deshalb Identitätslebenszyklus, Postfachlebenszyklus und Compliance-Aufbewahrung gemeinsam geplant werden (Delete or restore user mailboxes, Retention policies for Exchange).

Für Experten wird die Herkunft der Attribute wichtig. In einem reinen Cloudtenant werden Exchange-Eigenschaften online verwaltet. Bei synchronisierten Identitäten kann die lokale Umgebung weiterhin die massgebliche Quelle für bestimmte Empfängerattribute sein. Dann erscheint ein Wert zwar in Exchange Online, muss aber lokal geändert und erneut synchronisiert werden. Dieses Modell gehört in den Artikel Exchange Hybrid, weil es ohne Verzeichnissynchronisation nicht existiert.

Wie eine eingehende Nachricht das Postfach erreicht

Nachdem der Empfänger verstanden ist, lässt sich der Mailweg verfolgen. Der öffentliche MX einer Domain zeigt normalerweise auf Exchange Online Protection, EOP. EOP nimmt die SMTP-Verbindung an, bewertet Absender und Nachricht, wendet Schutz- und Transportregeln an und übergibt eine zugelassene Nachricht an Exchange Online. Für lokale Empfänger folgt anschliessend die Zustellung in das Postfach (Exchange Online Protection overview, Mail flow in EOP).

Die Accepted Domain legt fest, wie Exchange Online die Empfängerdomain behandelt. Bei Authoritative erwartet der Dienst alle gültigen Empfänger in der eigenen Organisation und weist unbekannte Adressen ab. Internal Relay erlaubt, unbekannte Empfänger an ein anderes System weiterzuleiten. Diese Einstellung ist nur dann sinnvoll, wenn der nächste Hop und die Empfängerauflösung zuverlässig geplant sind; sonst entstehen Unzustellbarkeiten oder Schleifen (Manage accepted domains in Exchange Online).

Eine interne Nachricht bleibt nicht automatisch «im selben Server». Exchange Online löst Absender und Empfänger auf, prüft Regeln und Schutzrichtlinien und schreibt Transportereignisse. Für den Admin ist diese Ereigniskette entscheidend: Delivered bedeutet, dass der Dienst an sein Ziel zugestellt hat; Filtered, Failed, Pending oder Expanded beschreiben andere Schritte. Message Trace macht diese Schritte sichtbar, ersetzt aber nicht die Prüfung des Zielpostfachs oder einer nachgelagerten Regel (Trace an email message, Message Trace FAQ).

Ausgehende Nachrichten und Konnektoren

Bei ausgehenden Nachrichten wird zuerst entschieden, ob Exchange Online direkt zum Zielsystem sendet oder einen konfigurierten Outbound Connector verwendet. Ein Connector kann Nachrichten zur eigenen Infrastruktur, zu einem Partner oder zu einem Mail-Gateway leiten. Die Auswahl beruht unter anderem auf Empfängerdomain, Connectorbedingungen und Transportregeln (Set up connectors to route mail).

Inbound Connectors beschreiben im Gegenzug, unter welchen Bedingungen Exchange Online einem sendenden System vertraut. Typische Kriterien sind die Quell-IP oder ein TLS-Zertifikat. Diese Angaben sind sicherheitsrelevant: Ein zu grosser IP-Bereich oder ein ungenau geprüftes Zertifikat kann fremden Verkehr wie internen Partnerverkehr aussehen lassen.

Steht ein externes Mail-Gateway vor EOP, sieht Microsoft zunächst die IP des Gateways. Enhanced Filtering for Connectors kann Informationen über den ursprünglichen Hop in die Filterbewertung einbeziehen. Die Funktion ist kein allgemeiner «Spamfilter-Schalter», sondern muss zum tatsächlichen Pfad, zu den Connectoren und zu den übersprungenen IPs passen (Enhanced Filtering for Connectors).

Die Expertenfrage lautet hier: Welche Gegenstelle hat eine Nachricht wirklich angenommen, welche Identität wurde für den Connector geprüft und an welchem Hop fand die letzte inhaltliche Filterung statt? Diese drei Antworten gehören in jedes Mailflowdiagramm.

Technischer Aufbau aus Adminsicht

Exchange Online veröffentlicht keine Serverliste, die ein Tenant-Admin wie eine lokale Farm verwaltet. Trotzdem besitzt der Dienst klar erkennbare technische Bausteine. Sie werden über Protokolle und Verwaltungsoberflächen sichtbar.

Der Technologiestack am Rand besteht damit vor allem aus SMTP und TLS für Mailtransport sowie HTTPS, OAuth, PowerShell und REST für Client- und Verwaltungszugriff. Die internen Implementierungsdetails sind für den Kunden nur soweit relevant, wie Microsoft sie als Dienstverhalten, Limit oder Diagnoseoberfläche dokumentiert (About the Exchange Online PowerShell module, Microsoft Graph mail API).

Clientzugriff und moderne Authentisierung

Der Mailtransport endet im Postfach; Benutzer greifen anschliessend über Clientprotokolle darauf zu. Outlook, Outlook im Web, mobile Clients und Anwendungen verwenden HTTPS-basierte Endpunkte. Autodiscover hilft Clients, den passenden Dienst zu finden. Die Anmeldung läuft über Microsoft Entra ID, während Exchange die Berechtigung am Postfach prüft (Clients and mobile in Exchange Online, Modern authentication in Exchange Online).

Das trennt zwei häufig vermischte Fehler. Schlägt die Anmeldung bei Entra fehl, erreicht der Client Exchange oft gar nicht. Ist das Token gültig, kann Exchange den Zugriff trotzdem wegen fehlender Rolle, Postfachberechtigung, Clientrichtlinie oder eines falschen Zielpostfachs ablehnen. Anmeldeprotokoll und Exchange-Diagnose müssen deshalb zeitlich zusammen betrachtet werden.

Anwendungen greifen vorzugsweise über Microsoft Graph oder unterstützte Exchange-Schnittstellen zu. Eine Graph-Application-Permission kann breit gelten; Exchange RBAC for Applications kann den erreichbaren Postfachbereich enger festlegen. Ein gültiges OAuth-Token ist also nur der erste Schritt. Danach prüft der Ressourcendienst, welche Aktion auf welchem Postfach erlaubt ist (Role Based Access Control for Applications).

Berechtigungen und Änderungen nachvollziehen

Exchange Online besitzt eigene Verwaltungsrollen. Entra-Rollen können den Einstieg in die Exchange-Verwaltung ermöglichen, doch die tatsächlichen Exchange-Cmdlets und ihr Geltungsbereich werden durch Exchange-RBAC bestimmt (Permissions in Exchange Online).

Daneben existieren Postfachberechtigungen wie Full Access, Send As und Send on Behalf. Sie steuern verschiedene Aktionen und sollten nicht als ein gemeinsames «Delegationsrecht» inventarisiert werden. Für Anwendungen kommen OAuth- und Exchange-Anwendungsrollen hinzu (Manage permissions for recipients).

Für Experten ist die Änderungsherkunft genauso wichtig wie der Endzustand. Auditprotokolle, Entra-Anmeldeprotokolle und Konfigurationsexporte beantworten, wer eine Regel, einen Connector oder eine Berechtigung geändert hat. Ein nächtlicher Export zentraler Mailflowobjekte erleichtert Vergleiche, ersetzt aber keine geschützte Auditquelle.

Diagnose: zuerst DNS, dann Transportereignisse

Eine Mailflowanalyse beginnt ausserhalb des Tenants. Der MX zeigt, welches System Internetmail annimmt. Danach wird mit Message Trace geprüft, ob Exchange Online die konkrete Nachricht gesehen und wie es sie verarbeitet hat.

Resolve-DnsName -Type MX example.com
Resolve-DnsName autodiscover.example.com

dig MX example.com
dig autodiscover.example.com

Resolve-DnsName und dig zeigen Veröffentlichung und Auflösung. Sie sagen noch nichts darüber aus, ob EOP die Nachricht angenommen oder ein Postfach sie erhalten hat.

Für den nächsten Schritt wird ein enger Zeitraum mit Absender und Empfänger gewählt. Dieselbe Exchange-Online-PowerShell läuft unter Windows und mit pwsh auf unterstützten Unix-Systemen.

Connect-ExchangeOnline
Get-MessageTraceV2 -SenderAddress sender@example.net `
  -StartDate (Get-Date).AddHours(-2) -EndDate (Get-Date)

pwsh
Connect-ExchangeOnline
Get-MessageTraceV2 -SenderAddress sender@example.net `
  -StartDate (Get-Date).AddHours(-2) -EndDate (Get-Date)

Connect-ExchangeOnline stellt die authentisierte Verwaltungssitzung her. Get-MessageTraceV2 sucht Transportereignisse; Get-Date begrenzt das Zeitfenster. Für Trends kommen Berichte hinzu, für Microsoft-Störungen Service Health. Ein einzelnes grünes Signal beantwortet nicht alle drei Fragen (Exchange Online monitoring).

Aufbewahrung, Löschung und Wiederherstellung

Microsoft schützt den laufenden Dienst mit mehreren Datenbankkopien, Shadow Redundancy und Safety Net. Diese Mechanismen dienen der Verfügbarkeit und Datenintegrität des Dienstes. Sie sind nicht die Benutzeroberfläche für die Wiederherstellung einer versehentlich gelöschten Nachricht (Exchange Online data resiliency).

Für Benutzer- und Compliancefälle greifen andere Funktionen: Deleted Item Retention, Recoverable Items, Single Item Recovery, Retention Policies und Holds. Ihre Wirkungen überschneiden sich, haben aber unterschiedliche Zwecke. Eine Aufbewahrungsregel kann Inhalte vor endgültiger Löschung schützen; sie stellt nicht automatisch ein separates, vom Tenant unabhängiges Backup mit frei wählbarem Wiederherstellungszeitpunkt dar (Recoverable Items folder, Retention policies for Exchange).

Ein belastbares Recoverykonzept hält deshalb fest, welche Ereignisse Microsofts Dienstresilienz abdeckt, welche Inhalte über Exchange- oder Purview-Aufbewahrung zurückgeholt werden können und für welche Anforderungen eine unabhängige Kopie nötig ist. Restoretests sollten konkrete Fälle verwenden: einzelne Nachricht, Ordner, Postfach nach Benutzerlöschung, rechtlich aufbewahrtes Element und tenantweite Störung.

Sicherheit und typische Grenzen

Exchange Online verbindet mehrere Sicherheitsbereiche: Internetmail, EOP, Tenantkonfiguration, Entra-Anmeldung, Postfachrechte und Anwendungen. Die Schutzwirkung hängt davon ab, dass der reale Nachrichten- und Anmeldeweg mit der Konfiguration übereinstimmt.

Für Mailfluss bedeutet das: MX, Connectoridentität, Enhanced Filtering, SPF/DKIM/DMARC und Transportregeln müssen als Kette geprüft werden. Für Clientzugriff sind moderne Authentisierung, Conditional Access, Exchange-RBAC und Postfachberechtigungen getrennte Kontrollen. Für Anwendungen kommen OAuth-Consent und der erlaubte Postfachbereich hinzu.

Die tiefere Adminfrage ist jeweils dieselbe: Welches System hat die Entscheidung getroffen, welche Eingangsdaten hat es dabei gesehen und wo ist das Ergebnis protokolliert? Ohne diese drei Angaben bleibt auch eine formal korrekte Richtlinie schwer prüfbar.

Technische Entwicklung und bewusste Trade-offs

Exchange Online entwickelte sich aus Microsofts gehosteten Exchange-Angeboten und übernahm viele Konzepte des Serverprodukts: Empfänger, Mailboxdatenbanken, Transport, DAGs, Shadow Redundancy und Safety Net. Der Dienst automatisiert den Betrieb dieser Infrastruktur und stellt Tenant-Admins eine höhere Verwaltungsebene bereit (Exchange Team: 20 years ago, Exchange Online data resiliency).

Der Gewinn liegt in ausgelagertem Plattformbetrieb, globaler Dienstintegration und standardisierten Verwaltungsoberflächen. Der Preis ist weniger Zugriff auf einzelne Server, Queues und Datenbankkopien sowie eine stärkere Abhängigkeit von veröffentlichten Diagnose-, Export- und Recoveryfunktionen. Für Experten besteht die Aufgabe deshalb nicht darin, die unsichtbare interne Topologie zu erraten, sondern die dokumentierten Tenantkontrollen und Dienstsignale vollständig zu nutzen.