Directory Based Edge Blocking (DBEB)

Exchange Online akzeptiert für eine eigene autoritative Domain trotzdem auch ungültige Empfänger und sendet einen NDR an den vorgebliche Absender. ich beschreibe, warum das so ist und wie sie es abschalten, nachdem Sie natürlich sichergestellt haben, dass wirklich alle Empfänger auch in der Exchange Online GAL vorhanden sind.

Wichtig: DBEB ist mittlerweile wohl für alle autoritativen Domains immer aktiv.

Beachten Sie dazu auch die Seite: EXO Antispam-Support zu Exchange Online und SPF, DKIM, DMARC, ARC, SRS, u.a.

Standardkonfiguration

Ich konnte es auch erst einmal nicht glauben, denn das Ablehnen von ungültigen Empfängern gehört doch zu guten Ton eines korrekt konfigurierten Mailserver. Wenn sich ein legitimer Absender bei der Adresse verschreibt, dann bekommt er eine Unzustellbarkeit von seinem eigenen System und das Zielsystem muss keinen NDR an den angeblich Absender erstellen. Da gibt es nämlich das Risiko, dass der Absender gefälscht ist und man selbst zum NDR-Spammer wird. Natürlich verrate ich damit dem Spammer welche Adressen ungültig sind aber das bekommt er über den NDR auch heraus oder es interessiert ihn eh nicht. Ich verliere also nichts, wenn ich eine Mail ablehne, die ich eh nicht zustellen kann. Siehe auch Spam und UCE - gültige Empfänger.

Erfahrene Exchange On-Premises Administratoren wissen sicher, dass bei Exchange On-Premises diese Funktion im Standard auch erst einmal abgeschaltet ist und manuell aktiviert werden muss (Siehe E2013 Recipient Filter), denn On-Premises hat Microsoft eine Exchange Edge Server für diese Aufgabe vorgesehen. Bei Exchange Online ist die Empfängerfilterung "vielleicht" aktiv. Dazu habe ich zwei Tests mit einem unverfälschten Tenant gemacht (Stand Fab 2023)gemacht. In Diesem Tenant gibt es zwei Domains:

Passend dazu gibt es auch Cloud-Only-Benutzer und ADSync-Benutzer mit Postfächern in der Cloud: Die Domains sind in Exchange Online alle als Autoritativ gelistet:

Zur Sicherheit habe ich noch beide Domänen per PowerShell "Get-AcceptedDomain" (https://learn.microsoft.com/en-us/powershell/module/exchange/get-accepteddomain) ausgegeben:

Einstellung msxfaqdev.onmicrosoft.com msxfaq.net 
DomainName                      
CatchAllRecipientID             
DomainType                      
MatchSubDomains                 
AddressBookEnabled              
Default                         
EmailOnly                       
ExternallyManaged               
RawAuthenticationType           
AuthenticationType              
LiveIdInstanceType              
PendingRemoval                  
PendingCompletion               
FederatedOrganizationLink       
MailFlowPartner                 
OutboundOnly                    
PendingFederatedAccountNamespace
PendingFederatedDomain          
IsCoexistenceDomain             
PerimeterDuplicateDetected      
IsDefaultFederatedDomain        
EnableNego2Authentication       
CanHaveCloudCache               
SendingFromDomainDisabled       
InitialDomain                   
AdminDisplayName                
ExchangeVersion                 
Name                            
Identity                        
OrganizationalUnitRoot          
Id                              
msxfaqdev.onmicrosoft.com

Authoritative
False
True
False
False
False
Managed
Managed
Business
False
False
Federation

False
False
False
False
False
False
False
False
False
True

0.20 (15.0.0.0)
msxfaqdev.onmicrosoft.com
msxfaqdev.onmicrosoft.com
msxfaqdev.onmicrosoft.com
msxfaqdev.onmicrosoft.com
 
msxfaq.net

Authoritative
False
True
True
False
False
Managed
Managed
Business
False
False
Federation

False
False
False
False
False
False
False
False
False
False

0.20 (15.0.0.0)
msxfaq.net
msxfaq.net
msxfaqdev.onmicrosoft.com
msxfaq.net

Die meisten Einstellungen sind hier also identisch. Nur die Einstellungen bei "InitialDomain" und "Default" sind unterschiedlich. Für die Domain "msxfaq.net" möchte Microsoft, dass ich folgenden MX-Record addiere:

Das kann ich machen, aber ich kann auch darauf verzichten, wenn ich beim Versender den Hostnamen direkt angeben. Per CURL sende ich nun Mails an die Domains.

Achtung: Prüfen Sie die Rückgaben genau, CURL zeigt nicht immer den kompletten Antwortstring sondern nur den Fehlercode an und es könnte sein, dass ihre Source-IP, z.B. auf einer RBL-Liste steht. Relativ sicher sind solche Tests von einer Azure-VM oder hinter einer statischer IP-Adresse.

Einstellung msxfaqdev.onmicrosoft.com msxfaq.net

Versand mit CURL aus einer CMD-Shell

 
curl smtp://msxfaq-net.mail.protection.outlook.com ^
   --mail-from frank@example.com ^
   --mail-rcpt invalid@msxfaqdev.onmicrosoft.com ^
   --upload-file body.txt

 
curl smtp://msxfaq-net.mail.protection.outlook.com ^
   --mail-from frank@example.com ^
   --mail-rcpt invalid@msxfaq.net ^
   --upload-file body.txt

Ergebnis

Wird mit "RCPT failed: 550" abgewiesen

Wird angenommen

SMTP Ergebnis

 
550 5.4.1 Recipient address rejected: Access denied. AS(201806281)
 
250 2.6.0 ....Queued mail for delivery

Wireshark-Trace

Obwohl beide Domain im Tenant gleich konfiguriert und insbesondere als "autoritativ" geführt werden, verhalten Sie sich bei der Empfängerprüfung unterschiedlich. Die für "invalid@msxfaq.net" angenommene Mail findet sich sogar im Messagetracking samt der erzeugten und zurückgesendeten NDR-Meldungen.

Sie sehen auch dass anscheinend ein paar Spammer wohl Mailadressen auf der msxfaq.de einsammeln und ausprobieren. Genau das ist aber das große Risiko, dass jemand z.B. eine Absenderadresse fälscht und massenhaft Mails zu Microsoft sendet, auf die Microsoft dann einen NDR an den vorgeblichen Absender zurücksendet.

Empfängerfilterung aktivieren

Warum Microsoft nur auf der eigenen Domain diese Empfängerfilterung bei Empfang aktiv hat, kann ich nur vermuten. Es mag ja Firmen geben, die eine Domain nicht nur bei einem System hosten, sondern weiterleiten. So ist es durchaus denkbar, dass eine Firma alle Mails zu Exchange Online sendet und über einen Outbound-Connector alle nicht zugestellten Mails zum nächsten Server weiterleitet. So kann man sich sie Mühe ersparen, in Exchange Online z.B. über Kontakte die Adressen richtig zu routen. Diese Funktion wird von Exchange sogar schon immer unterstützt, indem Sie eine Domain als "Internal Relay" konfigurieren können.

Ich rate von der Verwendung eines "Eimerkettenroutings" ab, da es Loops erzeugen kann und keine sichere Zustellung darstellt. Der erste Server einer Domain, der die Mails aus dem Internet annimmt, sollte eine Liste der gültigen Empfänger und deren finales Zielsystem kennen, optimiert routen und ungültige Empfänger direkt ablehnen.

Wenn Sie nun aber die Funktion auch für eigene Domains aktivieren wollen, dann gibt es auf Microsoft eine etwas ungewöhnliche Beschreibung.

Die Anleitung beschreibt ein geplantes Vorgehen.

Aktivieren Sie Schritt 3 erst, wenn Sie sicher sind, dass alle Empfänger auch wirklich in Exchange Online bekannt sind. Denken Sie auch an Objekte, die im Hybrid Mode durch ADSync vielleicht aufgrund der Konfiguration noch nicht synchronisiert werden, z.B. öffentliche Ordner, dynamische Verteilerlisten.
Siehe dazu auch Compare-GAL.

  1. Domain als "Internal Domain" setzen
    Zuerst werden Sie darum gebeten, die Domain als "Internal Relay" zu setzen
  2. Empfänger addieren
    Dann sollte man sicherstellen, dass alle Empfänger auch in der Exchange Online GAL vorhanden sind, z.B.: durch ADSync, als Kontakte o.ä.
  3. Domain als "Autoritative" setzen
    Damit wird Exchange dann angewiesen, dass er alle Empfänger kennt und alle anderen abgewiesen werden.

Achtung: Die Änderung wird quasi sofort aktiv. Bei mir hat die Umstellung von "internal Relay" auf "authoritative" nur weniger Sekunden benötigt.

Microsoft weist dabei aber selbst darauf hin, dass die Liste der Empfänger in Exchange Online nicht immer von alleine vollständig ist. Das betrifft z.B.

  • On-Premises: Dynamische Verteiler
    Diese werden von ADSync nicht als Kontakte ins AzureAD und damit Exchange Online repliziert. Sie müssten dafür manuell Kontakte anlegen.
  • On-Premises: Mailaktivierte öffentliche Ordner
    Auch diese Objekte werden von ADSync ignoriert und sie müssen entsprechende Kontakte anlegen.

Die Filterung durch Exchange Online funktioniert natürlich nur, wenn der MX-Record auch zu Exchange Online gesetzt wird.

Wichtig: DBEB ist mittlerweile wohl für alle autoritativen Domains immer aktiv

Mit der Umschaltung einer Domain von "Internal Relay" zu "Authoritative" wird dann die Filterung per DBEB aktiv. Also habe ich die Domain im Exchange Admin Center erst auf "Internal Relay" gestellt

Achtung: Die Funktion das Relay auf Unterdomains zu erweitern gibt es nicht bei "Autoritativ" Wenn Sie z.B. ihre Teams-Adressen auf eine Subdomain umlenken, dann können Sie die Filterung nur auf die Hauptdomain konfigurieren.

Kontrolle

Dass die Änderungen greifen, können Sie wieder mit einer Test-Mail an einen ungültigen Empfänger prüfen.

curl smtp://msxfaq-net.mail.protection.outlook.com ^
   --mail-from frank@example.com ^
   --mail-rcpt invalid@msxfaq.net ^
   --upload-file body.txt

Diesmal wird auch diese Mail mit einem "550" abgelehnt, die vorher noch angenommen wurde

Natürlich finden Sie diesen "Versuch" dann auch nicht mehr im Messagetracking. Ich habe natürlich mit "Get-AcceptedDomain" noch einmal die Daten der Domain ausgelesen aber bist auf das "LastModified"-Feld hat sich nichts sichtbar geändert.

Ich habe bislang keinen Weg gefunden, eine aktive DBEB-Filterung zu erkennen. Wenn Sie diese aber abschalten wollen, dann stellen Sie die Domain einfach wieder auf "internal Relay" um.

DBEB abschalten

Wenn ich das Verhalten aber wieder abschalten will, dann brauche ich die Domain einfach auf "Internal Relay" zuzustellen Exchange nimmer dann Mails für jeden Empfänger dieser Domain an und versucht sie intern neu zuzustellen. Allerdings weist mit zumindest die PowerShell bei der Umkonfiguration auf einen wichtigen Sachverhalt hin:

PS C:\> set-acceptedDomain msxfaq.net -DomainType internalrelay
WARNING: Es ist kein ausgehender Connector vorhanden, der E-Mail für diese Domäne zustellt. 
Vergewissern Sie sich, dass ein ausgehender Connector vom Typ \"On-Premises\" vorhanden ist, 
der jede akzeptierte "interne Relaydomäne" zuordnet. Für den Connector kann entweder das 
Flag \"AllAcceptedDomains\" aktiviert sein, oder er verfügt über eine Empfängerdomäne, 
die mit der akzeptierten Domäne übereinstimmt.

Ich sollte Exchange Online schon einen Weg zeigen, wohin er Mails an solche nicht vorhandene Empfänger weiter sendet. Ein entsprechender Outbound-Connector mit dem eigenen Adressraum oder auch mit einem "*" als Adressraum sollten Sie auf jeden Fall anlegen, damit die Mail nicht im Kreis läuft oder NDRs erzeugt.

Im Exchange Admin Center (https://admin.exchange.microsoft.com) bekommen Sie diesen Hinweis nicht!

Wenn Sie unbedingt wieder den Ausgangszustand herstellen wollen, dann könnten Sie natürlich die DNS-Domain im Tenant entfernen und wieder neu hinzufügen. Aber das erscheint mir unsinnig.

Zusammenfassung

Bis ca. April 2023 mussten Sie als Administrator auch eine autoritative Domain einmal auf "internal relay" und wieder zurück stellen, damit DBEB aktiviert wurde. Dies hat Microsoft mittlerweile aber korrigiert, nachdem ich den Fehler gemeldet und mit dem Exchange Beta Engineer durchexerziert habe. Die Änderung wurde wohl auch für alle Bestand-Tenants aktiviert. Nun gilt, dass Mails an Empfänger einer "authorisierten Domain" von Exchange Online nur noch angenommen werden, wenn es den Empfänger auch gibt. Wer nicht sicher ist, dass alle Empfänger in Exchange Online bekannt sind, sollte die Domains auf "internal Relay" umstellen und einen Outbound-Connector zu einem Mailservice einrichten, der alle Empfänger kennt.

Weitere Links