Sophos Firewall MTA mit Microsoft 365 einrichten

Sophos Firewall kann im MTA Mode vor Microsoft 365 als eigenes Mail-Gateway arbeiten. Eingehende Nachrichten erreichen zuerst die Firewall und werden danach an Exchange Online Protection zugestellt. Ausgehende Nachrichten sendet Exchange Online über einen Connector zurück zur Firewall, die sie prüft und ins Internet weiterleitet.

Dieser Aufbau ist möglich, aber nicht automatisch die beste Architektur. Sophos Central Email, Microsoft Defender for Office 365 und die On-box Mail Protection überschneiden sich teilweise. Vor dem Umbau muss klar sein, welches System für Spam, Malware, Quarantäne, TLS, DKIM und Fehlersuche verantwortlich ist.

⚠️ Eine breite Relay-Freigabe macht aus der Firewall im schlimmsten Fall ein Open Relay. Vor der MX-Umschaltung bleiben eine lokale Adminsitzung, der bisherige Mailflow und ein getesteter Rückfallweg verfügbar. Die produktive Umstellung erfolgt erst, wenn ein nicht autorisierter Relay-Test zuverlässig abgewiesen wird.

Den bidirektionalen Mailflow zuerst zeichnen

Der eingehende Pfad lautet Internet → Sophos Firewall MTA → Exchange Online Protection → Microsoft-365-Postfach. Der öffentliche MX-Record zeigt dafür auf die öffentliche SMTP-Adresse der Firewall. Die SMTP-route-and-scan-Policy stellt anschliessend an den tenant-spezifischen Microsoft-Zielhost zu, zum Beispiel example-com.mail.protection.outlook.com.

Der ausgehende Pfad lautet Exchange Online → Microsoft-365-Connector → Sophos Firewall MTA → Internet. Die Firewall darf Relay nur von den aktuellen Exchange-Online-Protection-Netzen akzeptieren. HELO, Zertifikat, öffentliche Absender-IP, PTR/rDNS, SPF, DKIM und DMARC müssen zu diesem Pfad passen.

Die allgemeinen MTA-Grundlagen, Policy-Felder, Quarantäne und Logs erklärt Mail Protection im MTA Mode einrichten. Dieser Artikel konzentriert sich auf die Microsoft-365-Verbindung.

Beispielwerte und Voraussetzungen

Das Beispiel verwendet die Maildomain example.com, den Firewall-FQDN mail.example.com, die Dokumentationsadresse 192.0.2.25 und den tenant-spezifischen Zielhost example-com.mail.protection.outlook.com. Diese Werte werden durch die echte Domain, eine feste öffentliche Adresse und den tatsächlichen Microsoft-Zielhost ersetzt. 192.0.2.25 gehört zu TEST-NET und darf nicht produktiv verwendet werden.

Vor der Konfiguration müssen TCP 25 aus dem Internet zur Firewall, ausgehend zu Microsoft 365 und von der Firewall zu externen Mailservern funktionieren. Benötigt werden zudem eine passende Email-Protection-Lizenz, MTA-Unterstützung auf dem Modell, ein öffentlich vertrauenswürdiges Zertifikat, kontrollierter DNS-Zugriff sowie Berechtigungen für Exchange Admin Center und autoritatives DNS.

Die Exchange-Online-Protection-Netze ändern sich. Sie werden nicht aus einem statischen Blogbeispiel übernommen, sondern aus der aktuellen von Sophos verlinkten Microsoft-365-Endpunktliste gepflegt. Für diesen Mailflow sind insbesondere die SMTP-Endpunkte auf TCP 25 relevant. Owner und Review-Intervall der Hostobjekte werden dokumentiert.

Microsoft 365 und SFOS in acht Schritten verbinden

1. Bestehenden MX, SPF, Connectoren, Mailheader, öffentliche Absender-IP und Rückfallweg sichern.
2. MTA Mode, automatische MTA-Regel, Zertifikat und ausgehenden Scan auf SFOS vorbereiten.
3. Aktuelle EOP-IP-Bereiche als getrennte IP-Hostobjekte anlegen.
4. SMTP Relay aus WAN erlauben, Host-based relay auf die EOP-Objekte begrenzen und alle anderen Quellen blockieren.
5. Eine SMTP-route-and-scan-Policy für die geschützte Domain und den tenant-spezifischen Microsoft-Zielhost erstellen.
6. In Exchange Online einen Connector von Microsoft 365 zur öffentlichen Firewall-Adresse einrichten.
7. MX und SPF im Wartungsfenster auf den neuen Pfad umstellen.
8. Eingehende, ausgehende und abgewiesene Relay-Versuche mit Headern, Mail logs, Spool und Microsoft-Trace abnehmen.

Sophos Firewall vorbereiten

MTA Mode, automatische Regel und Zertifikat

Unter Email > General settings wird MTA mode aktiviert. SFOS erstellt dabei Auto added firewall policy for MTA für SMTP und SMTPS. Die Regel wird nicht editiert und bleibt gemäss Sophos ganz oben. Fehlt sie trotz aktivem MTA Mode, wird nicht blind eine eigene Any-to-Any-Regel gebaut; zuerst werden Modus, bestehende Konfiguration und Supportweg geprüft.

Unter SMTP settings erhält SMTP hostname den vorgesehenen Domainnamen. Für SMTP TLS configuration wird ein öffentlich vertrauenswürdiges Zertifikat gewählt und Allow invalid certificate bleibt deaktiviert. Scan outgoing mails muss aktiv sein, wenn auch der aus Exchange Online kommenden Versand geprüft werden soll.

EOP-Quellen als Relay erlauben

Unter Hosts and services > IP host wird für jeden aktuellen EOP-IPv4-Bereich ein nachvollziehbar benanntes Objekt angelegt, zum Beispiel mit dem Präfix O365_EOP_. Die Bereiche werden nicht zu einem grösseren Netz zusammengefasst. Nach einer Microsoft-Änderung werden neue und entfernte Netze kontrolliert nachgeführt und getestet.

Unter Administration > Device access wird SMTP Relay für WAN aktiviert. Dieser Zonenschalter allein ist zu breit und wird deshalb unter Email > Relay settings > Host-based relay begrenzt:

• Allow relay from hosts/networks: nur die gepflegten EOP-Hostobjekte;
• Block relay from hosts/networks: Any.

Sophos wertet einen passenden Allow-Eintrag vor dem überlappenden Block aus. Genau deshalb dürfen in der Allow-Liste keine grossen Provider-, Cloud- oder Any-Netze stehen. Upstream host ist eine separate Zielsteuerung und ersetzt diese Quellprüfung nicht.

Für den normalen eingehenden Internet-Mailflow setzt das Sophos-Rezept unter Upstream host > Allow relay from hosts/networks dagegen Any. Diese Einstellung erlaubt externen SMTP-Hosts die Zustellung an die geschützten Domains; sie ist nicht dieselbe Freigabe wie das ausgehende Host-based relay. Steht bereits ein definierter externer Mailgateway vor SFOS, wird die Upstream-Liste stattdessen auf dessen reale Quellnetze begrenzt.

Route-and-scan-Policy zur Microsoft-Zustellung

Unter Email > Address group wird die geschützte Maildomain als Email address/domain angelegt. Danach entsteht unter Email > Policies and exceptions > Add a policy > SMTP route and scan eine Policy mit:

• der Address Group unter Protected domain;
• Global action: Accept;
• Route by: DNS host und dem tenant-spezifischen Microsoft-Zielhost;
• den bewusst gewählten Spam-, Malware-, File- und Data-Protection-Einstellungen.

Der Routinghost ist nicht der öffentliche MX von example.com, nachdem dieser auf die Firewall zeigt. Sonst stellt die Firewall an sich selbst zu und erzeugt eine Schleife. Der echte Microsoft-Zielhost wird vor der MX-Änderung erfasst und muss von SFOS korrekt aufgelöst werden.

Exchange Online Connector einrichten

Im Exchange Admin Center wird unter Mail flow > Connectors ein Connector From: Office 365 und To: Partner organization erstellt. Soll der gesamte ausgehende Mailflow über SFOS laufen, gilt seine Zielbedingung für alle Empfängerdomains (*). Eine bewusst begrenzte Teilmenge muss zum dokumentierten Maildesign passen. Als Smarthost dient die öffentliche IP-Adresse oder der FQDN mail.example.com der Firewall.

TLS wird für den Connector erzwungen. Die Sophos-Hilfe zeigt als kompatible Auswahl auch beliebige digitale Zertifikate, einschliesslich selbstsignierter Zertifikate. Für den produktiven Pfad ist ein öffentlich vertrauenswürdiges Zertifikat mit zum FQDN passender Identität jedoch robuster und wird mit einem echten Connector-Test abgenommen.

Die Connector-Validierung kann vor der DNS-Umschaltung scheitern. Sie ersetzt deshalb weder den späteren End-to-End-Test noch den negativen Relay-Test. Nach dem Speichern wird mit Microsoft Message Trace geprüft, ob ausgehende Nachrichten tatsächlich den vorgesehenen Connector und die Firewall verwenden.

MX und SPF kontrolliert umstellen

Erst wenn die Firewall-Policy, EOP-Relay-Freigabe, der interne Microsoft-Zielhost und der Connector vorbereitet sind, zeigt der öffentliche MX auf mail.example.com. Die TTL wird rechtzeitig vor dem Wartungsfenster reduziert. Alte MX-Ziele bleiben für den dokumentierten Rückfall verfügbar, werden aber nicht parallel so belassen, dass Absender den neuen Schutzpfad zufällig umgehen.

Der SPF-Record muss Exchange Online und die öffentliche Absenderidentität der Firewall autorisieren. Sophos zeigt dafür als einfaches Beispiel v=spf1 include:spf.protection.outlook.com mx -all. Dieser Wert wird nicht blind ersetzt: Vorhandene Versanddienste, Subdomains, Include-Ketten und das DNS-Lookup-Limit werden zuerst inventarisiert. DKIM und DMARC werden mit echten Nachrichtenheadern erneut geprüft.

Den gesamten Pfad abnehmen

Von einem externen Testsystem helfen folgende lesende Checks:

dig MX example.com
dig A mail.example.com
nc -vz mail.example.com 25
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com

Die Beispielnamen werden durch die echten Werte ersetzt. DNS, TCP und TLS beweisen noch keine Zustellung. Für die Abnahme werden mindestens eine externe Nachricht an ein Microsoft-365-Postfach, eine ausgehende Nachricht aus Microsoft 365, ein ungültiger Empfänger und ein Relay-Versuch von einer nicht erlaubten Quell-IP getestet.

Auf SFOS werden Email > Mail logs, Mail spool, SMTP quarantine, Log Viewer sowie smtpd_main.log, smtpd_reject.log und smtpd_error.log mit demselben Zeitstempel korreliert. Auf Microsoft-Seite zeigen Message Trace und Connectorstatus, ob EOP die Nachricht angenommen beziehungsweise über den Connector gesendet hat. Die Logdateien sind unter Sophos Firewall Services und Logs eingeordnet.

Fehler nach Symptom eingrenzen

Externe Nachricht erreicht Microsoft 365 nicht

Zuerst MX, öffentliche Firewall-Adresse, TCP 25, SMTP Relay aus WAN, automatische MTA-Regel und Mail logs prüfen. Nimmt SFOS die Nachricht an, aber stellt sie nicht weiter zu, sind DNS-Auflösung des tenant-spezifischen Zielhosts, Route-and-scan-Policy, TLS und Spool entscheidend.

Ausgehende Nachricht umgeht die Firewall

Connector-Scope, Priorität und Message Trace im Exchange Admin Center prüfen. Erst wenn der Trace die Firewall als Smarthost zeigt, werden SFOS-Relay-Match, Policy und öffentliche Quelladresse bewertet. Bei mehreren WAN-Leitungen hilft der entsprechende Abschnitt unter Mail Protection im MTA Mode einrichten.

Relay wird abgewiesen oder wäre zu breit erlaubt

Die reale EOP-Quell-IP mit der aktuellen Microsoft-Liste und den SFOS-Hostobjekten vergleichen. Ein erlaubtes EOP-Netz muss in Allow relay from hosts/networks stehen; alle übrigen Quellen fallen auf Block relay from hosts/networks: Any. Eine breite Cloud- oder WAN-Freigabe ist kein Fehlerfix.

TLS oder Connector-Validierung schlägt fehl

FQDN, öffentliche DNS-Auflösung, Zertifikatsname, vollständige Kette, Gültigkeit und STARTTLS getrennt prüfen. Ein erfolgreiches openssl s_client bestätigt den Firewall-Endpunkt, aber noch nicht Microsofts Connector-Scope oder die vollständige Zustellung. Ein Zertifikatsfehler wird nicht mit Allow invalid certificate dauerhaft umgangen.

Es entsteht eine Mail-Schleife

Öffentlichen MX und Ziel der SMTP-route-and-scan-Policy vergleichen. Zeigen beide auf mail.example.com, muss die Policy auf den tenant-spezifischen Microsoft-Zielhost korrigiert werden. Bis der Pfad eindeutig ist, wird die produktive Zustellung auf den dokumentierten alten Weg zurückgesetzt.

Sicher zurückrollen

Beim Rollback wird zuerst der Exchange-Online-Connector deaktiviert oder auf den dokumentierten Vorzustand gesetzt. Danach werden MX und SPF zurückgestellt und ihre weltweite Auflösung geprüft. Erst wenn ein- und ausgehende Testmails wieder über den alten Pfad funktionieren, werden die Pilot-Policy, EOP-Hostobjekte und Relay-Freigaben auf SFOS entfernt.

Nachrichten im Spool oder in der Quarantäne werden nicht blind gelöscht. Sie gehören zum dokumentierten Übergang und werden erst nach Prüfung von Absender, Empfänger und gewünschtem Zustellpfad behandelt.

Betriebscheckliste

• Zuständigkeit von SFOS, Microsoft 365 und weiteren Mail-Gateways ist festgelegt.
• Bisheriger MX, SPF, Connector und Mailflow sind als Rückfall dokumentiert.
• EOP-IP-Objekte stammen aus der aktuellen Microsoft-Liste und besitzen einen Owner.
• SMTP Relay ist nur über enge Host-based-relay-Einträge nutzbar; nicht autorisierte Quellen werden abgewiesen.
• Route-and-scan-Policy zeigt auf den tenant-spezifischen Microsoft-Zielhost und nicht zurück auf den öffentlichen MX.
• Connector, Zertifikat, DNS, MX, SPF, DKIM und DMARC sind mit echten Nachrichten geprüft.
• Eingehender, ausgehender, ungültiger und nicht autorisierter Testfall sind bestanden.
• Mail logs, Spool, Quarantäne und Microsoft Message Trace lassen sich zeitlich korrelieren.
• EOP-Netze und Zertifikatsablauf werden regelmässig überprüft.

FAQ