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 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. Massgeblich ist dort der als erforderlich ausgewiesene Exchange-Online-Eintrag für *.mail.protection.outlook.com und *.mx.microsoft auf TCP 25 (Endpunkt-ID 10 in der Worldwide-Instanz), nicht die deutlich grössere Gesamtheit aller Exchange-Online-Adressen. Für eine andere Microsoft-Cloudinstanz wird deren eigene Liste verwendet. Verantwortliche Person und Prüfintervall der Hostobjekte werden dokumentiert.
Microsoft 365 und SFOS in acht Schritten verbinden
- Bestehenden MX, SPF, Connectoren, Mailheader, öffentliche Absender-IP und Rückfallweg sichern.
- MTA Mode, automatische MTA-Regel, Zertifikat und ausgehenden Scan auf SFOS vorbereiten.
- Aktuelle EOP-IP-Bereiche als getrennte IP-Hostobjekte anlegen.
SMTP RelayausWANerlauben, Host-based relay auf die EOP-Objekte begrenzen und alle anderen Quellen blockieren.- Eine SMTP-route-and-scan-Policy für die geschützte Domain und den tenant-spezifischen Microsoft-Zielhost erstellen.
- In Exchange Online einen Connector von Microsoft 365 zur öffentlichen Firewall-Adresse einrichten.
- MX und SPF im Wartungsfenster auf den neuen Pfad umstellen.
- 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 SMTP-Bereich aus diesem Microsoft-Eintrag ein nachvollziehbar benanntes Objekt angelegt, zum Beispiel mit dem Präfix O365_EOP_. Die Bereiche werden nicht zu einem grösseren Netz zusammengefasst. Wird SMTP über IPv6 veröffentlicht oder geroutet, müssen auch die dort aufgeführten IPv6-Bereiche abgedeckt sein; andernfalls darf kein unbeabsichtigter IPv6-Pfad an der IPv4-Prüfung vorbeiführen. 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 legt separat fest, aus welchen Netzen eingehende Nachrichten für die geschützten Domains angenommen werden; diese Freigabe erlaubt diesen Quellen kein beliebiges ausgehendes Relay.
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 > Add a connector ein Connector mit Connection from: Office 365 und Connection to: Partner organization erstellt. Unter Use of connector wird für den vollständigen ausgehenden Mailflow Only when email messages are sent to these domains gewählt und * als Empfängerdomain eingetragen. Eine bewusst begrenzte Domainliste muss zum dokumentierten Maildesign passen. Unter Routing wird Route email through these smart hosts gewählt; als Smarthost dient die öffentliche IP-Adresse oder der FQDN mail.example.com der Firewall. Diese Felder entsprechen der aktuellen Sophos-Anleitung für Microsoft 365.
Unter Security restrictions wird Always use Transport Layer Security (TLS) to secure the connection (recommended) aktiviert. Die Sophos-Anleitung wählt dazu Any digital certificate, including self-signed certificates. Diese Auswahl erzwingt TLS, prüft aber weder eine vertrauenswürdige CA noch den Namen. Für den produktiven Pfad wird deshalb gemäss der Microsoft-Connector-Dokumentation Issued by a trusted certificate authority (CA) gewählt und zusätzlich der Subject- beziehungsweise SAN-Name mail.example.com vorgegeben. Der Name wird durch den echten Firewall-FQDN ersetzt und mit einem 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 jede tatsächlich nach aussen sendende Quelle autorisieren. Sophos zeigt dafür als einfaches Beispiel v=spf1 include:spf.protection.outlook.com mx -all: mx autorisiert die Adressen der MX-Hosts, include:spf.protection.outlook.com bleibt nötig, wenn Exchange Online für diese Domain auch direkt ins Internet sendet. Läuft ausnahmslos jeder externe Versand über SFOS, wird nicht allein aus Gewohnheit ein ungenutzter Microsoft-Direktpfad freigegeben. Der bestehende Record wird in keinem Fall blind ersetzt; weitere Versanddienste, Subdomains, Include-Ketten und das von Microsoft dokumentierte SPF-Limit von zehn DNS-auslösenden Mechanismen werden zuerst inventarisiert. Danach bestätigen echte Nachrichtenheader, dass SPF für die beobachtete letzte Absender-IP besteht und DKIM sowie DMARC weiterhin ausgerichtet sind.
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 der dokumentierte Vorzustand wiederhergestellt, nicht ein vermuteter Standard. Zuerst erhält der Exchange-Online-Connector exakt seinen früheren Aktivierungszustand, Scope, Routing- und TLS-Wert; nur ein für diese Umstellung neu erstellter Connector wird deaktiviert. Danach werden die gesicherten MX-Ziele samt Prioritäten und der vollständige frühere SPF-TXT-Wert zurückgespielt. Autoritative DNS-Antworten und mehrere öffentliche Resolver müssen die alten Werte liefern.
Pilot-Policy, EOP-Hostobjekte und Relay-Freigaben bleiben bestehen, bis ein- und ausgehende Testmails wieder über den alten Pfad funktionieren und die frühere DNS-TTL abgelaufen ist. Danach werden nur die für diese Umstellung neu erstellten Elemente entfernt; zuvor vorhandene oder gemeinsam genutzte Objekte bleiben unverändert.
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 Relayist 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.