Exchange Online:
Senden vom Alias

Kurz gesagt: Seit dem 7. Oktober 2026 können Benutzer in Exchange Online von jedem Alias ihres Postfachs senden und antworten, nicht mehr nur von der primären Adresse. Die Funktion wird mit einer einzigen mandantenweiten Einstellung aktiviert und funktioniert in Outlook im Web, Desktop und Mobile. Vor dem Einschalten lohnt sich jedoch ein Blick auf Nachrichtenregeln, Journaling, Nachrichtenablaufverfolgung, freigegebene Postfächer und die Authentifizierung sekundärer Domains.

Was sich ändert

In Exchange Online kann ein Postfach mehrere Adressen haben: die primäre und einen oder mehrere Aliase (Proxy- oder sekundäre Adressen), etwa info@, eine nach einer Namensänderung beibehaltene alte Adresse oder die Adresse auf einer zweiten Domain der Gruppe. Bisher konnten Aliase nur empfangen: Jede Antwort ging von der primären Adresse aus. Um wirklich von einer anderen Adresse zu schreiben, griff man auf freigegebene Postfächer oder Verteilergruppen mit Sendeberechtigung zurück.

Mit der Funktion „Sending from Aliases“, lange in der öffentlichen Vorschau und jetzt allgemein verfügbar, können Benutzer von jedem Alias senden, direkt in Outlook, vom Alias antworten, an den die Nachricht adressiert war, und in unterstützten Clients wählen, welche Aliase angezeigt werden. Für alle, die Microsoft 365 verwalten, ist das die Gelegenheit, Postfächer und Gruppen abzuschaffen, die nur als Notlösung existierten.

So wird es aktiviert

Die Einstellung gilt für den ganzen Mandanten und wird von einem Exchange-Administrator auf zwei gleichwertige Arten aktiviert: im Exchange Admin Center unter Einstellungen → Nachrichtenfluss, indem man „Sending from Aliases“ einschaltet; oder in Exchange Online PowerShell mit Set-OrganizationConfig -SendFromAliasEnabled $true. Laut Microsoft kann es bis zu 60 Minuten dauern, bis die Änderung wirksam wird.

Die Aliase der einzelnen Benutzer werden wie gewohnt im Microsoft 365 Admin Center verwaltet. Darf eine ganze Domain nicht senden (oder nicht empfangen), lässt sie sich mit den Parametern SendingFromDomainDisabled und SendingToDomainDisabled des Cmdlets Set-AcceptedDomain als „Receive-only“ oder „Send-only“ festlegen. Feinere Einschränkungen pro Benutzer oder pro Alias müssen mit Nachrichtenflussregeln oder internen Richtlinien umgesetzt werden.

Was Benutzer sehen

In allen Clients gehen Antworten automatisch vom Alias aus, an den die Nachricht adressiert war.

Vor dem Aktivieren: was zu prüfen ist

Microsoft selbst weist darauf hin, dass die Funktion das Verhalten von Exchange Online deutlich verändert und noch Randfälle auftreten können. Diese Punkte sollten geprüft werden:

• 1Regeln, die nach einer bestimmten Adresse suchen — Nachrichtenflussregeln, Journaling, Hygiene- und Routingregeln, die auf die primäre Adresse geschrieben sind, erkennen von einem Alias gesendete Nachrichten möglicherweise nicht und greifen dann bei einem Teil der E-Mails nicht.
• 2Nachrichtenablaufverfolgung — eine Suche nach der primären Adresse liefert keine von einem Alias gesendeten Nachrichten: Dafür muss der Alias verwendet werden. Der Support muss das wissen, sonst gilt eine Nachricht als „nie gesendet“, obwohl sie tatsächlich verschickt wurde.
• 3Hybridumgebungen — die Funktion gilt nur für in Exchange Online gehostete Postfächer. Sind noch lokale Server in Betrieb, können diese Aliase umschreiben, und Abwesenheitsnotizen können von der Routingadresse der Form mandantenname.mail.onmicrosoft.com statt von der Unternehmensdomain gesendet werden.
• 4Freigegebene Postfächer — das Senden von Aliasen funktioniert nur in Outlook im Web, wenn das Postfach über „Weiteres Postfach öffnen“ geöffnet wird. Im Outlook-Client wird es nicht unterstützt.
• 5Ein veränderter „Von“-Absender — waren in Outlook Adressen oder Anzeigenamen konfiguriert, die von denen des Postfachs abweichen, können gesendete Nachrichten nach der Aktivierung einen anderen Absender zeigen als zuvor.
• 6Authentifizierung sekundärer Domains — ein Alias auf einer anderen Domain versendet E-Mails im Namen dieser Domain. SPF, DKIM-Signatur und DMARC dieser Domain müssen auf Exchange Online ausgerichtet sein, sonst riskieren Nachrichten bei einer strengen DMARC-Richtlinie Quarantäne oder Ablehnung. Dieser Punkt steht nicht in der Microsoft-Ankündigung: Es ist die Prüfung, die wir ergänzen und die wir mit dem DMARC-Monitoring verfolgen.

Was noch fehlt

Die allgemeine Verfügbarkeit deckt die Kernfunktionen ab. Microsoft prüft nach eigenen Angaben, ohne sich zur Umsetzung zu verpflichten, drei Erweiterungen: einen eigenen Anzeigenamen pro Alias, zusätzliche Filter- und Standard-Alias-Steuerungen sowie die Unterstützung für den Kalender. Heute ist der Anzeigename also für alle Aliase des Postfachs gleich, und der Kalender wird von der Funktion noch nicht abgedeckt.

Wie wir vorgehen

Bevor wir die Funktion in den von uns verwalteten Mandanten aktivieren, prüfen wir: die Liste der verwendeten Aliase und Domains, Nachrichtenfluss- und Journalingregeln, die von der primären Adresse abhängen, freigegebene Postfächer, die nur zum Schreiben von einer anderen Adresse dienen, sowie die SPF-, DKIM- und DMARC-Einträge jeder Domain, die senden soll. Erst dann aktivieren wir, testen das Senden aus den Clients, die das Unternehmen tatsächlich nutzt, und zeigen den Benutzern, wo sie den Alias finden. Archiviert das Unternehmen seine E-Mails, prüfen wir außerdem, ob die E-Mail-Archivierung auch die von Aliasen gesendeten Nachrichten erfasst.

AtWorkStudio arbeitet seit dem Jahr 2000 in Piacenza. Wir sind zertifiziert nach ISO/IEC 27001, 27017, 27018 und ISO 9001, ACN-qualifiziert (Agenzia per la Cybersicurezza Nazionale, die italienische nationale Cybersicherheitsbehörde) für Cloud-Dienste, Mitglieder von Clusit (italienischer Verband für Informationssicherheit) und Confindustria Piacenza im RICT-Cluster zugeordnet.