E-Mail-Versand über Exchange Online – Möglichkeiten und Alternativen
Im Zuge einer Migration von Exchange Server zu Exchange Online stellt sich irgendwann unweigerlich eine Frage:
„Können alle unsere Apps und Systeme E-Mails über Exchange Online senden oder müssen wir dafür weiter unseren Exchange Server verwenden?“
Wie so oft gibt es auf diese Frage keine pauschale Antwort. Es kommt vielmehr auf mehrere Faktoren an, ob diese Frage mit „Ja“, „Teilweise“ oder „über Alternativen“ beantwortet werden kann.
Dieser Artikel zeigt die Möglichkeiten und potenzielle Alternativen auf, um den E-Mail-Versand von Apps und Systemen von Exchange Server hin zur Microsoft Cloud zu migrieren.
Die grundlegende Problematik
An Exchange Server lässt sich im Grunde alles anbinden – es muss nur SMTP sprechen können (bzw. IMAP/POP für das Abholen von Mails).
Eine Authentifizierung wird nicht zwingend vorausgesetzt. Ebenso ist kein TLS zwingend erforderlich, sofern ich nicht selbst bestimmte Vorgaben erzwinge. Und Massenmails setzt nur die Leistungsfähigkeit des/der Server(s) eine Grenze.
In Exchange Online sieht dies etwas anders aus:
- Mindestens TLS 1.2
- Kein Massenmail-Versand (abhängig davon, was man selbst als „Masse“ ansieht)
- Moderne Authentifizierung über OAuth, falls ein Postfach für den Versand genutzt werden soll*
Für all diese Punkte gibt es berechtigte Gründe. Diese einen Wechsel von Exchange Server zu Exchange Online in diesem Fall zwar schwerer – aber nicht unmöglich!
Möglichkeiten in Exchange Online
Es gibt natürlich weiterhin Möglichkeiten, um einen E-Mail-Versand über Exchange Online für Systeme zu realisieren, die keine oder nur eine Basisauthentifizierung beherrschen:
- SMTP-Relay (interne und externe Empfänger)
- Direktes Senden (nur interne Empfänger)
Die folgenden Kapitel beschreiben Details zu diesen Möglichkeiten.
SMTP-Relay
Ein SMTP-Relay in Exchange Online funktioniert im Grunde genauso wie in Exchange Server, wenngleich die Konfiguration wesentlich einfacher ausfällt:
Voraussetzungen:
- MX-Endpunkt der benutzerdefinierten Domäne, bspw. contoso-com.mail.protection.outlook.com [MX-Eintrag ermitteln]
- Port 25
- TLS 1.2 oder 1.3 erforderlich
- Verwendung einer akzeptierten Domäne
Vorgehensweise:
- Connector anlegen (wichtig: „Partnerorganisation“ auswählen, siehe den Hinweis unten)
- IP-Adressen oder Absenderdomänen eintragen, um das absendende System eindeutig zu identifizieren
- Funktion testen
Über ein SMTP-Relay können E-Mails sowohl an interne als auch an externe Empfänger gesendet werden.
Dies ist eine einfache Variante, um einem System den Versand zu erlauben, gleichzeitig aber die erlaubten Systeme zu beschränken. Um die Sicherheit etwas zu erhöhen, sollten TLS erzwungen und ein spezifischer Antragstellername hinterlegt werden.
Falls aufgrund technischer Einschränkungen nur IP-Adressen hinterlegt werden können, muss man sich des potenziellen Risikos bewusst sein – der Connector erlaubt sämtlichen Systemen, die sich hinter der öffentlichen IP befinden, einen unauthentifizierten E-Mail-Versand.
Dies lässt sich jedoch wiederum durch Beschränkung des Ports 25 auf die erlaubten Systeme mitigieren.
Direktes Senden
Direktes Senden ermöglicht wie das SMTP-Relay einen unauthentifizierten Versand über Exchange Online. Es ist jedoch hierfür kein expliziter Connector erforderlich. Dementsprechend sind auch die Anforderungen etwas geringer:
Voraussetzungen:
- MX-Endpunkt der benutzerdefinierten Domäne, bspw. contoso-com.mail.protection.outlook.com [MX-Eintrag ermitteln]
- Port 25
- TLS optional
- Verwendung einer akzeptierten Domäne
Diese Daten sind lediglich auf dem absendenden System zu hinterlegen und der E-Mail-Versand sollte direkt funktionieren. Wichtig: hierüber können nur interne Empfänger angesprochen werden!
Das folgende Bildschirmfoto zeigt exemplarisch eine Transportregel, die den Empfang von E-Mails über direktes Senden einschränkt:
Das Problem mit Massenmails
Die zuvor gezeigten Möglichkeiten sind eine schöne Alternative für Apps und Systeme, die nur in geringem Umfang E-Mails versenden. Für größere Sendeanforderungen, beispielsweise Newsletter, sind diese jedoch nicht geeignet.
Microsoft gibt keine genauen Grenzwerte an, allerdings ist davon auszugehen, dass die Grenzwerte recht niedrig angesetzt sind.
Je nachdem, welche Anforderungen diesbezüglich existieren, können die folgenden Dienste eine Möglichkeit darstellen.
E-Mails mit hohem Volumen (HVE)
In Exchange Online gibt es seit einiger Zeit den Dienst E-Mails mit hohem Volumen (HVE). Dieser ist explizit für einen massenhaften Versand von E-Mails ausgelegt.
Allerdings können auch mit diesem Dienst nur interne Empfänger angesprochen werden. Während der Testphase war es noch möglich, externe Empfänger anzusprechen, diese Möglichkeit hat Microsoft jedoch stillschweigend entfernt.
Eine weitere Besonderheit dieses Dienstes ist, dass er nutzungsbasiert abgerechnet wird. D.h. es wird nicht eine Lizenz gebucht, die monatlich/jährlich abgerechnet wird, sondern es wird nach dem Volumen versendeter E-Mails abgerechnet.
Hierfür wird ein Azure-Abonnement benötigt, über das die Abrechnung erfolgt. Dieses kann entweder von Microsoft direkt oder einem Cloud Service Provider bezogen werden.
HVE ist über zwei Authentifizierungsmethoden ansprechbar – für den Dienst werden eigene Konten innerhalb des Exchange Admin Centers angelegt:
- SMTP AUTH (d.h. klassische Basisauthentifizierung)
- Moderne Authentifizierung über OAuth
Damit eignet sich der Dienst nicht über Apps und Systeme, die keine Authentifizierung unterstützen. Allerdings greift hier die angekündigte Abschaltung von SMTP AUTH nicht. HVE wird auch über 2027 hinaus SMTP AUTH unterstützen.
Die mögliche Alternative: Azure Communication Services
Für lange Zeit waren die zuvor beschriebenen Varianten die einzige Möglichkeit, E-Mails über Exchange Online bzw. die Microsoft Cloud zu versenden (abgesehen von einer benutzerbasierten Authentifizierung).
Passte keine der Varianten, musste man entweder weiter einen lokalen Exchange Server oder eine Drittanbieter-Applikation betreiben oder auf SaaS-Angebote wie Sendgrid zurückgreifen.
Mittlerweile gibt es in Microsoft Azure jedoch ein Angebot, das explizit für Massenversand vorgesehen ist: die Azure Communication Services, kurz ACS.
Ähnlich wie HVE unterstützt ACS die folgenden Authentfizierungsmethoden:
- SMTP AUTH
- Moderne Authentifizierung mittels OAuth
Darüber hinaus werden noch die folgenden Authentifizierungsmethoden speziell für die Anbindung von Azure-Diensten unterstützt, diese sind jedoch in dem Kontext dieses Artikels nicht weiter relevant:
- Zugriffsschlüssel
- Entra ID
Schön hierbei ist, dass die ACS-Komponenten kostenlos aufgebaut werden und ohne Nutzung auch keine laufenden Kosten erzeugen. Erst der Versand von E-Mails erzeugt Kosten. Der Dienst kann also bedenkenlos aufgebaut und getestet werden.
Voraussetzungen
Für den Einsatz von ACS werden die folgenden Ressourcen benötigt:
- Azure-Abonnement für die Bereitstellung des Dienstes und aller zugehörigen Ressourcen
- App-Registrierung in Entra ID für die Bereitstellung von Kennwörtern (Client-Geheimnisse)
- Grundkenntnisse in der Bedienung von Azure
Optional: Einrichtung von Berechtigungen auf das Azure-Abonnement
selbst mit der Rolle Globaler Administrator verfügt man zunächst noch nicht über Berechtigungen auf das Abonnement. Mithilfe dieser Rolle kann man sich jedoch die Berechtigungen selbst erteilen.
Falls bislang noch kein Azure-Abonnement vorhanden war, muss zunächst der Zugriff auf das Abonnement eingerichtet werden.
Die folgenden Schritte zeigen dies einmal exemplarisch. Es wird jedoch vorsorglich darauf hingewiesen, dass in Produktivumgebungen ein angemessenes Rechte- und Rollenkonzept zu entwickeln und zu etablieren ist.
- Entra Admin Center aufrufen
- Unter der Überschrift Zugriffsverwaltung für Azure-Ressourcen den Schalter umlegen und unten auf Speichern klicken
- Azure-Portal in neuem Tab oder anderem Browserfenster aufrufen (in der Folge muss zwischen Entra ID und Azure gewechselt werden)
Hinweis: wenn hier noch keine Abonnements zu sehen sind, dann einmal vom Webportal ab- und wieder anmelden.
- Abonnement aufrufen zu Zugriffssteuerung (IAM) wechseln
- Oben auf Hinzufügen > Rollenzuweisung hinzufügen klicken
- Zum Reiter Privilegierte Administratorrollen wechseln und die Rolle Besitzer auswählen
- Oben auf den Reiter Mitglieder klicken
- Über + Mitglieder auswählen den eigenen Benutzer auswählen
- Oben zum Reiter Bedingungen wechseln
- Was Benutzer tun können > Benutzer das Zuweisen aller Rollen mit Ausnahme…
- Oben zum Reiter Zuweisungstyp wechseln
- Zuweisungstyp > Aktiv, Zuweisungsdauer > Permanent
- Oben zum Reiter Überprüfen und zuweisen wechseln
- Unten auf Überprüfen und zuweisen klicken.
Der eigene Benutzer verfügt nun über die notwendigen Berechtigungen zur Erstellung von Ressourcen im Azure-Abonnement.
Erstellung einer Ressourcengruppe
Ressourcen werden in Azure in sogenannten Ressourcengruppen organisiert. Diese sind vom Prinzip her mit klassischen Dateiordnern vergleichbar, die unterschiedliche Dateitypen enthalten.
Dementsprechend muss zunächst eine Ressourcengruppe erstellt werden, welche die Komponenten von ACS beinhalten wird:
- Abonnement-Übersicht in Azure aufrufen und Abonnement auswählen
- In der Navigationsleiste zu Ressourcengruppen wechseln
- Oben auf + Erstellen klicken
- Abonnement auswählen, falls noch nicht vorausgewählt und einen beliebigen Namen für die Ressourcengruppe vergeben. Die gewählte Region sollte sich möglichst nah am Nutzungsstandort befinden.
- Auf Überprüfen und erstellen klicken und anschließend unten auf Erstellen klicken
Nach einem kurzen Moment ist die Ressourcengruppe in der Liste sichtbar und kann aufgerufen werden.
Erstellung der ACS-Ressourcen
Als nächstes können die notwendigen Komponenten aus dem Azure-Marktplatz hinzugefügt werden:
- Innerhalb der Ressourcengruppe oben auf + Erstellen klicken
- Im Suchfeld oben Communication eingeben und aus den Suchergebnissen zunächst Communication Services auswählen
- Auf Erstellen klicken
- Beliebigen Namen für Resssource eingeben und als Data Location die Region auswählen, die dem Nutzungsstandort am nächsten ist, anschließend auf Review + Create klicken
- Auf Create klicken, um den Bereitstellungsprozess zu starten
Diese Schritte müssen anschließend für den Dienst Email Communication Services wiederholt werden. Die Ressourcengruppe sollte dann die beiden neu angelegten Ressourcen beinhalten.
Einrichtung der E-Mail-Konfiguration
Nun kann die E-Mail-Konfiguration eingerichtet werden. Zunächst muss eine Absenderdomäne hinzufügt werden. Hierfür ist es empfehlenswert, nicht die/eine produktive Domäne der Organisation, sondern eine eigene Domäne zu verwenden.
Dies vermeidet Probleme, falls durch den Einsatz von ACS die Reputation vorübergehend sinken sollte (was unwahrscheinlich, aber nicht ausgeschlossen ist).
- Zuvor angelegte Ressource für die Email Communication Services aufrufen
- Links zu Settings > Provision domains navigieren
- Oben auf + Add domain > Custom domain klicken
- Gewünschten Domänennamen zweimal eingeben, dann auf Confirm und anschließend auf Add klicken
- Warten, der Prozess beendet ist, anschließend auf Verify Domain klicken
- TXT-Eintrag kopieren und in der öffentlichen DNS-Zone hinzufügen, dann auf Next klicken
Wurde der Eintrag richtig hinterlegt, sollte der Domain status zu Verified wechseln. Anschließend müssen noch ein SPF-Eintrag und zwei DKIM-Einträge hinzugefügt werden.
Sind alle Einträge ordnungsgemäß validiert, kann die Domänenkonfiguration über den blau unterlegten Namen aufgerufen werden. Hier müssen nun die gewünschten Absenderadressen hinzugefügt werden:
- Zu Einstellungen > Email services > MailFrom addresses wechseln
- Mittels + Add die gewünschte(n) Absenderadresse(n) hinzufügen
Hinweis: falls die Schaltfläche + Add ausgegraut ist, so muss die Konfiguration über die Azure CLI erfolgen. Diese kann über das kleine PowerShell-Symbol oben rechts in der blauen Leiste aufgerufen werden.
Beim ersten Aufruf wird eventuell gefragt, ob ein Azure-Speicherkonto angelegt werden soll. Dies ist nicht notwendig. Als Sprache ist PowerShell auszuwählen.
# Ermitteln, ob mehr als ein Abonnement vorhanden ist
$Count = (Get-AzSubscription).Count
if ($Count -gt 1)
{
# Abonnement-Auswahl anzeigen
$Selection = (Get-AzSubscription | Out-GridView `
'Bitte Abonnement mit ACS-Komponenten auswählen' `
-OutputMode:Single).SubscriptionId
# Kontext wechseln
Set-AzContext $Selection
}
# Variablen abfragen
$ACSEmail = Read-Host 'Bitte gib den Namen der E-Mail-Ressource ein'
$ACSRG = Read-Host 'Bitte gib den Namen der Ressourcengruppe ein'
$Domain = Read-Host 'Bitte gib den Domänennamen ein'
$Prefix = Read-Host 'Bitte gib das Präfix der Absenderadresse ein (z.B. "scanner")'
$DisplayName = Read-Host 'Bitte gib den Anzeigenamen ein'
# Absenderadresse hinzufügenn
az communication email domain sender-username create --email-service-name $ACSEmail --resource-group $ACSRG --domain-name $Domain --sender-username $Prefix --username $Prefix --display-name $DisplayName
Falls weitere Absenderadressen hinzugefügt werden sollen, müssen lediglich die Zeilen 16-23 erneut ausgeführt werden.
Erstellung einer App-Registrierung
Für die Authentifizierung mittels SMTP AUTH werden Benutzername und Kennwort benötigt. Für die Bereitstellung von Kennwörtern nutzt ACS eine App-Registrierung in Entra ID.
Diese wird wie folgt erstellt:
- Assistenten für die Erstellung im Entra Admin Center aufrufen
- Beliebigen Namen vergeben und Registrieren anklicken
- App-Registrierung aufrufen
- In der Navigationsleiste zu Zertifikate & Geheimnisse wechseln
- Reiter Geheime Clientschlüssel aufrufen
Grundsätzlich reicht die Erstellung eines Kennworts für alle Absenderadressen. Es wird allerdings dringend empfohlen, pro Absenderadresse einen individuellen Clientschlüssel zu erstellen:
- Clientschlüssel laufen nach maximal 2 Jahren ab. Je mehr Systeme diesen verwenden, umso größer wird der Aufwand, diesen überall zu tauschen, bevor er abläuft.
- Über die Verwendung individueller Schlüssel wird indirekt dokumentiert, welche Systeme alle ACS verwenden.
Erteilung von Berechtigungen für die App-Registrierung
Die App-Registrierung muss Zugriffsberechtigungen auf die globale ACS-Komponente erhalten, damit ein E-Mail-Versand erlaubt werden kann. Hierzu ist wie folgt vorzugehen:
- Im Azure-Portal die zuvor angelegte Ressourcengruppe aufrufen und dort die Ressource Communication Service aufrufen (NICHT die Ressource Email Communication Service!)
- Links zu Zugriffssteuerung (IAM) wechseln
- Oben auf + Hinzufügen > Rollenzuweisung hinzufügen klicken
- In das Suchfeld den Begriff Communication eingeben und aus den Ergebnissen die Rolle Communication and Email Service Owner* auswählen
- Oben zum Reiter Mitglieder wechseln und als Mitglied die soeben angelegte App-Registrierung auswählen
- Unten auf Überprüfen und zuweisen klicken und anschließend erneut, um die Zuweisung zu speichern
Damit dürfen nun über die App-Registrierung E-Mails versendet werden.
Verbindung der E-Mail-Domäne mit ACS
Im nächsten Schritt muss eine Verbindung zwischen den beiden ACS-Komponenten hergestellt werden, damit ein E-Mail-Versand möglich wird. Hierzu ist wie folgt vorzugehen:
- Im Azure-Portal die zuvor angelegte Ressourcengruppe aufrufen und dort die Ressource Communication Service aufrufen (NICHT die Ressource Email Communication Service!)
- Links zu E-Mail > Domänen wechseln
- Oben auf Connect domains klicken und im Flyout-Menü entsprechend die zuvor hinzugefügten Ressourcen auswählen
- Unten auf Connect klicken
- Schritte ggf. für weitere Domänen wiederholen
Damit ist bzw. sind die Domäne(n) nun für ACS verfügbar.
Einrichtung eines SMTP-Benutzernamens
Als letzter Schritt muss ein SMTP-Benutzername angelegt werden, mit dem sich die Applikation bzw. das System zusammen mit dem Clientschlüssel authentifizieren kann. Hierzu ist wie folgt vorzugehen:
- Im Azure-Portal die zuvor angelegte Ressourcengruppe aufrufen und dort die Ressource Communication Service aufrufen (NICHT die Ressource Email Communication Service!)
- Links zu E-Mail > SMTP-Benutzernamen wechseln
- Oben auf + Add SMTP Username klicken
- Entra Application > zuvor angelegte App-Registrierung auswählen
- Username Type nach Wunsch auswählen und gewünschten Benutzernamen eingeben und mit Save bestätigen
Es spielt technisch gesehen keine Rolle, ob der Benutzername nur ein Text oder eine E-Mail-Adresse ist. Sofern das absendende System E-Mail-Adressen unterstützt, würde ich persönlich jedoch stets E-Mail-Adressen wählen, um eine Eindeutigkeit zu erhalten.
Im Bereich E-Mail > E-Mail testen kann geprüft werden, ob der Versand über ACS technisch problemlos möglich ist. Hier können auch Anhänge hinzugefügt werden. Außerdem werden Codebeispiele für unterschiedliche Sprachen bereitgestellt.
Und wenn wir lokal bleiben wollen/müssen?
Es gibt mittlerweile eine Vielzahl kostenpflichtiger und auch kostenloser Lösungen für die Bereitstellung eines lokalen E-Mail-Relays.
Neben bekannten Lösungen wie Postfix gibt es auch Windows-basierende Lösungen wie EmailRelay und MailEnable. Da die geeignete Lösung sehr stark von den individuellen Anforderungen der Organisation abhängt und dieser Artikel auf cloudbasierte Lösungen abzielt, wird hier keine vollständige Übersicht oder ein Vergleich zwischen Lösungen gegeben.
Tipps und Tricks
Ermittlung des MX-Eintrags für eine benutzerdefinierte Domäne
Normalerweise lässt sich der MX-Eintrag für eine benutzerdefinierte Domäne über das Microsoft 365 Admin Center ermitteln (> Domäne aufrufen, zu Tab DNS-Einträge wechseln, Wert für MX-Eintrag kopieren).
Falls diese jedoch nicht konfiguriert sind, kann es sein, dass dieser Reiter fehlt. In diesem Fall kann der MX-Eintrag alternativ über PowerShell ermittelt werden:
# Notwendige Module prüfen und installieren, falls nicht vorhanden
if (!(Get-InstalledModule 'Microsoft.Graph.Authentication'))
{
Write-Host 'Notwendiges Graph-Modul nicht gefunden, installiere...' -Foreground Color Yellow
Install-Module -Name 'Microsoft.Graph.Authentication'
}
if (!(Get-InstalledModule 'Microsoft.Graph.Identity.DirectoryManagement'))
{
Write-Host 'Notwendiges Graph-Modul nicht gefunden, installiere...' -Foreground Color Yellow
Install-Module -Name 'Microsoft.Graph.Identity.DirectoryManagement'
}
# Zu Microsoft Graph verbinden
Write-Host 'Verbinde zu Microsoft Graph...' -ForegroundColor Yellow
Connect-MgGraph -Scopes Domain.Read.All
# 'Ermittle MX-Eintrag für Standarddomäne...' -ForegroundColor Yellow
$DefaultDomain = (Get-MgDomain | Where-Object {$_.IsDefault -eq $True}).Id
$MxRecord = (Get-MgDomainServiceConfigurationRecord -DomainId $DefaultDomain | Where-Object {$_.RecordType -eq "Mx"}).additionalproperties.mailExchange
Write-Host "MX-Eintrag: $MxRecord" -ForegroundColor Green
# Trenne Verbindung zu Microsoft Graph
Write-Host ''
Write-Host 'Trenne Verbindung zu Microsoft Graph...' -ForegroundColor Yellow
Disconnect-MgGraph