Exchange-Ratgeber › Ausgang: Sendeconnectoren und Smarthosts

Exchange-Sendeconnectoren routen nach Empfängerdomäne, nicht nach Absender — so routen Sie trotzdem nach Absenderadresse

Ein Exchange-Sendeconnector wird über die Empfängerdomäne (den Adressraum) und die Kosten ausgewählt, nie über den Absender; um verschiedene Absenderdomänen lokal über verschiedene Smarthosts zu senden, brauchen Sie getrennte AD-Standorte mit bereichsbezogenen Connectoren, einen Transport-Agenten oder ein SMTP-Relay vor Exchange, das nach Absender routet. Dieser Ratgeber erklärt, wie die Connector-Auswahl funktioniert, warum die naheliegenden Umwege scheitern und was die drei echten Wege an Aufwand kosten.

Aktualisiert am 2026-09-16

Die Frage und die kurze Antwort

Die Ausgangslage ist häufig: Ein Exchange Server beherbergt firma-a.de und firma-b.de, oder eine Firmendomäne plus einige Adressen bei einem Hosting-Provider. Jede Domäne hat ihr eigenes Provider-Relay mit eigenem Login, und jeder Provider nimmt nur Mail von den Adressen an, die zu diesem Login gehören. Also legt der Administrator zwei Sendeconnectoren an, einen je Smarthost, und erwartet, dass Exchange für jeden Absender den richtigen benutzt. Das tut es nicht, und keine Einstellung am Connector ändert daran etwas. Microsofts eigene Dokumentation zählt auf, wonach ein Sendeconnector ausgewählt wird, und der Absender steht nicht auf der Liste. In unserer Knowledge Base steht die Antwort seit Exchange 2010 in einem Satz: „mit Bordmitteln“ geht es nicht (Exchange 2010: mehrere Smarthosts anlegen).

Wie Exchange einen Sendeconnector auswählt

Laut Microsoft Learn wird der Sendeconnector, der eine Nachricht zu einem Empfänger routet, in der Phase der Routingauflösung der Kategorisierung ausgewählt, und diese Einstellungen zählen (Sendeconnectors in Exchange Server, E-Mail-Routing in Exchange Server):

Einstellung	Wirkung	Hängt vom Absender ab?
Adressräume	Die Zieldomänen, für die der Connector zuständig ist, etwa `` für alle Domänen oder `.contoso.com`. Eine Nachricht wird dem Connector mit dem genauesten Adressraum für ihren Empfänger zugeordnet.	Nein
Kosten	Entscheiden zwischen Connectoren mit demselben Adressraum: Der Connector mit dem niedrigeren Kostenwert wird bevorzugt.	Nein
Bereich	Ein bereichsbezogener Connector ist nur für Exchange-Server im eigenen Active-Directory-Standort sichtbar; nicht bereichsbezogene Connectoren sieht die ganze Gesamtstruktur.	Nein (hängt vom Standort des sendenden Servers ab)
Quellserver	Welche Exchange-Server über den Connector zustellen dürfen.	Nein
Netzwerkeinstellungen	DNS-Zustellung oder ein oder mehrere Smarthosts, dazu die Authentifizierung am Smarthost.	Nein
Nachrichtengrößenlimit	Connectoren, deren Limit kleiner als die Nachricht ist, werden übersprungen.	Nein

Jede Eingangsgröße der Entscheidung beschreibt das Ziel, die Topologie oder die Nachrichtengröße. Absenderadresse, Absenderdomäne, Postfachdatenbank oder Abteilung werden nicht ausgewertet. Das ist kein Versehen einer bestimmten Version: Die Logik ist laut Microsoft seit Exchange 2010 im Kern unverändert und gilt für Exchange 2013, 2016, 2019 und Exchange Server SE gleichermaßen.

Warum die naheliegenden Versuche scheitern

Zwei Connectoren mit dem Adressraum * und verschiedenen Smarthosts. Beide beanspruchen jedes Ziel. Exchange löst den Gleichstand über den Kostenwert auf, und nichts an dieser Entscheidung betrachtet den Absender. Mail aller Absender geht an den Connector, der gewinnt, oder an beide, und der Provider, der nur seine eigenen Domänen erwartet, antwortet mit einem Absender- oder Authentifizierungsfehler wie 530 SMTP authentication is required oder einer Ablehnung der Absenderadresse.
Ein Adressraum je Absenderdomäne. Der Adressraum ist die Empfängerdomäne. Ein Eintrag firma-b.de macht den Connector für Mail an firma-b.de zuständig, also für Ihre eigene akzeptierte Domäne, die ohnehin intern zugestellt wird. Ein Feld für die sendende Domäne gibt es nicht.
Eine Nachrichtenfluss- (Transport-)Regel. Regeln können eine Nachricht umleiten, ändern, kopieren oder ablehnen und Empfänger hinzufügen, aber sie laufen in einer anderen Phase und können weder einen Connector noch einen Smarthost benennen. Genau das kann der ausgehende Connector in Exchange Online mit seiner Regelbedingung, und genau das kann das lokale Produkt nicht.
Ein zweiter Exchange-Server je Domäne. Hilft nur, wenn die Server in verschiedenen Active-Directory-Standorten stehen (erste Option unten); zwei Server in einem Standort treffen dieselbe Routingentscheidung.

Die drei Wege, die wirklich funktionieren

Option	So funktioniert es	Was es Sie kostet
Getrennte Active-Directory-Standorte mit bereichsbezogenen Connectoren	Jede Absenderdomäne bekommt einen eigenen AD-Standort mit eigenem Exchange-Server und einem bereichsbezogenen Sendeconnector für diesen Provider. Weil ein bereichsbezogener Connector nur im eigenen Standort sichtbar ist, kann Mail, die auf diesem Server eingeliefert wird, nur über ihn hinaus.	Ein Exchange-Server und eine Postfachdatenbank je Domäne, Standortverknüpfungen zu pflegen, und die Benutzer einer Domäne müssen auf diesem Server liegen. Von Microsoft unterstützt, aber schwer für den Fall mit zwei Domänen.
Eigener Transport-Agent	Ein Routing-Agent in der Transportpipeline prüft den Absender und überschreibt das Routingziel, bevor die Kategorisierung endet.	Code, den Sie selbst schreiben und pflegen, nach jedem Cumulative Update neu testen, und der in der Transportpipeline läuft, wo ein Fehler den gesamten Mailfluss anhält.
Absenderrouting-Relay vor Exchange	Exchange behält einen Sendeconnector, der alles an einen lokalen Relay-Dienst übergibt. Das Relay gleicht die Absenderadresse mit seinen Regeln ab und liefert über das Provider-Relay mit den Anmeldedaten, die zu diesem Absender gehören.	Ein Dienst, den Sie installieren und konfigurieren. Exchange selbst bleibt unverändert; die Routingregeln liegen im Relay, und die Exchange-Warteschlangenanzeige zeigt die Mail weiterhin beim Verlassen.

Die ersten beiden Optionen sind Microsoft-Mechanismen und auf den oben verlinkten Microsoft-Learn-Seiten beschrieben. Die dritte setzt MultiSendcon um: Es installiert sich als Windows-Dienst auf dem Exchange-Server, lauscht als lokaler Smarthost (standardmäßig auf Port 2500, weil Exchange selbst Port 25 für seine Empfangsconnectoren belegt), und der Installer legt den Sendeconnector an, der Exchange dorthin zeigt. Kann der Installer den Connector nicht anlegen, etwa weil PowerShell-Remoting deaktiviert ist, erledigt das ein Befehl in der Exchange-Verwaltungsshell (Knowledge Base: den MultiSendcon-Sendeconnector manuell anlegen):

new-sendconnector -name MultiSendcon -Addressspaces "SMTP:*;100" -port 2500 -SmarthostAuthMechanism none -smarthosts 127.0.0.1

Der Adressraum * mit Kosten 100 macht ihn zum Connector für alle Internet-Mail; setzen Sie die Kosten auf 1, damit er gegen jeden älteren Connector gewinnt. Von da an trifft Exchange genau eine Routingentscheidung, und der absenderabhängige Teil passiert im Relay.

Was das Relay je Absender entscheidet

In MultiSendcon ist jedes Provider-Relay ein SMTP-Konto mit einer Absendermaske: *@firma-a.de für eine ganze Domäne, benutzer@firma-b.de für eine einzelne Adresse oder ein Wildcard-Muster. Jedes Konto trägt seinen eigenen Relay-Server, Port (25, 587 oder 465), Login und seine TLS-Einstellungen, optional einen Empfängerfilter und eine lokale IP-Adresse, von der gesendet wird. Die erste passende Regel in Listenreihenfolge gewinnt, eine einzelne Adresse kann also über ihrer Domänenregel stehen, und zwei Konten mit derselben Maske bilden ein Primär-/Ausweichpaar. Absender, auf die keine Regel passt, laufen über die Master-Relay-Konfiguration oder können an die eigenen Sendeconnectoren von Exchange zurückgegeben werden. Eine Option für einen festen Absender ersetzt die ausgehende Adresse, wo ein Provider nur die Adresse des angemeldeten Kontos akzeptiert, und sie füllt auch den leeren Envelope-Absender, den Exchange bei Unzustellbarkeitsberichten und Abwesenheitsnotizen verwendet und den manche Provider inzwischen ablehnen (Knowledge Base: IONOS blockiert Unzustellbarkeitsberichte und Abwesenheitsnachrichten).

Derselbe Mechanismus deckt die verwandten Fälle ab: mehrere Firmen auf einem Server, eine Firmendomäne gemischt mit Google-Workspace-Adressen, Massenmail über eine eigene IP aus Reputationsgründen oder ein Ziel, das ein eigenes Relay braucht (empfängerabhängiges Routing). Exchange 2003 bis 2019 und Exchange Server SE werden unterstützt; der Anschluss ist der normale Sendeconnector, es wird kein Transport-Agent und kein Pipeline-Plug-in installiert.

Exchange Online ist anders

Liegen Ihre Postfächer in Exchange Online, brauchen Sie nichts davon: Ein ausgehender Connector kann dort so eingestellt werden, dass er nur benutzt wird, wenn eine Transportregel Nachrichten an ihn umleitet, und die Regel kann auf den Absender prüfen, also ist „Mail dieser Absender über diesen Smarthost“ eine eingebaute Konfiguration (Bedingtes E-Mail-Routing in Exchange Online). Dieser Ratgeber behandelt Exchange Server vor Ort, wo diese Option nicht existiert.

Nächste Schritte

Zwei Domänen, zwei Provider: Installieren Sie die 30-Tage-Testversion von MultiSendcon, lassen Sie den Installer den Sendeconnector anlegen, richten Sie je Provider ein SMTP-Konto mit Absendermaske ein und senden Sie aus jeder Domäne eine Testmail.
Nur ein Provider, aber mehrere Logins: dieselbe Einrichtung mit einem Konto je Login.
Ein Provider, ein Login, aber die Ablehnungen wegen leerem Absender: Die im Download enthaltene LITE-Edition ersetzt den leeren Absender und reicht für diesen Fall.

Häufig gestellte Fragen

Kann eine Transportregel in Exchange 2019 den Smarthost festlegen?

Nein. Eine Nachrichtenflussregel auf Exchange Server kann eine Nachricht ändern, umleiten oder ablehnen und Empfänger hinzufügen, aber sie kann keinen Sendeconnector und keinen Smarthost auswählen. Die Connector-Auswahl findet in der Routingauflösung der Kategorisierung statt und richtet sich nach Adressräumen, Kosten und Bereich der Sendeconnectoren. In Exchange Online ist das anders: Ein ausgehender Connector kann dort so eingestellt werden, dass er nur benutzt wird, wenn eine Transportregel Nachrichten an ihn umleitet. Deshalb hat dieselbe Frage in der Cloud eine eingebaute Antwort und lokal keine.

Warum routet ein zweiter Sendeconnector mit dem Adressraum * nicht nach Absender?

Beide Connectoren beanspruchen dasselbe Ziel, nämlich alle Domänen, und Exchange löst den Gleichstand über die Kosten auf; was bei gleichen Kosten entscheidet, betrachtet die Connectoren und die Topologie, nie den Absender. Die Absenderadresse fließt nicht in diese Entscheidung ein. Mail aller Absender landet bei dem Connector, der gewinnt, und der Provider, der nur seine eigenen Domänen erwartet, lehnt den Rest mit einem Authentifizierungs- oder Absenderfehler ab.

Kann ich stattdessen einen Open-Source-Mailserver vor Exchange setzen?

Ja, jedes SMTP-Relay, das absenderabhängigen Transport und Authentifizierung beherrscht, lässt sich zwischen Exchange und die Provider setzen; Exchange braucht dann nur einen Sendeconnector dorthin. Der Preis ist ein zweites Mailsystem mit eigenem Betriebssystem, Patches, Zertifikaten, Warteschlangen und Protokollen. Ein Connector-Dienst erledigt dasselbe Routing als Windows-Dienst auf dem Exchange-Server selbst, und die Exchange-Warteschlangenanzeige bleibt der eine Ort, an dem Sie nachsehen.

Warum lehnt IONOS Mail von meinen anderen Domänen ab?

Provider wie IONOS nehmen über ihr authentifiziertes SMTP-Relay nur Mail von Absenderadressen an, die zum Login gehören, und seit 2024 blockiert IONOS zusätzlich Nachrichten mit leerem Envelope-Absender, so wie Exchange Unzustellbarkeitsberichte und Abwesenheitsnotizen versendet. Jede Domäne über das Relay-Konto zu senden, zu dem sie gehört, löst das erste Problem; den leeren Absender durch eine feste Adresse zu ersetzen, das zweite. Beides ist auf den MultiSendcon-Seiten und in der Knowledge Base beschrieben.

Mehr zum ausgehenden Mailfluss im Exchange-Ratgeber oder in der Knowledge Base. In English: Exchange send connectors route by recipient domain, not sender.