SMTP Relay migrieren – aber wie? (Teil 2)

In Teil 1 ging es darum herauszufinden, welche Systeme euren Exchange tatsächlich als Relay nutzen. Wenn ihr die Liste habt, kommt der unangenehmere Teil: Für jedes Gerät und jede Anwendung muss entschieden werden, wie die Mails künftig nach Exchange Online kommen.

Und dafür gibt es gerade einen ziemlich guten Grund, sich nicht mehr allzu viel Zeit zu lassen: Ende Dezember 2026 schaltet Microsoft Basic Auth für SMTP AUTH in bestehenden Tenants standardmäßig ab. Admins können es noch einmal einschalten, das endgültige Abschaltdatum will Microsoft in der zweiten Jahreshälfte 2027 nennen. Spätestens dann ist für jedes Gerät, das sich heute mit Benutzername und Passwort an smtp.office365.com anmeldet, Schluss.

Die Microsoft-Wege im Überblick

Microsoft dokumentiert inzwischen vier Wege, wie Geräte und Anwendungen über Exchange Online senden können:

Für moderne Anwendungen, die OAuth sprechen, ist SMTP AUTH mit OAuth oder HVE oft der einfachste Weg. Für alles, was intern verschickt (Scan to Mail an die eigenen Postfächer), reichen Direct Send oder HVE. Und dann bleibt der Rest.

Das Problem, das übrig bleibt

Der Rest, das sind in fast jeder Umgebung, die ich sehe:

• Multifunktionsgeräte und Scanner, die kein OAuth können und auch nie ein Firmware-Update dafür bekommen werden.
• Geräte mit altem TLS-Stack. Wie schnell man da Probleme bekommt, habe ich im Scanner-Artikel beschrieben. Exchange Online spricht nur TLS 1.2 und 1.3. Ein Gerät, das nur TLS 1.0 kann, liefert dort bestenfalls im Klartext ein.
• Fachanwendungen, die mit fremden Absenderadressen arbeiten oder an externe Empfänger senden.
• Geräteflotten, bei denen man nicht jedes Gerät einzeln anfassen will. Hundert Drucker auf eine neue Zieladresse, neue Zugangsdaten und neue Ports umzustellen, ist ein Projekt für sich.

Für diese Geräte ist der Connector-Weg der richtige. Er braucht aber eine feste IP oder ein Zertifikat, also genau das, was ein Drucker nicht hat. Die Lösung, die sich in der Praxis bewährt hat: ein kleines lokales Relay, das die Geräte wie bisher anonym auf Port 25 bedient und die Mails sauber per Connector an Exchange Online übergibt. Es ersetzt den Exchange-Server für genau diese eine Aufgabe, ohne den Rest von Exchange.

Zwei Kandidaten stelle ich euch vor.

Variante 1: E-MailRelay

E-MailRelay ist ein schlankes Open-Source-Relay (GPL 3) von Graeme Walker, das es seit vielen Jahren gibt. Aktuell ist Version 2.6.1 vom Februar 2026. Es läuft als Windows-Dienst (mit Setup und Konfigurationsoberfläche) oder als Linux-Daemon.

Das Prinzip ist Store-and-forward: Mails landen in einem Spool-Verzeichnis und werden an einen Smarthost weitergereicht. Für Exchange Online gibt es zwei Wege:

• Port 25 an den MX-Endpunkt, mit Inbound-Connector auf die feste IP oder mit einem TLS-Client-Zertifikat (--client-tls-certificate).
• SMTP AUTH an smtp.office365.com:587, auch mit XOAUTH2. Das Token holt E-MailRelay allerdings nicht selbst, dafür braucht es ein externes Skript.

Ich habe beides ausprobiert. Bei einem Kunden läuft E-MailRelay unter Windows im Produktivbetrieb, per Port 25 an einen Inbound-Connector. Das funktioniert unauffällig.

Was man wissen sollte:

• Welche Geräte einliefern dürfen, lässt sich per IP festlegen. Eine eingebaute Prüfung von Absender- und Empfängerdomänen gibt es nicht, das geht nur über eigene Filter-Skripte.
• Die TLS-Einstellungen (--tls-config) gelten global für beide Richtungen, eine Auswahl der Cipher Suites gibt es nicht.
• Überwachung heißt im Wesentlichen: Logdateien lesen und auf .bad-Dateien im Spool achten.

Für eine überschaubare Zahl von Geräten, die man kennt, ist E-MailRelay eine solide und kostenlose Lösung, solange man bereit ist, ein wenig Konfigurationsarbeit zu investieren.

Variante 2: mein exo-smtp-relay

Weil ich bei Kunden immer wieder vor derselben Situation stehe, habe ich mir ein eigenes Relay gebaut, das genau auf diesen Migrationsfall zugeschnitten ist: exo-smtp-relay. Es ist aus meinem EXO Signature Gateway ausgekoppelt, ohne Signaturen und S/MIME, und läuft als Docker-Container (auch auf dem Raspberry Pi), als systemd-Dienst oder als Windows-Dienst.

Was es anders macht:

• Drei Grenzen statt offenem Relay. Nur Geräte aus der Liste dürfen einliefern, nur mit Absenderdomänen eures Tenants, und standardmäßig nur an Empfänger in eurem Tenant. Externe Empfänger lassen sich je Gerät freischalten. Ein übernommener Drucker wird so nicht zur Spamschleuder.
• Lernmodus. Ihr kennt nicht alle Geräte? Dann gebt einen IP-Bereich für maximal zwei Stunden frei. Jedes Gerät, das darin etwas Zulässiges einliefert, landet in der Liste. Die Ergebnisse aus Teil 1 lassen sich so schnell gegenprüfen.
• Einrichtungsassistent. Ein Entra-Login genügt: Der Assistent legt die App-Registrierung an, richtet den Inbound-Connector ein und holt die Postfachliste. Danach stuft er die App auf reine Leserechte herab. Ein kopierter Schlüssel kann dann nur noch Postfachadressen lesen. Wer gar keine App im Tenant haben will, trägt die Domänen von Hand ein und legt den Connector selbst an.
• Zwei Rückwege. Standardmäßig Port 25 mit Zertifikat an den Connector. Wo ausgehend Port 25 gesperrt ist, geht es per Port 587 mit einem Dienstkonto.
• Altgeräte. Eingetragene Geräte dürfen auch ohne STARTTLS einliefern, und auf der Geräteseite akzeptiert das Relay auch alte TLS-Versionen und Cipher Suites. Richtung Exchange Online wird immer modern verschlüsselt.
• Dashboard. Für jedes Gerät seht ihr, wie viel es einliefert, ob verschlüsselt oder im Klartext, ob an interne oder externe Empfänger, und was abgewiesen wurde.
• Ausfallsicher. Kann das Relay nicht an Exchange übergeben, antwortet es dem Gerät mit einem temporären Fehler (451). Das Gerät versucht es dann später erneut, es geht also nichts verloren.

Das Relay ist kostenlos und ohne Postfachgrenze nutzbar.

E-MailRelay oder exo-smtp-relay?

Kurz gesagt: Wer wenige, bekannte Geräte hat und mit einer Konfigurationsdatei glücklich ist, fährt mit E-MailRelay gut. Wer eine größere, gewachsene Landschaft migriert und sehen will, was da eigentlich verschickt wird, hat es mit dem exo-smtp-relay leichter.

Die Umstellung in der Praxis

Egal für welches Relay ihr euch entscheidet, die Schritte sind dieselben:

1. Inbound-Connector in Exchange Online anlegen (Typ OnPremises), mit Zertifikat oder fester IP. Im Zertifikat muss eine eurer Accepted Domains stehen.
2. Ausgehend Port 25 vom Relay zu <domäne>.mail.protection.outlook.com freigeben. Viele Provider und Netze sperren ihn.
3. Relay einrichten und die Geräte aus Teil 1 eintragen (oder per Lernmodus einsammeln).
4. Geräte umstellen. Am elegantesten ganz ohne Gerätekonfiguration: den DNS-Namen, den die Geräte heute als SMTP-Server nutzen, auf das Relay zeigen lassen, oder die IP-Adresse des alten Exchange-Servers für das Relay übernehmen.
5. Testen und beobachten, dann die alten Receive Connectors abschalten und den Exchange-Server endlich in den Ruhestand schicken.

Fazit

Mit Exchange Online verschwindet der lokale Exchange, die Drucker im Keller bleiben aber. Für alles, was OAuth spricht oder nur intern verschickt, reichen die Microsoft-Wege. Für den Rest ist ein kleines lokales Relay die pragmatischste Lösung, und mit dem Basic-Auth-Ende im Dezember wird genau dieser Rest gerade größer. Ob E-MailRelay oder mein exo-smtp-relay: Hauptsache, ihr habt einen Plan, bevor die Drucker es euch per Fehlermeldung mitteilen. 🙂

Feedback, Fragen und Erfahrungen gerne in die Kommentare oder als Issue im Repo.