Warum Multifunktionsgeräte und Anwendungen nach der Microsoft-365-Migration keine E-Mails mehr senden – und wie man SMTP korrekt anbindet

Technische Ursachen nach der Migration: Transportpfade, Authentifizierung, TLS und Relaying in Exchange Online

Nach einer Migration zu Microsoft 365 ändern sich die Transportpfade für ausgehende E-Mails fundamental: Statt eines lokalen Exchange-Transportdienstes oder eines firmeneigenen SMTP-Gateways wird der Versand in vielen Szenarien über Exchange Online bzw. Exchange Online Protection (EOP) abgewickelt. Systeme, die zuvor „einfach“ an einen internen SMTP-Server übergeben haben, treffen nun auf deutlich strengere Annahmebedingungen, andere Namensräume und eine neue Sicherheitslogik. Die Auswirkungen zeigen sich besonders bei Multifunktionsgeräten, Scannern, ERP- und Monitoring-Anwendungen, die traditionell SMTP ohne moderne Authentifizierung verwenden.

Die häufigsten Ursachen sind keine „Fehler“ der Geräte, sondern gebrochene Annahmen: Ein lokaler Smarthost existiert nicht mehr, eine Absenderdomäne ist in Exchange Online nicht als zulässige Senderdomäne bekannt, die Verbindung kommt nur über opportunistisches TLS zustande oder Exchange Online blockiert Relaying ohne explizite Freigabe. Hinzu kommen tenantweite Sicherheitsstandards wie deaktiviertes SMTP AUTH für Benutzerpostfächer oder Conditional-Access-Vorgaben, die für „Legacy-Clients“ nicht erfüllt werden können (relevant vor allem bei SMTP Submission mit Benutzeranmeldung).

Transportpfade in Exchange Online: Warum der alte SMTP-Weg nicht mehr greift

In klassischen On-Premises-Umgebungen akzeptiert ein interner Exchange-Server häufig SMTP aus dem LAN und übernimmt Relaying sowie Richtlinien (z. B. Empfangsconnectoren nach Quell-IP). Nach der Migration ist Exchange Online jedoch nicht „der neue interne SMTP-Server“, sondern ein Internetdienst mit klar definierten Annahmepunkten. Verbindungen werden nur unter bestimmten Bedingungen akzeptiert: passende Connector-Konfiguration (für Relay-Szenarien), zulässige Senderdomäne, konsistente Envelope- und Header-Sender, sowie eine Transportentscheidung, ob die Nachricht als „intern autorisiert“ oder als „anonym aus dem Internet“ gewertet wird.

Viele Geräte senden zudem an smtp.office365.com und erwarten, dass der Dienst Relaying für beliebige Empfänger zulässt. Exchange Online unterscheidet jedoch streng zwischen clientbasiertem Versand (Submission) und Relay-Szenarien. Submission ist an Authentifizierung gebunden und nutzt typischerweise Port 587. Relay-Szenarien werden in Microsoft 365 typischerweise über den MX-Endpunkt der Domäne (EOP) auf Port 25 und einen passenden Inbound Connector abgebildet; sie verlangen eine eindeutige Identifikation der Quelle (meist feste öffentliche IP) und eine sauber definierte Absenderdomäne.

Authentifizierung: SMTP AUTH, Modern Auth und typische Bruchstellen

„SMTP AUTH“ bezeichnet in Microsoft-365-Kontext meist SMTP Submission mit Benutzername/Passwort (oder OAuth2/XOAUTH2). In sicherheitsgehärteten Tenants ist SMTP AUTH häufig tenantweit deaktiviert oder pro Postfach gesperrt, um Passwortangriffe und Legacy-Protokollrisiken zu reduzieren. Anwendungen, die nur Basic Auth sprechen, scheitern dann bereits beim AUTH-Handshake oder erhalten nach erfolgreicher TCP-Verbindung ein Ablehnungsverhalten beim Senden.

Ein verbreitetes Missverständnis entsteht durch die Gleichsetzung von „Anmeldung am Microsoft-Konto“ mit „Modern Authentication“. SMTP Submission unterstützt in Exchange Online zwar OAuth2 (XOAUTH2), aber nur, wenn die Anwendung dies explizit implementiert und im Tenant entsprechend zugelassen ist. Die Mehrheit eingebetteter Geräte und älterer Applikationen kann das nicht. In solchen Fällen bleibt entweder ein Relay-Modell ohne Benutzeranmeldung oder ein lokales Relay, das selbst modern angebunden wird.

• SMTP Submission mit Authentifizierung: Ziel ist typischerweise smtp.office365.com über 587 mit STARTTLS; scheitert bei deaktiviertem SMTP AUTH oder nicht unterstützter Auth-Methode (Basic vs. OAuth2).
• Connector-basiertes SMTP-Relay: Annahme erfolgt über MX/Exchange Online Protection; Identifikation der Quelle über feste öffentliche IP und Inbound-Connector; kein Benutzerkontext, daher keine Postfach-Anmeldeprüfung.
• Lokales Relay als „Übersetzer“: Geräte sprechen intern unverschlüsseltes SMTP, das Relay übernimmt TLS, Richtlinien und ggf. Submission/Connector-Anbindung nach außen; reduziert die Anzahl direkter Cloud-Verbindungen.

TLS und Zertifikatsrealität: STARTTLS, Namensprüfung und erzwungene Verschlüsselung

Exchange Online erwartet für Submission über Port 587 grundsätzlich STARTTLS mit aktuellen TLS-Versionen und passenden Cipher Suites. Ältere Geräte unterstützen häufig nur TLS 1.0/1.1 oder bieten fehlerhafte Implementierungen (z. B. Probleme bei Zertifikatsprüfung/Chain, abweichende Namensprüfung). Das führt zu Abbrüchen im TLS-Handshake oder zu Zuständen, in denen das Gerät zwar eine Verbindung aufbaut, aber beim Umschalten auf TLS scheitert und den Versand abbricht.

Für Relay über Connectoren ist TLS nicht in jedem Szenario zwingend erzwungen, wird aber in der Praxis oft über Connector-Einstellungen („TLS erforderlich“) oder organisatorische Sicherheitsvorgaben vorausgesetzt. Problematisch wird es, wenn Anwendungen „opportunistisches TLS“ erwarten, aber gleichzeitig ein Richtlinienrahmen entsteht, der Verschlüsselung erzwingt und bei Klartext ablehnt. Technisch sichtbar wird das je nach Gegenstelle als 4xx-Status (z. B. temporäre TLS-Probleme) oder als generischer Verbindungsabbruch während der Aushandlung; konkrete Codes können je nach Pfad/Frontend variieren.

Relaying und „550 5.7.54 Unable to relay“: Was Exchange Online tatsächlich verweigert

Die Meldung 550 5.7.54 Unable to relay steht typischerweise dafür, dass kein autorisierter Berechtigungsweg für den Versand an die angeforderten Empfänger besteht (häufig: externe Empfänger). In Exchange Online ist Relaying kein Default-Verhalten für anonyme Einlieferungen. Wird eine Nachricht ohne Authentifizierung und ohne passenden Inbound-Connector übermittelt, bewertet Exchange Online die Quelle wie eine beliebige Internetquelle und blockiert den Versuch, externe Empfänger zu adressieren.

Auch bei vorhandener Connector-Konfiguration kann Relaying scheitern, wenn die Quell-IP nicht exakt übereinstimmt (NAT-Wechsel, falscher Internet-Uplink), wenn die Absenderdomäne nicht als Accepted Domain geführt ist oder wenn Envelope-From/From-Header nicht konsistent wirken und dadurch zusätzliche Anti-Spoofing-Prüfungen greifen. In der Praxis werden solche Fälle oft fälschlich als „SMTP kaputt“ interpretiert, obwohl Exchange Online lediglich eine nicht autorisierte Weiterleitung unterbindet.

Warum DNS und IP-Identität technisch mit dem Versandweg verknüpft sind

Nach der Migration verlagert sich die „Identität“ des sendenden Systems: Bei Submission ist es das authentifizierte Postfach; bei Connector-Relay ist es primär die öffentliche Quell-IP und die daraus abgeleitete Vertrauensstellung. Diese Entscheidung hat direkte Folgen für DNS und Authentizität: SPF muss die tatsächlich verwendeten Versandwege abbilden, sonst steigt die Wahrscheinlichkeit, dass Empfänger die Nachricht als Spoofing einordnen oder dass Filtermechanismen sie als verdächtig markieren. Besonders kritisch sind Szenarien, in denen ein Gerät über einen ISP ausgehende IPs wechselt oder mehrere Standorte unterschiedliche NAT-Gateways nutzen.

Technisch stabil wird der Versand nur, wenn Transportpfad, Authentifizierungsmethode, TLS-Fähigkeit und Identitätsnachweise (IP/DNS) zueinander passen. Andernfalls entstehen Fehlerbilder, die je nach Gerätelogik als Timeout, als generischer „Send failed“-Status oder als SMTP-Statuscodes sichtbar werden, obwohl die eigentliche Ursache in einer abweichenden Annahmepolitik von Exchange Online liegt.

Anbindungsmodelle sauber trennen: SMTP AUTH (Client Submission), SMTP-Relay über Exchange Online Connectoren und lokales Relay (On-Premises/Edge)

Nach der Migration zu Microsoft 365 scheitern SMTP-basierte Systeme häufig nicht an „SMTP allgemein“, sondern an einer falschen Modellannahme. Exchange Online unterstützt unterschiedliche Wege für den E-Mail-Versand, die sich in Authentifizierung, zulässigen Absendern, Protokoll- und Netzwerkgrenzen sowie in den Betriebs- und Sicherheitsfolgen deutlich unterscheiden. Eine saubere Trennung der Anbindungsmodelle verhindert Fehlkonfigurationen wie ungewolltes Relaying, unsichere Ausnahmeregeln oder dauerhaft blockierte Geräte.

Die drei praxistauglichen Grundmodelle sind: SMTP AUTH (Client Submission) für Anwendungen, die modern authentifizieren können, SMTP-Relay über Exchange Online (Connector-basiert) für Geräte und Systeme ohne Nutzeranmeldung, sowie ein lokales Relay (On-Premises/Edge) als kontrollierte Zwischenstation, wenn Netzwerksegmentierung, Legacy-Protokolle oder komplexe Routinganforderungen das erfordern.

Modell 1: SMTP AUTH (Client Submission) – Benutzerbasierter Versand

SMTP AUTH bezeichnet den Versand per „Client Submission“ über Exchange Online mit expliziter Authentifizierung. Typisch ist Port 587 mit STARTTLS gegen smtp.office365.com. Das Modell passt zu Anwendungen, die Benutzeranmeldeinformationen (oder dedizierte Servicekonten) sicher verwalten können und die das Authentifizierungsmodell der Organisation unterstützen. In vielen Tenants ist Basic Authentication für SMTP AUTH aus Sicherheitsgründen deaktiviert; wenn SMTP AUTH genutzt wird, sollte es gezielt auf Mailbox-Ebene für ein Servicekonto aktiviert und streng abgesichert werden.

Technisch wird bei SMTP AUTH in der Regel eine echte Mailbox als Absenderidentität verwendet. „Send As“ oder „Send on Behalf“ kann erforderlich sein, wenn eine Anwendung im Namen eines Funktionspostfachs senden soll. Für Multifunktionsgeräte ist dieses Modell oft unpraktisch, weil Geräte selten moderne Authentifizierung beherrschen, Passwörter langfristig gespeichert werden müssten und MFA/Conditional Access zusätzliche Hürden erzeugt.

Modell 2: SMTP-Relay über Exchange Online Connectoren – IP-/Zertifikatsbasierter Versand ohne Benutzerlogin

Beim SMTP-Relay über Exchange Online wird kein Benutzer für den SMTP-Dialog authentifiziert. Stattdessen identifiziert Exchange Online die sendende Quelle über eine vordefinierte Vertrauensstellung, typischerweise eine oder mehrere statische öffentliche IP-Adressen (seltener per Zertifikat in hybriden Szenarien). In Exchange Online wird dafür ein Inbound Connector eingerichtet (E-Mail von Ihrer Organisation/Partnerorganisation). Geräte oder ein lokaler Relay-Host senden dann auf Port 25 an den Tenant-Endpunkt (MX) der Domäne, beispielsweise <domain>.mail.protection.outlook.com. TLS wird unterstützt und sollte, wo möglich, erzwungen werden; STARTTLS ist für viele Geräte leichter als moderne Authentifizierung.

Das Modell eignet sich besonders für Scanner/MFPs, Appliances und Tools, die nur „an einen Smart Host senden“ können. Grenzen entstehen dort, wo keine feste Absenderdomäne genutzt werden kann (z. B. externe Envelope-From-Domänen) oder wo Internet-Egress über wechselnde IPs erfolgt. Da Exchange Online hier als Relay fungiert, muss der Absenderbereich über akzeptierte Domänen und Anti-Spam-Regeln sauber kontrolliert werden; ansonsten drohen Zustellprobleme oder Missbrauch, wenn IP-Range und Absender nicht eng genug gefasst sind.

Modell 3: Lokales Relay (On-Premises/Edge/SMTP-Server) – kontrollierte Zwischeninstanz

Ein lokales Relay ist ein im eigenen Netz betriebener SMTP-Server (z. B. Edge Transport, ein dedizierter SMTP-Relay-Dienst oder ein Mail-Gateway), der Geräte in internen Segmenten annimmt, normalisiert und Richtung Exchange Online weiterleitet. Das Modell reduziert Komplexität auf den Endgeräten: Diese sprechen nur zum internen Relay, häufig ohne TLS oder mit internen Zertifikaten, während das Relay selbst die sichere Weiterleitung, Absenderumschreibung, Ratenbegrenzung, Protokollierung und ggf. TLS-Policy umsetzt.

Lokale Relays sind sinnvoll bei mehreren Standorten, getrennten VLANs, fehlender Internetanbindung in Produktionsnetzen, bei Bedarf nach zentralen SMTP-Logs oder wenn zahlreiche Legacy-Systeme nur unverschlüsselt oder ohne Authentifizierung senden können und die Vertrauensgrenze nicht bis Exchange Online gezogen werden soll. Gleichzeitig erhöht sich die Betriebsverantwortung: Patch-Management, Zertifikate, Monitoring und klare Relay-Regeln werden zwingend.

Abgrenzungskriterien für die Modellauswahl

Die Modellauswahl hängt weniger vom Gerätetyp als von dessen Fähigkeiten und vom Sicherheitsmodell der Umgebung ab. Entscheidend sind: Unterstützung für STARTTLS und Zertifikatsprüfung, Möglichkeit zur Nutzung moderner Authentifizierung, vorhandene feste öffentliche IPs für den ausgehenden SMTP-Verkehr, sowie die Frage, ob Absenderadressen strikt in der eigenen Accepted Domain liegen. Ebenso relevant sind Betriebsanforderungen wie zentrale Protokollierung, Störungsdiagnose und die Notwendigkeit, mehrere interne Systeme über einheitliche Policies zu führen.

• Wenn Benutzeridentitäten tragfähig sind: SMTP AUTH über smtp.office365.com mit 587 und STARTTLS; geeignet für Applikationen mit Servicekonto und kontrollierter Berechtigung (z. B. „Send As“).
• Wenn ein Login vermieden werden muss: Exchange-Online-Relay über Inbound Connector und feste Quell-IP(s); Versand an <domain>.mail.protection.outlook.com auf 25, Absender in der eigenen Domäne.
• Wenn Netzsegmente und Legacy dominieren: lokales Relay als Trust-Grenze; Geräte senden intern, das Relay erzwingt Policies und leitet gebündelt nach Exchange Online weiter (oft ebenfalls per Connector-Modell).
• Wenn Absenderdomänen variieren oder extern sind: keines der Modelle sollte „blind“ relayn; erforderlich sind klare Regeln zur erlaubten MAIL FROM-Domäne und ggf. Applikationsanpassungen oder ein dedizierter Mail-Gateway-Ansatz mit kontrolliertem Rewriting.

Sicherheits- und Compliance-Implikationen je Modell

SMTP AUTH verschiebt das Risiko auf Credential-Diebstahl und Fehlkonfiguration bei Konten (z. B. zu breite Berechtigungen, fehlende Einschränkung der Anmeldung). Daher sind dedizierte Servicekonten, minimale Rechte, starke Kennwortrichtlinien und eine enge Kontrolle, ob SMTP AUTH im Tenant überhaupt zulässig ist, zentrale Leitplanken.

Connector-basiertes Relay ist robust gegen Passwortthemen, setzt aber voraus, dass die Quell-IP vertrauenswürdig und stabil ist. Ohne saubere Eingrenzung der IPs und Absenderdomänen entsteht faktisch ein Relay-Pfad, der missbraucht werden kann. Zusätzlich ist die Nachvollziehbarkeit stark von korrekten Headern, eindeutigen Gerätenamen (HELO/EHLO) und konsistenter Protokollierung abhängig.

Ein lokales Relay verbessert Steuerbarkeit und Transparenz, erhöht jedoch die Angriffsfläche im eigenen Betrieb. Der Relay-Host benötigt Härtung, Patchzyklen, TLS-Zertifikatsmanagement und Monitoring. Außerdem müssen Relay-Restrictions (z. B. nur definierte Subnetze, nur definierte Absenderdomänen) aktiv durchgesetzt werden, um „Open Relay“-Risiken im internen Netz zu vermeiden.

Schritt für Schritt zum funktionsfähigen SMTP-Relay: Connector-Setup, SPF, IP-Zuordnung, sichere Tests und Diagnose typischer Fehler (z. B. 550 5.7.54)

Ein SMTP-Relay über Exchange Online (Microsoft 365) ist das gängigste Modell, um Geräte und Anwendungen ohne moderne Authentifizierung weiterhin E-Mails versenden zu lassen. Technisch basiert es auf einer eingehenden Verbindung zu Exchange Online Protection (MX-Endpunkt der Domäne) auf Port 25, die nicht per Benutzername/Kennwort authentifiziert wird, sondern über die Quell-IP (und optional über TLS-Zertifikatsmerkmale). Damit diese Verbindung nicht als „Open Relay“ missbrauchbar wird, erfolgt die Freischaltung strikt über Connectoren und (im Regelfall) über feste öffentliche IP-Adressen.

1) Vorbereitungen: Anforderungen, Absenderdomäne, feste öffentliche IP

Vor der Konfiguration sollten die fachlichen und technischen Randbedingungen feststehen. Entscheidend ist, ob das System nur an interne Empfänger (eigene Tenant-Domänen) senden muss oder auch extern. Der Relay-Connector kann beides unterstützen, aber die Domäne und das Routing müssen sauber definiert sein. Ebenso kritisch: Exchange Online kann eingehende Relay-Verbindungen nur zuverlässig über eine definierte Quell-IP autorisieren, die öffentlich erreichbar und dem sendenden System (oder einem vorgeschalteten lokalen Relay) eindeutig zugeordnet ist.

• Absenderdomäne festlegen: Absenderadressen müssen typischerweise in einer akzeptierten Domäne des Tenants liegen (z. B. scanner@firma.tld), und die Domäne muss in Microsoft 365 verifiziert sein.
• Öffentliche Quell-IP bestimmen: Bei direktem Versand aus einem Standort ist die NAT-/WAN-IP erforderlich; bei Cloud-Systemen die ausgehende IP des Providers. Für dynamische IPs ist dieses Modell nur eingeschränkt geeignet.
• TLS-Fähigkeit prüfen: Für SMTP über das Internet ist STARTTLS üblich (opportunistisch oder erzwungen – je nach Connector/Policy). In Fällen, in denen Altgeräte kein brauchbares TLS unterstützen, ist ein lokales Relay (das TLS modern spricht) oft die saubere Entkopplung.
• Empfängerprofil definieren: Falls externe Empfänger erforderlich sind, muss der Versandpfad über Exchange Online auch dafür vorgesehen sein und darf nicht durch Transportregeln, Anti-Spam-Policies oder Tenant-Restriktionen blockiert werden.

2) Connector in Exchange Online anlegen (Inbound): IP-basierte Autorisierung

Der Relay-Connector wird im Exchange Admin Center als eingehender Connector konfiguriert. Er repräsentiert E-Mail von Ihrer Organisation bzw. einer Partnerorganisation in Richtung Microsoft 365. Die zentrale Sicherheitsentscheidung ist die Identifikation des Absenders: in der Praxis über eine oder mehrere feste öffentliche IP-Adressen. Optional lässt sich die Identifikation über ein TLS-Zertifikat (z. B. über Zertifikatsnamen/Issuer-Informationen) absichern; das ist robust, erfordert jedoch Zertifikatsmanagement auf dem sendenden System oder dem lokalen Relay.

Wesentliche Parameter sind: eindeutiger Name, zulässige Quell-IP(s), ob TLS erzwungen wird, und ob der Connector für bestimmte Domänen oder generell gilt. Für eine geringe Angriffsfläche sollten nur die wirklich benötigten IPs aufgenommen werden. Bei mehreren Standorten empfiehlt sich je Standort ein eigener Connector, um Ursache-Wirkung in Logs und bei Sperren klar zuzuordnen.

3) SPF und Absenderauthentizität: Zustellbarkeit und Spoofing-Schutz

Ein Relay-Connector löst nicht automatisch das Problem der Absenderauthentizität. Für externe Zustellung ist ein konsistentes Setup aus SPF, DKIM und DMARC entscheidend. Beim SMTP-Relay über Exchange Online muss klar sein, welche Systeme im Namen der Domäne senden: entweder ausschließlich Microsoft 365 (empfohlen) oder zusätzlich weitere Relay-Quellen. In der Praxis sollte der Versand möglichst über Microsoft 365 konsolidiert werden; das reduziert SPF-Komplexität und senkt die Wahrscheinlichkeit von „Softfail/Fail“ bei Empfängern.

• SPF für reinen Microsoft-365-Versand: SPF-Eintrag auf v=spf1 include:spf.protection.outlook.com -all setzen, sofern keine weiteren legitimen Absender existieren.
• SPF bei zusätzlichen Absendern: Weitere Mechanismen ergänzen (z. B. ip4:x.x.x.x oder zusätzliche include:-Einträge), dabei DNS-Lookup-Limit (10) im Blick behalten.
• DKIM/DMARC ausrichten: DKIM in Microsoft 365 aktivieren und DMARC mit realistischem Policy-Pfad starten (z. B. p=none mit Reporting), bevor restriktive Policies ausgerollt werden.

Wichtig ist die Erwartungshaltung: Beim Relay per IP-Connector kann die From-Adresse zwar technisch gesetzt werden, aber externe Empfänger prüfen SPF/DKIM/DMARC. Wenn die Sendekette nicht zur SPF-Policy passt oder DKIM/Alignment nicht greift, sinkt die Zustellrate oder es entstehen Spoofing-Warnungen.

4) Client-/Gerätekonfiguration: Server, Port, TLS, Absender und Empfängertests

Auf dem Gerät oder der Anwendung wird als Smarthost für das Connector-Relay in der Regel der MX-Endpunkt der eigenen Domäne konfiguriert (z. B. <domain>.mail.protection.outlook.com), Port 25, ohne SMTP AUTH. Die Absenderadresse sollte eine existierende, im Tenant akzeptierte Domäne verwenden; je nach Gerät ist ein fester From/Reply-To zu definieren. Für Multifunktionsgeräte empfiehlt sich ein dediziertes Absenderpostfach oder eine Shared-Mailbox-Adresse als From, verbunden mit eindeutiger Identifikation im Betreff oder X-Headern (falls das Gerät das unterstützt), um Traces später zu vereinfachen.

• SMTP-Ziel: <domain>.mail.protection.outlook.com auf Port 25, Authentifizierung deaktiviert, wenn der Connector über Quell-IP autorisiert.
• TLS-Einstellung: Wenn verfügbar STARTTLS aktivieren; bei Problemen mit alten TLS-Stacks besser ein lokales Relay vorschalten statt TLS zu deaktivieren.
• Testempfänger staffeln: Zuerst internes Postfach in derselben Domäne, dann internes Postfach in anderer akzeptierter Domäne, anschließend externer Empfänger; jede Stufe getrennt dokumentieren.

5) Sichere Tests und nachvollziehbare Verifikation

Tests sollten sowohl die SMTP-Strecke als auch die spätere Zustellung abdecken. Für die SMTP-Ebene ist ein Test von derselben Quell-IP entscheidend, die im Connector hinterlegt wurde (bei NAT: vom internen System aus testen, das tatsächlich ausgehend genattet wird). Für die Zustellebene liefern Message Trace und die Headeranalyse belastbare Hinweise, ob Exchange Online die Nachricht angenommen, verarbeitet und ausgeliefert hat oder ob sie durch Policies, Reputation oder Empfängerregeln gestoppt wurde.

• SMTP-Handshake prüfen: Verbindung zu <domain>.mail.protection.outlook.com:25 muss möglich sein; bei Netzwerkproblemen zuerst Firewall/Provider-Sperren für Port 25 klären.
• Nachrichtenfluss verifizieren: In Exchange Admin Center Message Trace nutzen (Zeitraum, Absender, Empfänger), zusätzlich Header wie Received: und Authentication-Results: auswerten.
• Testdaten minimieren: Keine produktiven Dokumente scannen; für MFP-Tests neutrale Testseiten verwenden und Zustellung nur an dedizierte Testpostfächer erlauben.

6) Diagnose typischer Fehler: 550 5.7.54, Auth-Fehler und TLS-Probleme

Die häufigste Fehlermeldung bei falsch konfiguriertem Relay ist 550 5.7.54 Unable to relay. Sie bedeutet in diesem Kontext: Exchange Online hat die Verbindung nicht als autorisierte Relay-Quelle erkannt oder lehnt den Versandpfad (Absender/Empfänger) gemäß Connector- oder Richtlinienlogik ab. Die Diagnose sollte strikt von außen nach innen erfolgen: zuerst Identität (IP/TLS), dann Domänen/Adressierung, dann Transport-/Security-Policies.

• 550 5.7.54 Unable to relay: Prüfen, ob die tatsächlich ausgehende Quell-IP mit der im Connector hinterlegten IP übereinstimmt (NAT, zusätzliche Internetleitungen). Connector-Zuordnung und IP-Liste in EAC kontrollieren; bei mehreren Connectors Überschneidungen vermeiden.
• 5.7.57 Client not authenticated / SMTP AUTH disabled: Tritt auf, wenn das Gerät versucht, SMTP AUTH zu nutzen oder auf Submission-Endpunkte konfiguriert ist. In der Gerätekonfiguration Authentifizierung deaktivieren und den MX-Endpunkt der Domäne nutzen (Connector-Relay), oder auf das Modell „SMTP AUTH über Client Submission“ wechseln (dann smtp.office365.com:587 mit Benutzer/Passwort bzw. OAuth2 – abhängig von Tenant-Policy).
• 4.4.x Timeout / Verbindungsfehler: Meist blockiert eine Firewall oder ein ISP ausgehend Port 25. Netzwerkpfad testen und ggf. lokales Relay nutzen, das über einen erlaubten Ausgang arbeitet.
• TLS/Handshake-Fehler: Deuten auf inkompatible TLS-Versionen oder Cipher Suites bzw. Zertifikatsprüfung hin. Gegenprobe über ein aktuelles Relay (z. B. SMTP auf einem aktuellen Mail-Relay-Host) durchführen; Altgeräte sollten nicht durch Deaktivierung von TLS „repariert“ werden.
• Extern nicht zustellbar trotz Annahme: Message Trace zeigt Annahme/Weiterleitung, aber extern blockiert eine Richtlinie (Anti-Spam, Transportregel, Tenant-Restriktion) oder DMARC schlägt beim Empfänger fehl. Headeranalyse und SPF/DKIM/DMARC-Abgleich durchführen.

Für wiederholbare Fehleranalyse lohnt eine feste Check-Reihenfolge: Quell-IP und Portreichweite, Connector-Match, Absenderdomäne, Empfängerprofil (intern/extern), anschließend Policies und Authentizität (SPF/DKIM/DMARC). Damit lassen sich „Relay“-Fehler von Zustellbarkeitsproblemen trennen, die erst nach erfolgreicher Annahme durch Exchange Online entstehen.

Betrieb und Wartung: Dokumentation, Monitoring, Missbrauchsschutz und Änderungen im Microsoft-365-Umfeld

SMTP-Anbindungen sind nach der erfolgreichen Inbetriebnahme nicht „fertig“, sondern werden zu einer dauerhaften Betriebsaufgabe. Microsoft 365 verändert sich regelmäßig durch Security-Defaults, Protokollhärtungen, neue Authentifizierungsanforderungen und Anpassungen in Exchange Online. Zusätzlich bleiben Multifunktionsgeräte, Appliances und Fachanwendungen häufig lange im Feld und unterstützen moderne Verfahren wie OAuth 2.0 nur eingeschränkt. Ohne klar geregelte Betriebsprozesse entstehen schleichend Zustellprobleme, Sicherheitslücken oder unkontrollierte Abhängigkeiten von Einzelpersonen.

Dokumentation: Nachvollziehbarkeit statt „Tribal Knowledge“

Die Dokumentation muss die technische Realität abbilden: welches Gerät oder welche Anwendung sendet über welchen Weg, mit welchen Absenderdomänen, welchen IP-Adressen, welchen Connector-Regeln und welchen DNS-Prämissen. Besonders relevant ist die Kette aus Netzwerksegment, Relay (falls vorhanden), Exchange-Online-Connector und den im Tenant erzwungenen Sicherheitsmechanismen. Änderungen in einem Glied wirken oft erst zeitverzögert auf die Zustellung, etwa wenn eine öffentliche IP durch Providerwechsel wechselt oder ein Gerät nach Firmware-Update andere TLS-Parameter aushandelt.

Praktisch bewährt hat sich eine dokumentierte „SMTP-Serviceakte“ je Relay-Pfad, inklusive Abhängigkeiten zu Zertifikaten, Firewall-Regeln und Zustellgrenzen (Empfängerbereiche, erlaubte Absender, Ratelimits). Für Prüf- und Auditfähigkeit sollten Konfigurationsstände versioniert werden, etwa als Export der Connector-Parameter und als Change-Log zu DNS-Einträgen.

• Connector-Export (Referenzstand): Get-InboundConnector | Select Name,Enabled,ConnectorType,SenderDomains,SenderIPAddresses,TlsSenderCertificateName,RequireTls,RestrictDomainsToIPAddresses
Get-OutboundConnector | Select Name,Enabled,SmartHosts,TlsSettings,RecipientDomains,UseMXRecord
• DNS-Prämissen festhalten: SPF-Record der Absenderdomäne mit dokumentierter Quelle (z. B. include:-Mechanismen oder feste ip4:/ip6:-Einträge) sowie Notiz, ob DKIM/DMARC für diese Absenderdomäne aktiv sind.
• Geräte-/App-Inventar: eindeutige Zuordnung von Hostname/Asset-ID zu FQDN, interner IP, NAT-öffentlicher IP, genutztem SMTP-Port (typisch 25 oder 587), erzwungenem TLS-Modus und konfiguriertem Envelope-From.
• Verantwortlichkeiten und Change-Fenster: benannte Owner für Appliance, Netzwerk/NAT, DNS und Tenant-Konfiguration; Änderungen an Connector, Firewall oder IP-Ranges nur über Change-Prozess mit Rückfallplan.

Monitoring und Diagnose: Signale früh erkennen

SMTP-Störungen werden im Betrieb oft zuerst als „Scan kommt nicht an“ sichtbar. Für einen stabilen Service braucht es Metriken und eine standardisierte Diagnosekette. In Exchange Online liefern Message Trace und (bei vorhandenem Zugriff) erweiterte Trace-Details die beste Sicht auf Annahme, Routing und Policy-Entscheidungen. Auf Relay-Seite sind SMTP-Logs, Queue-Längen und TLS-Handshake-Fehler die wichtigsten Indikatoren. Sinnvoll sind synthetische Tests, die regelmäßig eine definierte Testnachricht senden und die Zustellung bis in ein Postfach überwachen.

Für die Alerting-Praxis ist weniger „alles loggen“ entscheidend, sondern ein enger Satz an Zustandsprüfungen: Erreichbarkeit des Relay-Endpunkts, Annahme über den vorgesehenen Connector-Pfad, sowie Abweichungen bei 4xx/5xx-Antwortcodes. Bei Exchange-Online-Relays ohne Authentifizierung müssen außerdem IP-Änderungen (NAT, Provider) als Monitoring-Event betrachtet werden, weil sie unmittelbar zu „Unable to relay“ führen können.

Missbrauchsschutz: Relays als Angriffsziel behandeln

SMTP-Relays werden häufig nicht aus „klassischen“ Mailserver-Gründen betrieben, sondern als technische Brücke für Geräte. Genau deshalb fehlt ihnen im Alltag oft die gleiche Härtung wie produktiven Mail-Infrastrukturen. Das Risiko ist real: falsch gefasste Connector-Regeln, zu breite IP-Freigaben oder unkontrollierte Absender erlauben Spoofing oder Massenversand. Zusätzlich können kompromittierte Geräte (oder Default-Passwörter bei Appliances) als Sprungbrett dienen, selbst wenn Exchange Online den eigentlichen Versand begrenzt.

Robuster Missbrauchsschutz setzt an mehreren Stellen an: möglichst enge Netzgrenzen (nur definierte IPs), Absenderrestriktionen, TLS-Erzwingung wo technisch möglich, und Protokollierung, die forensisch verwertbar bleibt. In Exchange Online sollte ein Inbound-Connector für Relay-Szenarien nur die minimal nötigen Sender-IP-Adressen enthalten und keine „wildcards“ bei Senderdomänen verwenden, wenn feste Domänen ausreichen. Auf der Relay- oder Geräte-Seite müssen Default-Credentials entfernt, Firmware gepflegt und Zugriffe administrativ begrenzt werden.

• IP-Scope klein halten: Connector nur mit festen öffentlichen IPs in SenderIPAddresses; NAT-Änderungen als Change behandeln, keine Freigabe ganzer Provider-Netze.
• Absenderdomänen begrenzen: im Connector nur tatsächlich genutzte Domänen, keine pauschalen Annahmen; Abweichungen als Incident (Spoofing-Versuch oder Fehlkonfiguration) werten.
• TLS erzwingen, wenn möglich: Connector-Optionen wie RequireTls nutzen; bei zertifikatsgebundenen Szenarien den Parameter TlsSenderCertificateName sauber dokumentieren und Zertifikatswechsel terminieren.
• Raten- und Volumenauffälligkeiten überwachen: Alerts auf Versandspitzen, ungewöhnliche Empfängerdomänen und wiederkehrende NDR-Codes wie 550 5.7.54 oder 530 5.7.0.
• Keine generischen Shared Mailbox Credentials: falls SMTP AUTH genutzt wird, ausschließlich dedizierte Konten, minimale Berechtigungen, MFA- und Conditional-Access-Konzept (wo anwendbar) sowie regelmäßige Secret-Rotation.

Änderungen im Microsoft-365-Umfeld: Betriebsfähigkeit trotz stetiger Anpassungen

Microsoft 365 folgt einem kontinuierlichen Update-Modell. Für SMTP-Szenarien sind vor allem Änderungen an der Authentifizierung (z. B. Tenant- oder Protokoll-Policies), an Sicherheitsvorgaben (Security Defaults, Conditional Access) sowie an den Transportregeln und Anti-Spam-Mechanismen relevant. Selbst wenn ein Relay technisch „nur“ über Port 25 zustellt, können Richtlinien und Schutzmechanismen die Annahme beeinflussen, etwa wenn eine Sendekette plötzlich als riskant bewertet wird oder Absender-/Header-Konsistenzregeln greifen.

In der Wartung bewährt sich ein festes Änderungsfenster, in dem Connector- und DNS-Änderungen gebündelt werden, sowie ein wiederholbarer Abnahmetest. Ein solcher Test sollte nicht nur „Mail kommt an“ prüfen, sondern auch, ob SPF und ggf. DKIM/DMARC erwartbar auswerten, ob der Message Trace den vorgesehenen Connector zeigt und ob keine unerwünschten Header-Umschreibungen auftreten. Zusätzlich sollte die Lebensdauer von Zertifikaten (falls TLS mit Zertifikatsbindung verwendet wird) vor Ablauf überwacht werden, da abgelaufene Zertifikate in der Praxis oft zu sporadischen TLS-Fehlern und schwer zuzuordnenden Zustellabbrüchen führen.

Bei Änderungen an SMTP AUTH (Tenant-Einstellung, pro Mailbox, oder durch Security-Defaults) muss vorab geprüft werden, ob Geräte und Anwendungen überhaupt moderne Authentifizierung unterstützen. Wo das nicht der Fall ist, sollte die Stabilität über ein Relay-Modell erreicht werden, das keine Benutzeranmeldung am Gerät erfordert, ohne dabei IP- und Domänenrestriktionen zu verwässern. Für Störungen ist ein Runbook sinnvoll, das die Prüfung in der Reihenfolge Netzwerk/NAT, DNS/SPF, Connector-Matching, Authentifizierung und schließlich Gerätekonfiguration abarbeitet.