Zum Hauptinhalt springen
CaptainDNS

Senden von Aliasen in Exchange Online: Jede akzeptierte Domain wird zur Absenderdomain

Von CaptainDNS
Veröffentlicht am 11. Oktober 2026

Aktualisiert am 11. Oktober 2026

Schema eines Exchange-Online-Postfachs mit einer primären Adresse und zwei Aliasen auf anderen Domains; über einen der Aliase wird eine Nachricht verschickt

Bisher diente ein Exchange-Online-Alias nur zum Empfangen, wie die Microsoft-Ankündigung vom 7. Oktober 2026 festhält: "Previously, aliases could only receive mail, and all outgoing messages used the primary SMTP address of the mailbox." Das Senden von einem Alias ist jetzt allgemein verfügbar: Domains, die noch nie eine Nachricht verschickt haben, können nun im From: Ihrer ausgehenden E-Mails auftauchen.

TL;DR
  • Exchange Online erlaubt das Senden von jedem Alias (Proxyadresse) eines Postfachs. Die Einstellung gilt für den gesamten Tenant und kann bis zu 60 Minuten brauchen, bis sie greift.
  • Jede akzeptierte Domain mit Aliasen kann dann im From: erscheinen: Prüfen Sie SPF, DKIM und DMARC vor der Aktivierung, oder sperren Sie den Versand für diese Domain (Receive Only, SendingFromDomainDisabled).
  • Überprüfen Sie Nachrichtenfluss-, Journal- und Hygieneregeln. Suchen Sie in Message Trace nach dem Alias.

Prüfen Sie DMARC für jede Alias-Domain

Mein DMARC prüfenMein SPF prüfen

Was Microsoft ändert: Senden von einer Proxyadresse

Laut der Ankündigung des Exchange-Teams erlaubt die Funktion den Nutzern, "to send emails from any alias (proxy address) associated with their mailbox, not just their primary SMTP address". Ein Postfach julie@contoso.com, das auch julie@contoso.de und julie@alte-marke.com trägt, kann von jeder dieser Adressen schreiben.

Antworten folgen dem: "Replies automatically use the alias the message was sent to". Eine an julie@contoso.de eingegangene Nachricht wird von dieser Adresse aus beantwortet, ohne dass der Nutzer etwas auswählt. So verlassen E-Mails das Unternehmen über Domains, die niemand vorbereitet hat.

Nach einer öffentlichen Vorschau seit Januar 2022 wird die Funktion mit dieser Ankündigung allgemein verfügbar.

Das gilt nur für Exchange-Online-Postfächer. In Hybridumgebungen trägt eine Nachricht, die von der lokalen Umgebung an Exchange Online gesendet wird, die Routingadresse des Nutzers auf der onmicrosoft.com-Domain des Tenants (Beispiel von Microsoft: mail.contoso.onmicrosoft.com). Ist das Senden von Aliasen aktiviert, behält Exchange Online diese Adresse bei, statt sie durch die primäre Adresse zu ersetzen. Eine Abwesenheitsnotiz kann dann von der Routingadresse aus verschickt werden. Damit automatische Antworten diese Adresse nicht mehr verwenden, verweist Microsoft auf eine Änderungsanfrage (DCR) beim Outlook-Team. Bei einem freigegebenen Postfach funktioniert das Senden von einem Alias nur in Outlook im Web (OWA) über "Open another mailbox", nicht im Outlook-Client.

Aktivieren: eine Einstellung für den gesamten Tenant

Die Aktivierung erfolgt in Exchange Online PowerShell:

Set-OrganizationConfig -SendFromAliasEnabled $True

Die Einstellung gibt es auch im Exchange Admin Center (EAC): Settings > Mail Flow, Option "Sending from Aliases". Microsoft warnt: "It might take up to 60 minutes for this change to take effect in your tenant."

Steht sie auf $True, können alle Aliase des Tenants als Absenderadresse dienen, unabhängig von ihrer Domain. Der von Microsoft dokumentierte Hebel besteht darin, den Versand für eine ganze Domain zu sperren (siehe unten). Für feinere Einschränkungen, etwa für einen einzelnen Alias oder Nutzer, verweist die Ankündigung auf Nachrichtenflussregeln oder auf eine interne Richtlinie, an die sich die Nutzer halten sollen.

Jede Domain mit Aliasen wird zur Absenderdomain

Erfassen Sie die akzeptierten Domains des Tenants: alter Markenname, übernommenes Unternehmen, Länderdomains, defensive Domains gegen Typosquatting. Diese Domains empfangen seit Jahren E-Mails, ohne dass jemand gefragt hätte, ob sie auch senden können. Jetzt können sie es.

Die Domain des Alias wird zur Domain des sichtbaren From: (5322.From), anhand derer die Empfänger DMARC auswerten. Die DMARC-Dokumentation von Microsoft hält fest: DMARC besteht, wenn SPF oder DKIM erfolgreich ist und auf diese Domain ausgerichtet ist, und eine DKIM-Signatur ist nur dann ausgerichtet, wenn sie die benutzerdefinierte Domain verwendet.

Für jede betroffene Domain gibt es drei Prüfungen:

PrüfungWas Sie sehen solltenWenn nicht
DKIMSignatur in Exchange Online für diese Domain aktiviertDie Signatur trägt nicht den Namen der Domain und kann nicht ausgerichtet sein
SPFEin veröffentlichter SPF-Eintrag, der Exchange Online autorisiert (include:spf.protection.outlook.com)Die Domain autorisiert die Server nicht, die für sie senden
DMARCEin veröffentlichter _dmarc-Eintrag mit einer rua-Adresse für die BerichteKeine Richtlinie, die greifen könnte, und keine Berichte, die zeigen, was hinausgeht

DKIM zuerst: Eine mit der Alias-Domain erstellte Signatur ist der verlässliche Weg zum DMARC-Alignment. SPF ist nur ausgerichtet, wenn die Envelope-Adresse (5321.MailFrom) dieselbe Domain trägt; prüfen Sie das an einer Testnachricht vom Alias, im Feld smtp.mailfrom des empfangenen Headers.

Um DKIM für eine Alias-Domain zu aktivieren, folgen Sie unserem Leitfaden DKIM auf Office 365 und Google Workspace, und prüfen Sie anschließend mit dem DKIM-Selektor-Finder, ob auf dieser Domain Selektoren antworten.

Ohne ausgerichtete Signatur und ohne ausgerichtetes SPF schlägt DMARC fehl; veröffentlicht die Domain p=quarantine oder p=reject, kann der Empfänger die Nachricht in Quarantäne stellen oder ablehnen. Bei einem Empfänger auf Microsoft 365 zeigt sich der Fehler auch im zusammengesetzten Urteil (siehe compauth=fail bei Microsoft 365). Der tückischste Fall ist eine defensive Domain, die bereits auf p=reject steht, ohne DKIM und ohne SPF-Eintrag, der Exchange Online autorisiert. Gegen Spoofing ist sie gut geschützt, doch die legitimen Nachrichten Ihrer Nutzer fallen dann bei DMARC durch und können abgelehnt werden.

Vorher und nachher: Akzeptierte Domains, die nur empfangen haben, können nach der Aktivierung des Sendens von Aliasen auch senden, jede mit eigenen SPF-, DKIM- und DMARC-Prüfungen, außer der auf Receive Only gesetzten Domain

Den Versand für nicht vorbereitete Domains sperren

Für eine Domain, die empfangen, aber nie senden soll, schlägt Microsoft vor, sie mit dem Parameter SendingFromDomainDisabled von Set-AcceptedDomain auf "Receive Only" zu setzen. Laut der Dokumentation dieses Cmdlets verhindert der Parameter mit dem Wert $true den Versand von Adressen der Domain; der Empfang hängt von einem eigenen Parameter ab, SendingToDomainDisabled, den dieser Befehl nicht verändert:

Set-AcceptedDomain -Identity alte-marke.com -SendingFromDomainDisabled $true

Tun Sie das vor der Aktivierung von SendFromAliasEnabled, für jede Domain, deren SPF, DKIM und DMARC noch nicht bereit sind: Die Domain behält ihre Aliase und ihren Empfang, der von SendingToDomainDisabled abhängt, kann aber nicht mehr als Absenderadresse dienen. Für defensive Domains und aufgegebene Marken ist das die richtige Standardeinstellung.

Nach der Aktivierung: Regeln, Message Trace und DMARC-Berichte

Microsoft warnt: "Rules set up that do not account for aliases such as journaling or routing rules, may not work as expected." Die Ankündigung nennt Hygiene, Journaling und Nachrichtenflussregeln. Eine Transportregel, die Nachrichten von julie@contoso.com einen rechtlichen Hinweis anhängt, übergeht womöglich die von julie@contoso.de: Gehen Sie jede Regel durch, die nach dem Absender filtert.

In Message Trace findet eine Suche nach der primären Adresse laut Microsoft keine Nachrichten, die von einem Alias gesendet wurden: Suchen Sie nach dem Alias. Informieren Sie den First-Level-Support, bevor ein Ticket "meine Nachricht ist nie rausgegangen" im Kreis läuft.

Verfolgen Sie in den ersten Wochen die aggregierten DMARC-Berichte jeder geöffneten Domain: Welche Quellen senden mit ihr, und ist DKIM ausgerichtet? Die DMARC-Auswertung von CaptainDNS bündelt sie. Für eine Stichprobe senden Sie eine Testnachricht an ein externes Postfach und fügen den empfangenen Header in die Mail-Header-Analyse ein: Suchen Sie nach dkim=pass mit header.d auf der Alias-Domain.

Die Schritte in dieser Reihenfolge:

  1. Die akzeptierten Domains mit Aliasen auflisten und für jede entscheiden, ob der Versand geöffnet oder gesperrt wird.
  2. Gesperrte Domains: SendingFromDomainDisabled auf $true setzen.
  3. Geöffnete Domains: DKIM aktivieren, dann SPF und DMARC mit dem DMARC-Eintrags-Prüfer kontrollieren.
  4. SendFromAliasEnabled aktivieren, bis zu 60 Minuten warten, jede Domain testen.
  5. Nachrichtenflussregeln überprüfen und den Support zu Message Trace informieren.

FAQ

Funktioniert das Senden von einem Alias mit einem freigegebenen Postfach?

Ja, aber nur in Outlook im Web (OWA), wenn Sie das freigegebene Postfach über "Open another mailbox" öffnen. Der Outlook-Client erlaubt es für freigegebene Postfächer nicht.

Muss DKIM für jede Alias-Domain einzeln aktiviert werden?

Ja. Ohne aktiviertes DKIM für die Alias-Domain trägt die Signatur nicht die Domain des From: und kann für DMARC nicht ausgerichtet sein.

Wie sperren Sie den Versand von einer akzeptierten Domain, ohne den Empfang zu unterbrechen?

Microsoft schlägt vor, sie auf "Receive Only" zu setzen: Set-AcceptedDomain -Identity <Domain> -SendingFromDomainDisabled $true. Laut der Dokumentation von Set-AcceptedDomain verhindert dieser Parameter den Versand von Adressen der Domain; der Empfang hängt von einem eigenen Parameter ab, SendingToDomainDisabled, und die Domain empfängt weiterhin auf ihren Aliasen.

Verwandte Anleitungen

Quellen

Ähnliche Artikel