True IT Stories

alle@ in Exchange Online einrichten

Im ersten Teil ging es darum, warum ich bei jedem Kunden eine Adresse alle@kunde.de einrichte, die jeden Mitarbeiter erreicht und trotzdem nur für interne Absender und uns offen ist (Eine Adresse für alle beim Kunden — und trotzdem kein Spam ). Hier die Umsetzung in Exchange Online — so, wie ich sie inzwischen bei jedem Kunden fahre.

Warum die Gruppe allein nicht reicht

Eine Verteilergruppe in Exchange Online hat nur einen Schalter: RequireSenderAuthenticationEnabled. Auf $true dürfen nur interne Absender schreiben, auf $false jeder — dazwischen nichts. AcceptMessagesOnlyFrom hilft nicht: Der Parameter akzeptiert nur Empfängerobjekte aus dem eigenen Tenant, keine fremde Domain.

Microsofts Lösung: Die Gruppe öffnet sich für externe Absender, eine Nachrichtenflussregel (Transportregel) davor weist alles ab, was nicht aus der Organisation oder einer freigegebenen Domain kommt. Sie greift vor der Zustellung — der externe Absender bekommt einen Unzustellbarkeitsbericht mit Begründung.

Voraussetzungen

  • Das Modul ExchangeOnlineManagement und Exchange-Admin-Rechte im Kundentenant.
  • Ein Testpostfach im Tenant, das niemand produktiv nutzt — bei jedem Kunden lege ich mir eins an.
  • Die Aliase der eigenen Admin- und Testkonten, die nicht im Verteiler landen sollen — vor dem Anlegen live prüfen, nicht aus dem Gedächtnis.

Schritt 1: Bestand aufnehmen

Vor dem Anlegen drei Dinge ansehen:

Get-DynamicDistributionGroup -Identity "alle@kunde.de" -ErrorAction SilentlyContinue
Get-DistributionGroup -Identity "Alle Mitarbeiter" -ErrorAction SilentlyContinue
Get-TransportRule | Select-Object Priority, Name, State
Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Measure-Object

Wichtig sind die Transportregeln: Eine bestehende Regel mit höherer Priorität kann die neue aushebeln, etwa eine, die Mails umleitet oder zulässt. Namen und Prioritäten notieren — so weiß man, wo die neue Regel einsortiert wurde.

Schritt 2: Dynamische Verteilerliste anlegen

Eine dynamische Verteilergruppe hat keine Mitgliederliste, sondern einen Filter, der bei jedem Versand ausgewertet wird:

New-DynamicDistributionGroup -Name "Alle Mitarbeiter" -Alias "alle" `
  -PrimarySmtpAddress "alle@kunde.de" `
  -RecipientFilter "(RecipientTypeDetails -eq 'UserMailbox') -and (Alias -ne 'adm_it') -and (Alias -ne 'test.postfach')"

Der Filter nimmt alle Benutzerpostfächer und schließt die Technikkonten aus; freigegebene Postfächer, Raumpostfächer und Kontakte sind keine UserMailbox und fallen automatisch raus.

Eine dynamische Gruppe zeigt ihre Mitglieder nicht direkt; zum Prüfen lässt man den Filter auswerten:

Get-Recipient -RecipientPreviewFilter (Get-DynamicDistributionGroup "alle@kunde.de").RecipientFilter -ResultSize Unlimited |
  Select-Object DisplayName, PrimarySmtpAddress

Die Anzahl muss der Zahl aus Schritt 1 minus den Ausschlüssen entsprechen; stimmt sie nicht, jetzt korrigieren — nicht erst nach dem ersten Versand.

Schritt 3: Gruppe öffnen und Schutzregel setzen

Zuerst die Gruppe für externe Absender öffnen:

Set-DynamicDistributionGroup -Identity "alle@kunde.de" -RequireSenderAuthenticationEnabled $false

Ab jetzt könnte jeder an alle@ schreiben — deshalb direkt danach die Regel:

New-TransportRule -Name "Alle-Mitarbeiter: nur intern und dienstleister.de" `
  -AnyOfToCcHeader "alle@kunde.de" `
  -ExceptIfFromScope InOrganization `
  -ExceptIfSenderDomainIs "dienstleister.de" `
  -RejectMessageReasonText "Diese Adresse akzeptiert nur Nachrichten interner Absender sowie des IT-Dienstleisters. Ihre Nachricht wurde nicht zugestellt." `
  -RejectMessageEnhancedStatusCode "5.7.1" `
  -Comments "Erlaubt externen Versand von dienstleister.de an alle@kunde.de. Eingerichtet 2026-08-13."

Die Logik ist einfacher, als es aussieht: Bedingung — die Nachricht hat alle@kunde.de in An oder Cc. Ausnahmen — der Absender ist intern, oder die Absenderdomain ist dienstleister.de. Aktion — ablehnen mit 550 5.7.1 und dem Begründungstext.

Zwei Anmerkungen: RejectMessageReasonText landet beim Absender im Unzustellbarkeitsbericht — so formulieren, dass er versteht, warum seine Mail nicht ankam. Und Comments ist keine Deko: In einem Jahr will jemand wissen, warum die Regel existiert und wer sie angelegt hat.

Soll später eine zweite Domain durch, etwa ein weiterer Dienstleister:

Set-TransportRule "Alle-Mitarbeiter: nur intern und dienstleister.de" -ExceptIfSenderDomainIs "dienstleister.de","partner.de"

Der Parameter ersetzt die Liste, statt sie zu ergänzen — wer nur die neue Domain angibt, sperrt sich selbst aus.

Schritt 4: Testen, ohne jemandem eine Testmail zu schicken

Diesen Schritt macht man leicht falsch: Wer die Produktionsregel testet, indem er an alle@ schreibt, schickt die Testmail an alle Mitarbeiter — das passiert genau einmal.

Stattdessen lege ich eine identische Regel auf das Testpostfach:

New-TransportRule -Name "TEST Absenderbeschraenkung (temporaer loeschen)" `
  -AnyOfToCcHeader "test.postfach@kunde.de" `
  -ExceptIfFromScope InOrganization `
  -ExceptIfSenderDomainIs "dienstleister.de" `
  -RejectMessageReasonText "TEST: nur intern und Dienstleister." `
  -RejectMessageEnhancedStatusCode "5.7.1"

Dann fünf bis zehn Minuten warten, bis die Regel verteilt ist, und zwei Mails schicken:

  1. Von einer privaten Fremdadresse — Gmail, GMX, egal — an test.postfach@kunde.de. Diese Mail muss mit 550 5.7.1 abgewiesen werden.
  2. Von einer Adresse der eigenen Domain an test.postfach@kunde.de. Diese Mail muss ankommen.

Beides im Message Trace nachsehen:

Get-MessageTraceV2 -RecipientAddress "test.postfach@kunde.de" -StartDate (Get-Date).AddHours(-1) -EndDate (Get-Date)

Beim abgewiesenen Versand muss im Detail-Trace TRANSPORT.RULES.RejectMessage mit dem Namen der Testregel stehen. Stimmen beide Ergebnisse, ist die Logik bewiesen — und weil die Testregel bis auf die Zieladresse identisch mit der Produktionsregel ist, gilt der Beweis für beide.

Schritt 5: Aufräumen und abnehmen

Remove-TransportRule -Identity "TEST Absenderbeschraenkung (temporaer loeschen)" -Confirm:$false
Get-DynamicDistributionGroup "alle@kunde.de" | Select-Object Name, RequireSenderAuthenticationEnabled, ModerationEnabled
Get-TransportRule | Select-Object Priority, Name, State

Der Endzustand: Die Gruppe hat RequireSenderAuthenticationEnabled = False und ModerationEnabled = False, von den Transportregeln steht nur noch die aktive Produktionsregel. Das kommt bei mir in die Ticket-Doku, zusammen mit der Mitgliederzahl aus Schritt 2.

Rückbau

Falls nötig, sind es zwei Zeilen — Regel zuerst, dann Gruppe:

Remove-TransportRule -Identity "Alle-Mitarbeiter: nur intern und dienstleister.de" -Confirm:$false
Remove-DynamicDistributionGroup -Identity "alle@kunde.de" -Confirm:$false

Teil 1 erklärt, warum diese Adresse überhaupt sinnvoll ist. Teil 3 sammelt fünf Stolpersteine, die mir dabei fast durchgerutscht wären.