Vorsicht Falle! Wie das Senden von Aliasen dazu führen kann, dass E-Mail-Filter-Richtlinien nicht mehr greifen
Krähe mit Hut
Das Senden von einem Alias ist eine feine Sache! Vorbei die Zeiten, in denen Benutzer mehrere Postfächer verwenden mussten (oder man über das IMAP-Protokoll eine Hintertür gebaut hat), wenn sie für ihr eigenes Postfach mehrere Absenderadressen verwenden wollen/müssen.
So etwas kann beispielsweise in folgenden Szenarien notwendig sein:
- Ein Mitarbeitender hat aufgrund eines Namenswechsels (Heirat, Scheidung, etc.) eine neue E-Mail-Adresse, möchte Kontakte aber noch von der alten E-Mail-Adresse aus über die Änderung informieren.
- Benutzer wurden auf eine neue Absenderdomäne umgestellt (bspw. im Rahmen eines Unternehmenszukaufs oder einer Aufteilung) und müssen noch unter der alten Adresse erreichbar sein und E-Mails versenden.
Während Exchange Server diese Funktion nach wie vor nicht anbietet, kann sie in Exchange Online mit einem Klick (oder PowerShell-Befehl) aktiviert werden. Der Benutzer kann dann einfach die alternative Absenderadresse in seinem Outlook auswählen und Mails versenden.
Solange die Mails dann direkt von Exchange Online bzw. über ein Drittherstellersystem versendet werden, funktioniert dies reibungslos. Eine Besonderheit entsteht jedoch, wenn Exchange Server in den Nachrichtenfluss eingebunden ist.
In diesem Artikel beschreibe ich Besonderheiten, die in hybriden Exchange-Umgebungen (also Exchange Server + Exchange Online) auftreten können, wenn die Funktion "Senden von Alias" aktiviert ist.
Nachrichtenfluss in hybriden Umgebungen
Bevor wir zu den Besonderheiten kommen, soll kurz erklärt werden, wie der Nachrichtenfluss in einer hybriden Exchange-Umgebung funktioniert:
Innerhalb einer hybriden Exchange-Organisation wird eine sogenannte Remoteroutingdomäne verwendet. Diese ist an der Syntax ...mail.onmicrosoft.com erkennbar.
Jedes Postfach in der Organisation verfügt über einen Alias mit dieser Domäne. Exchange Server/Online kann anhand dieses Aliases die Mails korrekt weiterleiten, auch wenn sich das Postfach nicht in der gleichen Organisation (lokal oder Cloud) befindet.
Im Empfänger-Postfach wird die Adresse vom Alias wieder auf die primäre E-Mail-Adresse des Empfängers geändert. Auf diese Weise ist der Prozess für die Benutzer transparent und die Remoteroutingadresse nicht sichtbar.
Aktivierung der Funktion "Senden von Alias"
Die Aktivierung dieser Funktion ist zur Abwechslung relativ einfach:
- Exchange Online Admin Center aufrufen: Exchange admin center
- "Nachrichtenfluss" auswählen
- Unter "Allgemein" den Haken bei "Senden von Alias aktivieren" setzen und unten "Speichern" anklicken.
PowerShell:
# Zu Exchange Online verbinden
Connect-ExchangeOnline -ShowBanner:$False
# Senden von Alias aktivieren
Set-OrganizationConfig -SendFromAliasEnabled $TrueBesonderheiten in Verbindung mit dem Senden von einem Alias
Die Funktion "Senden von Alias" führt hier zu einem besonderen Verhalten. Der Prozess zur Anpassung der Remoteroutingadresse auf die eigentliche Empfängeradresse funktioniert nicht mehr. Microsoft hat dieses Problem bereits bestätigt, es gibt jedoch nach wie vor (Juni 2026) noch keine Lösung dafür: Sending From Email Aliases – Public Preview | Microsoft Community Hub
Dies hat einige Auswirkungen, die in der Folge beschrieben werden.
Abwesenheitsnachrichten
Hat ein Mitarbeitender für sein Postfach den Abwesenheitsassistenten konfiguriert und versendet automatische Antworten an Sender, so wird dem Absender in der Abwesenheitsnachricht die Remoteroutingadresse (...mail.onmicrosoft.com) statt der primären E-Mail-Adresse des Postfachs (...@contoso.com) angezeigt.
Dies ist aus folgenden Gründen problematisch:
- Der Absender erhält eine Adresse, die nicht für den E-Mail-Versand bestimmt ist. Zwar kann der Absender auch an diese Adresse Nachrichten senden, allerdings entspricht dies nicht dem vorgesehenen Zweck.
- Microsoft hat bereits angekündigt, die produktive Verwendung solcher Domänen einzuschränken (Limiting Onmicrosoft Domain Usage for Sending Emails | Microsoft Community Hub). Es ist daher denkbar, dass das Senden von E-Mails von extern zu einem späteren Zeitpunkt nicht mehr funktionieren wird
- Es wird eine potenziell als sensibel einzustufende Information herausgegeben. Die Remoteroutingdomäne (contoso.mail.onmicrosoft.com) entspricht im Grunde der MOERA-Domäne (contoso.onmicrosoft.com; Microsoft Online Email Routing Address) des Mandanten, welche bei der Erstellung des Mandanten initial angelegt wird. Dies erlaubt daher Rückschlüsse auf den Mandanten und die Zugriffs-URLs für die Microsoft 365-Dienste (bspw. für das SharePoint Admin Center).
Hierfür gibt es aktuell keine funktionierende Umgehungslösung. Es bestehen nur die folgenden Möglichkeiten:
- Exchange Server ablösen und Mails direkt von Exchange Online versenden lassen bzw. Exchange Server nicht mehr als Mail-Relay einsetzen.
- Funktion "Senden von Alias" deaktivieren, falls die Entfernung von Exchange Server nicht möglich ist.
E-Mail-Filterung in Exchange Online Protection und Defender for Office 365
Exchange Online bietet mit Exchange Online Protection (EOP) einen integrierten Schutz gegen Spam, Malware und Phishing. Defender for Office 365 (MDO) fügt noch einen Schutz gegen schädliche Links und Anhänge hinzu.
Werden diese Dienste aktiv (anstelle oder zusätzlich zu Drittherstellerprodukten) genutzt, so werden üblicherweise entsprechende benutzerdefinierte Richtlinien erstellt.
Da solche Richtlinien möglichst umfassend angewendet werden sollen, werden üblicherweise die unternehmenseigenen Domänen in diesen Richtlinien hinterlegt, wie auf dem nebenstehenden Bild beispielhaft zu sehen.
Oft werden jedoch nur die benutzerdefinierten Domänen und nicht die MOERA- sowie die Remoteroutingdomäne hinzugefügt, da diese ja normalerweise nicht produktiv genutzt werden.
Ist die Funktion "Senden von Alias" aktiviert, so wird jedoch die Empfängeradresse des Mitarbeitenden wie oben beschrieben nicht mehr angepasst, sondern verbleibt auf der Remoteroutingdomäne. Dies hat dann wiederum zur Folge, dass die Richtlinien in EOP und MDO nicht mehr angewendet werden und somit auch schadhafte Mails zugestellt werden können. Ist dann auch noch die Junk-E-Mail-Funktion in Outlook deaktiviert (wie es oft gehandhabt wird, wenn andere Lösungen zum Einsatz kommen), so besteht keinerlei Schutz mehr!
Dies lässt sich jedoch zum Glück dadurch lösen, dass die Remoteroutingdomäne und idealerweise auch die MOERA-Domäne allen Richtlinien entsprechend hinzugefügt werden. Dann greift der Schutz auch für diese Domänen (und Aliase).
Hat Dir dieser Artikel gefallen? Lass es andere wissen!
