Mail-Gateway vor Exchange Online: MX umstellen ohne Mailverlust

Ein vorgelagertes Mail-Gateway vor Exchange Online ist nach wie vor verbreitet. Häufige Gründe: Filter, Archiv und Verschlüsselung sollen aus einer Hand kommen, ein bestehendes Gateway wird abgelöst, oder der Anbieter einer Suite wie Hornetsecurity 365 Total Protection übernimmt den Mailfluss. Technisch läuft es immer gleich: Der MX-Record zeigt auf das Gateway, das Gateway stellt an Exchange Online zu.

Der Moment der MX-Umstellung ist selten das Problem. Kritisch sind die Wochen danach. Dieser Artikel zeigt, worauf es bei Connectors, Filterung, Authentifizierung und Rückweg ankommt. Die Beispiele verwenden Exchange-Online-PowerShell und gelten unabhängig vom Gateway-Hersteller.

Drei Architekturen, eine Entscheidung

Bevor Sie Connectors anlegen, sollte feststehen, wo das Gateway im Mailfluss sitzt. Microsoft beschreibt drei Varianten:

Der Rest dieses Artikels behandelt die erste Variante, weil sie bei Suiten mit Filter, Archiv und Verschlüsselung der Normalfall ist.

Bestandsaufnahme vor dem ersten Connector

Die meisten Störungen nach einer MX-Umstellung haben eine Ursache, die vorher sichtbar gewesen wäre. Drei Fragen müssen beantwortet sein:

1. Welche Domains empfangen Mail? Jede akzeptierte Domain mit eigenem MX muss umgestellt werden, auch die vergessene Domain aus einer alten Fusion.
2. Wer stellt heute direkt an den Tenant zu? Scanner, Fachanwendungen, Partner-Connectors und Dienste, die direkt an example-de.mail.protection.outlook.com senden statt über den MX. Diese Absender werden nach der Härtung abgewiesen.
3. Welche Sonderregeln existieren? Transportregeln mit SCL -1, IP-Zulassungslisten, Allow-Einträge. Sie stammen oft vom Vorgänger-Gateway und passen nicht mehr.

Connect-ExchangeOnline
# Akzeptierte Domains und bestehende Connectors
Get-AcceptedDomain | Select-Object DomainName, DomainType, Default
Get-InboundConnector | Format-List Name, ConnectorType, Enabled, SenderIPAddresses, TlsSenderCertificateName, RestrictDomainsToIPAddresses, RestrictDomainsToCertificate, EFSkipLastIP, EFSkipIPs
# Regeln, die den Spamfilter umgehen
Get-TransportRule | Where-Object { $_.SetSCL -eq -1 } |
  Select-Object Name, State, Priority, SenderIpRanges, FromScope
# IP-Zulassungsliste der Verbindungsfilter-Richtlinie
Get-HostedConnectionFilterPolicy | Select-Object Name, IPAllowList
# Woher kommt eingehende Mail tatsächlich? (max. 10 Tage pro Abfrage)
Get-MessageTraceV2 -StartDate (Get-Date).AddDays(-10) -EndDate (Get-Date) -ResultSize 5000 |
  Group-Object FromIP | Sort-Object Count -Descending |
  Select-Object -First 30 Count, Name

Get-MessageTraceV2 ist das aktuelle Cmdlet. Die alten Cmdlets Get-MessageTrace und Get-MessageTraceDetail hat Microsoft abgekündigt, Skripte sollten umgestellt sein. Jede Abfrage liefert höchstens 10 Tage und 5000 Treffer. Für eine belastbare Absenderliste fragen Sie mehrere Zeitfenster ab. Jede Quell-IP, die nicht zum bisherigen Gateway oder zu Microsoft gehört, ist ein Kandidat für einen Direktzusteller.

TTL-Planung: der eigentliche Zeitplan

Der MX-Wechsel wird nicht sofort überall wirksam. Resolver halten den alten Eintrag bis zum Ablauf der TTL vor. Sendende Server, die eine Mail bereits in der Warteschlange haben, versuchen es oft weiter am alten Ziel. RFC 5321 empfiehlt Absendern, Zustellversuche erst nach vier bis fünf Tagen aufzugeben.

• Mindestens 48 Stunden vorher die TTL des MX-Records senken, etwa von 3600 auf 300 Sekunden. Die Wartezeit muss mindestens der alten TTL entsprechen, sonst greift die Senkung nicht rechtzeitig.
• Altes Gateway mindestens fünf Tage weiter annehmen lassen und unverändert an Exchange Online zustellen.
• Erst danach das alte Gateway aus den Connectors entfernen und die TTL wieder anheben.

Connector-Härtung: Exchange Online nur noch über das Gateway erreichbar

Der MX zeigt nach der Umstellung auf das Gateway. Der Endpunkt *.mail.protection.outlook.com Ihres Tenants bleibt aber öffentlich erreichbar. Angreifer kennen das Muster und stellen Phishing direkt dorthin zu, am Gateway vorbei. Microsoft empfiehlt deshalb einen Inbound Connector vom Typ Partner, der nur Verbindungen vom Gateway akzeptiert:

# Bevorzugt: Absicherung über das Zertifikat des Gateways
New-InboundConnector -Name "Nur über Gateway" -ConnectorType Partner -SenderDomains * `
  -RestrictDomainsToCertificate $true -TlsSenderCertificateName "*.gateway-beispiel.de" -RequireTls $true
# Alternative: Absicherung über die IP-Bereiche des Gateways
New-InboundConnector -Name "Nur über Gateway" -ConnectorType Partner -SenderDomains * `
  -RestrictDomainsToIPAddresses $true -SenderIPAddresses "198.51.100.0/24","203.0.113.0/24" -RequireTls $true

Mails, die nicht über diesen Weg kommen, lehnt Exchange Online ab. Drei Punkte entscheiden darüber, ob das gut geht:

• Während der Übergangszeit beide Gateways zulassen. Absender, die noch den alten MX verwenden, kommen über das alte Gateway. Steht dessen IP nicht im Connector, wird ihre Mail abgewiesen. Die alten IPs fliegen erst nach Ablauf der Übergangsfrist raus.
• Kein OnPremises-Connector für Drittanbieter. Microsoft hat Anfang 2026 erneut darauf hingewiesen, dass OnPremises-Connectors mit IP-Adressen, die auch andere Tenants nutzen, oder mit Zertifikaten fremder Domains zu Fehlzuordnungen führen. Für ein Gateway ist der Partner-Typ richtig.
• Direktzusteller vorher umziehen. Was in der Bestandsaufnahme direkt an den Tenant zugestellt hat, braucht einen neuen Weg: über das Gateway, über einen eigenen Partner-Connector oder über authentifizierten Versand.

Ergänzend lässt sich nicht authentifizierter Direct Send organisationsweit sperren:

Set-OrganizationConfig -RejectDirectSend $true

Auch hier gilt: erst inventarisieren, dann sperren. Geräte, die per Direct Send an interne Empfänger senden, erhalten danach einen Fehler 550 5.7.68.

Enhanced Filtering: Exchange Online sieht den echten Absender

Ohne weitere Konfiguration sieht Exchange Online bei jeder eingehenden Mail nur die IP des Gateways. SPF wird gegen die falsche IP geprüft, Spoofing-Erkennung und Absenderreputation laufen ins Leere. Microsoft nennt die Folge selbst unvermeidliche Fehlklassifizierungen.

Enhanced Filtering for Connectors (auch Skip Listing) löst das: Exchange Online überspringt die bekannten Gateway-IPs und wertet die letzte echte Quelle aus. Die Authentifizierung wird dadurch explizit über SPF, DKIM und DMARC der Absenderdomain geprüft. Testen Sie zunächst mit wenigen Empfängern:

# Pilot: nur für ausgewählte Empfänger
Set-InboundConnector -Identity "Nur über Gateway" -EFSkipLastIP $true `
  -EFUsers "pilot1@example.de","pilot2@example.de"
# Danach für die ganze Organisation
Set-InboundConnector -Identity "Nur über Gateway" -EFSkipLastIP $true -EFUsers $null

Durchläuft eine Mail mehrere Hops mit öffentlichen IPs, etwa ein Gateway mit vorgelagerter Annahmestufe, tragen Sie statt -EFSkipLastIP alle Gateway-Bereiche in -EFSkipIPs ein. Private Adressen und Microsoft-IPs werden nicht unterstützt. Wirksamkeit zeigt der Header X-MS-Exchange-ExternalOriginalInternetSender in zugestellten Mails.

Doppelfilterung: wer entscheidet über Spam?

Mit Gateway und Exchange Online Protection laufen zwei Filter hintereinander. Ohne klare Rollenverteilung bekommen Anwender zwei Quarantänen, zwei Arten von Benachrichtigungen und Fehlalarme, die niemand eindeutig zuordnen kann. Es gibt zwei Wege:

Unser Vorgehen: Das Gateway ist der primäre Spamfilter und betreibt die Anwender-Quarantäne. Exchange Online Protection bleibt mit Enhanced Filtering aktiv, die Anti-Spam-Aktionen werden so abgestimmt, dass Mails mit hoher Wahrscheinlichkeit nicht ein zweites Mal in eine Anwender-Quarantäne laufen. Phishing- und Malware-Erkennung bleiben in beiden Stufen scharf. Nach dem Einschalten von Enhanced Filtering deaktivieren Sie bestehende SCL-1-Regeln für den Connector. Microsoft weist darauf hin, dass SCL -1 nur eine Eingabe in die Filterung ist und nicht das Ergebnis.

SPF, DKIM und DMARC nach dem Wechsel

Eingehend

Mit Enhanced Filtering prüft Exchange Online SPF und DMARC der Absender korrekt. Verändert das Gateway Mails, etwa durch Banner oder umgeschriebene Links, brechen die DKIM-Signaturen der Absender. Unterstützt das Gateway ARC, tragen Sie es als vertrauenswürdigen ARC-Sealer ein:

$sealer = @(Get-ArcConfig | Select-Object -ExpandProperty ArcTrustedSealers)
$sealer += "gateway-beispiel.de"
Set-ArcConfig -Identity Default -ArcTrustedSealers $sealer

Der Wert ist die Domain aus dem d=-Tag der ARC-Signatur des Gateways. Set-ArcConfig ersetzt die ganze Liste, deshalb wird die bestehende Liste zuerst gelesen.

Ausgehend

Läuft auch ausgehende Mail über das Gateway, ändern sich zwei Dinge:

• SPF: Das Gateway versendet ins Internet und muss im SPF-Record stehen, mit dem Include, den der Anbieter dokumentiert. Bleibt include:spf.protection.outlook.com stehen, achten Sie auf die Grenze von zehn DNS-Lookups.
• DKIM: Exchange Online signiert, bevor die Mail das Gateway erreicht. Fügt das Gateway danach Signaturen oder Disclaimer ein, ist die Exchange-Signatur ungültig. Entweder signiert das Gateway selbst mit Ihrer Domain, oder es verändert ausgehende Mails nicht.

Werten Sie die DMARC-Reports der ersten zwei Wochen gezielt aus. Wie Sie dabei vorgehen und warum p=reject erst nach dieser Kontrolle sinnvoll ist, beschreibt der Artikel DMARC auf p=reject umstellen.

Ausgehenden Weg schrittweise umstellen

Ausgehend müssen Sie nicht alles auf einmal umstellen. Ein Outbound Connector, der nur über eine Transportregel greift, erlaubt einen Pilot mit einzelnen Absendern:

New-OutboundConnector -Name "Ausgehend über Gateway" -ConnectorType Partner -RecipientDomains * `
  -SmartHosts "smtp-out.gateway-beispiel.de" -UseMXRecord $false `
  -TlsSettings DomainValidation -TlsDomain "smtp-out.gateway-beispiel.de" -IsTransportRuleScoped $true
New-TransportRule -Name "Pilot ausgehend über Gateway" -From "pilot1@example.de","pilot2@example.de" `
  -RouteMessageOutboundConnector "Ausgehend über Gateway"
Validate-OutboundConnector -Identity "Ausgehend über Gateway" -Recipients "test@extern-beispiel.de"

Läuft der Pilot sauber, setzen Sie -IsTransportRuleScoped $false und entfernen die Pilotregel. Bei Hybrid-Umgebungen mit zentralem Mailtransport gelten eigene Regeln, siehe Exchange Hybrid Mailflow.

Ablauf am Umstellungstag

Rollback: der Rückweg muss vorher funktionieren

Ein Rollback ist bei einem MX-Wechsel einfach, solange Sie ihn vorbereitet haben. Er besteht aus drei Schritten: MX zurück auf das alte Ziel, Partner-Connector so belassen, dass er das alte Gateway zulässt, und ausgehend die Transportregel bzw. den Scope des neuen Outbound Connectors zurücknehmen. Deshalb bleibt das alte Gateway unverändert in Betrieb, bis die Übergangsfrist abgelaufen ist, und seine IPs bleiben so lange im Connector.

Legen Sie die Abbruchkriterien vorher fest, zum Beispiel: Mails einer Domain kommen nach 30 Minuten nicht an, das Gateway lehnt gültige Empfänger ab, oder mehr als eine Handvoll legitimer Mails landet in einer Quarantäne, die Anwender nicht erreichen. Wer erst im Störfall über den Rückweg nachdenkt, verlängert die Störung.

Fazit

Ein Mail-Gateway vor Exchange Online ist sicher, wenn es nicht umgangen werden kann und Exchange Online trotzdem den echten Absender sieht. Beides erreichen Sie mit einem Partner-Connector und Enhanced Filtering. Der Rest ist Planung: Absender kennen, TTL rechtzeitig senken, den alten Weg offen lassen, bis der neue nachweislich trägt. Wenn Sie die Umstellung lieber mit jemandem planen, der sie schon oft durchgezogen hat: Unsere Leistungen rund um Mail-Security und Exchange Online beginnen genau mit dieser Bestandsaufnahme.

Nils Lappenbusch

Microsoft Certified Trainer · Exchange- und M365-Experte

Schreibt hier über Probleme, die in echten Projekten auftreten: Microsoft 365, Security, Automatisierung und digitale Systeme. Hängen Sie gerade an genau diesem Thema? Dann lösen wir es gemeinsam, von der Diagnose bis zur Umsetzung.

Kontakt aufnehmen