In vielen Tenants, die ich betreue, begegnet mir immer wieder dasselbe alte Sicherheitsproblem: Mails, die scheinbar von einer internen Domain kommen, in Wahrheit aber von außen über die MX-Endpunkte zugestellt werden. Genau das ist klassisches Direct Send. Angreifer nutzen diese Schwachstelle gern für Phishing, das täuschend echt wirkt, denn solche Nachrichten umgehen häufig sämtliche üblichen Anti-Spoofing-Maßnahmen und landen direkt im Postfach. Mit der neuen Option, Direct Send gezielt zu blockieren, schließt Microsoft diese Lücke jetzt. Viele Admins warten darauf schon sehr lange.

Direct Send öffnet Angreifern einen bequemen Weg für interne Phishing-Mails

Bei Direct Send geht eine Mail ohne Authentifizierung direkt an die MX-Adresse der eigenen Domain, und zwar mit einer eigenen Adresse als Absender. Viele Multifunktionsgeräte, Scanlösungen und Apps von Drittanbietern arbeiten so, weil sie keinen Authentifizierungsmechanismus mitbringen. Für Angreifer ist das eine Einladung: Sie können Phishing-Mails verschicken, die aussehen, als stammten sie von Kolleg:innen oder sogar von IT-Systemen. In der Praxis erlebe ich regelmäßig, dass solche Nachrichten auch dann durchkommen, wenn SPF, DKIM und DMARC für die eigene Domain sauber eingerichtet sind. Die übliche Empfehlung lautet seit Jahren, auf Direct Send zu verzichten und stattdessen Client Submission oder eigene Connectors einzurichten. Konsequent umgesetzt wurde das selten, mal aus Bequemlichkeit, mal wegen Altlasten bei Geräten und Anwendungen.

Reject Direct Send lehnt nicht authentifizierte Mails schon auf Transportebene ab

Ende April 2025 hat Microsoft die Public Preview für eine neue Einstellung gestartet. Mit RejectDirectSend lehnt Exchange Online serverseitig alle Mails ab, die von nicht authentifizierten Quellen am MX-Endpunkt eintreffen und eine akzeptierte Domain als Absender tragen. Es handelt sich dabei nicht um eine weitere SPF-, DKIM- oder DMARC-Funktion. Der Schutz greift vielmehr zusätzlich direkt auf der Transportebene. Ich halte das für einen großen Fortschritt: Fremde Systeme können damit keine internen Identitäten mehr vortäuschen, ganz gleich, wie die externen DNS-Einträge oder die Mailflow-Policy konfiguriert sind.

Eine gründliche Bestandsaufnahme zeigt, welche Systeme noch Direct Send nutzen

Vor dem Blockieren steht erst einmal Detektivarbeit an. In fast jeder größeren Umgebung gibt es noch Geräte oder Anwendungen, die hartnäckig per Direct Send verschicken. Welche das genau sind und aus welchen Netzbereichen sie senden, wissen die Verantwortlichen allerdings selten. Am zuverlässigsten findet man es mit einer gezielten Auswertung der Mailflow-Protokolle heraus. Unter Exchange Online Admin Center → Nachrichtenfluss → Nachrichtenablaufverfolgung (oder per PowerShell) lässt sich nach Nachrichten suchen, die ohne Authentifizierung und mit einer internen Domain als Absender eingegangen sind. In der Praxis gehe ich dabei so vor:

Tipp aus der Praxis: Nutzt die moderne Nachrichtenablaufverfolgung im Exchange Admin Center. Filtert nach Nachrichten, die euren Domainnamen als Absender tragen und bei denen keine Authentifizierungsmethode eingetragen ist. Auf diese Weise stoßt ihr auf die tatsächlichen Direct-Send-Absender. Wie das im Einzelnen funktioniert, beschreibt die offizielle Microsoft-Dokumentation.

Im Alltag zeigt sich dabei immer wieder, dass nicht nur die üblichen Verdächtigen wie Multifunktionsdrucker und Scanner Direct Send verwenden. Häufig tauchen auch Eigenentwicklungen oder ältere Systeme auf, manche davon sogar noch fest auf Port 25 eingestellt.

Geräte und Anwendungen müssen sich künftig authentifizieren

Wer Direct Send blockieren will, muss vorher seine Infrastruktur darauf vorbereiten. Die Alternativen sind bewährt, lassen sich aber nicht immer ohne Weiteres umsetzen:

  • SMTP AUTH Client Submission: Geräte oder Apps melden sich authentifiziert über smtp.office365.com an. Dafür muss SMTP AUTH für das jeweilige Konto aktiviert sein. Einzelheiten und Best Practices stehen in Microsofts Anleitung.
  • Partner-Inbound-Connector: Die Geräte senden über einen eigenen Connector, der per Zertifikat oder IP-Whitelist authentifiziert.
  • Azure Communication Services: Eine moderne Cloud-Lösung für Fälle, in denen die SMTP-Varianten nicht genügen.

Wichtig ist am Ende nur eines: Bei Exchange Online dürfen keine unauthentifizierten Mails mit internem Absender mehr direkt ankommen. SPF, DKIM und DMARC sind dafür eine gute Grundlage, ganz geschlossen wird die Lücke aber erst mit dieser neuen Funktion. Wie ihr die DNS-Einträge für SPF, DKIM und DMARC richtig setzt, beschreibe ich im Beitrag SPF, DKIM & DMARC für Exchange Online: DNS richtig einrichten.

Für die eigentliche Umstellung genügt ein einziger PowerShell-Befehl

Sobald die Bestandsaufnahme erledigt ist und alle verbliebenen Direct-Send-Absender umgestellt sind, könnt ihr die neue Einstellung aktivieren. Das ist derzeit nur per PowerShell möglich. Ihr braucht dafür die Rolle „Organization Management“ oder vergleichbare Berechtigungen in Exchange Online.

# PowerShell 7, Exchange Online Management Modul v3+
Set-OrganizationConfig -RejectDirectSend $true

Von da an lehnt Exchange Online alle Direct-Send-Mails ab, die von außen an eine akzeptierte Domain gehen und diese Domain als Absender verwenden. Unbemerkt im Postfach landen sie damit nicht mehr. Das folgende Mermaid-Diagramm zeigt vereinfacht, wie die Entscheidung im Mailflow fällt:

flowchart TD
    A["Mail von extern an MX"] --> B["Absender = akzeptierte Domain?"]
    B -->|"Nein"| G["Mailfluss normal"]
    B -->|"Ja"| C["Authentifizierung vorhanden?"]
    C -->|"Ja"| G
    C -->|"Nein"| D["Reject Direct Send aktiv?"]
    D -->|"Nein"| G
    D -->|"Ja"| E["Mail wird abgelehnt"]

Abbildung: Entscheidungsbaum für Reject Direct Send in Exchange Online.

Die Einstellung greift sofort. Für viele Admins ist sie ein spürbarer Gewinn, wenn es darum geht, internes Phishing abzuwehren.

Ich würde Reject Direct Send zügig, aber mit Umsicht einführen

Für mich gehört Reject Direct Send zu den wichtigsten Neuerungen im Mailflow der letzten Jahre. Die Funktion löst ein grundlegendes Problem, das sich bislang nur mit aufwendigen Workarounds und ständiger Überwachung einigermaßen beherrschen ließ. Wer seine Infrastruktur auf SMTP AUTH oder abgesicherte Connectors umstellt, erhöht die Sicherheit und behält zugleich die Kontrolle über die Mails, die das eigene Haus verlassen. Plant diesen Schritt am besten jetzt ein, aktiviert die Einstellung aber erst, wenn ihr alle Direct-Send-Nutzer sauber ermittelt und umgezogen habt. Mehr zu SMTP AUTH und zur Lizenzierung lest ihr im Artikel SMTP AUTH mit Basic Authentication: Exchange Online stellt sie ein.