Exchange DirectSend/RejectDirectSend
Seit Mai 2025 gibt es einen neuen Parameter "RejectDirectSend" in der Exchange Online Organisationseinstellung. Wie wirkt sich die Einstellung dieses neuen Parameters aus und warum sollten Sie diesen vom Default "$false" in ihrem Tenant auf "$true" setzen um ihre Anwender vor Phishing noch besser zu schützen.
Beachten Sie dazu auch die Seite HVE - High Volume Email mit Exchange, um ein hohe Anzahl von Mails an eigene Postfächer zu senden.
Ich habe das Thema auch als Audiodatei
für einen
Podcast
aufbereitet
directsend.mp3
Direct Send Exploited?
Haben Sie auch die Meldung im Juli 2025 über eine angebliche Sicherheitslücke in Exchange Online gelesen? Neu ist das aber alles nicht und habe ich auf Hybrid Hintereingang im Jahr 2017 und Exchange Online als Nebeneingang für Mailempfang im Jahr 2018 thematisiert. Jeder Exchange Online Anwender hat eine Mailadresse, die seinem UPN entspricht. Das ist einfach by Design so und von Microsoft auch beschrieben. Diese Adresse kennen Exchange Administratoren auch als MOERA - Microsoft Online Email Routing Address und ist für Migrationen und Koexistenz wichtig.
Seit Anbeginn von Office 365 hat Microsoft auch einen MX-Record für die Domain "<tenantname>.mail.onmicrosoft.com" und "<tenantname>.onmicrosoft.com" veröffentlicht und nimmt Mails dafür an. Exchange Online Protection versucht dabei einen Spamschutz zu realisieren. Insofern ist es nicht verwunderlich, dass mehr und mehr Spammer den regulären MX-Record einer Firmendomain mit leistungsfähigen Spamfilter wie NoSpamProxy u.a. umgehen wollen, indem Sie direkt an Exchange Online zustellen.
Das Phishing wird noch erleichtert, wenn Sie ihre eigene SMTP-Domain nicht durch SPF/DKIM/DMARC gesichert haben, weil der Exchange Online Spamschutz dann natürlich nicht so einfach gefälschte Mails ablehnen kann.
Hätten Sie ein "SPF -all"-Eintrag (Siehe SPF, DKIM und DMARC jetzt!) für ihre Domain und eine DMARC-Richtlinie "p=reject", könnte niemand über diese Hintertür eine Mail direkt an ihre Exchange Empfänger senden und dabei ihre eigene Absenderadresse verwenden. Ohne DMARC landen die Mails bei einem SPF-Hardfail im Junk-E-Mail-Ordner des Users.
Sie könnte natürlich auch den Hintereingang komplett mit einem Partner Connector blockieren aber das würde legitime Zustellungen ihrer Domain, z.B. von Scan2Mail-Diensten blockieren. Vielleicht sollten Sie dann auch gleich noch Directory Based Edge Blocking (DBEB), DBEB mit Hybrid einschalten, damit Mails an ungültige Empfänger ebenfalls direkt abgelehnt werden, und sie nicht als NDR-Backscatter auftreten.
Von einem "Exploit" würde ich hier nicht sprechen, eher von "Works as designed" und über die Defaults kann man streiten. In meiner Checkliste Tenant Einrichtung ist das Thema aber enthalten.
Wer der Exchange Online als Nebeneingang für Mailempfang durch einen Partner Connector für den Adressrau "*" und Angabe des OnPrem Server oder eigenen Spamfilters verschlossen hat, muss sich zum DirectSend keine Gedanken machen. Sie sollten aber ähnliche Schutzfunktionen dann auf dem OnPremises Spamfilter umsetzen, um eingehende Mails mit ihrer eigenen Domain zu unterbinden.
Und damit sind wir genau beim Thema "Direct Send", was genaugenommen "RejectDirectSend" heißen müsste, denn mit der passenden Einstellung wird verhindert, dass jemand mit der eigenen Domain von extern eine Mail direkt an Exchange Online sendet.
- Hybrid Hintereingang
- Exchange Online als Nebeneingang für Mailempfang
- MOERA - Microsoft Online Email Routing Address
- SPF, DKIM und DMARC jetzt!
- Directory Based Edge Blocking (DBEB)
- DBEB mit Hybrid
- NDR-Backscatter
-
What is Direct Send and how to secure it
https://techcommunity.microsoft.com/blog/exchange/what-is-direct-send-and-how-to-secure-it/4439865 -
Introducing more control over Direct Send in
Exchange Online
https://techcommunity.microsoft.com/blog/exchange/introducing-more-control-over-direct-send-in-exchange-online/4408790?WT.mc_id=M365-MVP-9501 -
How the proxyAddresses attribute is
populated in Microsoft Entra ID | Microsoft
Learn
https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/user-prov-sync/proxyaddresses-attribute-populate -
Microsoft 365 'Direct Send' abused to send
phishing as internal users
https://www.bleepingcomputer.com/news/security/microsoft-365-direct-send-abused-to-send-phishing-as-internal-users/ -
Microsoft 365’s Direct Send Exploited to
Bypass Defenses with Internal Phishing -
HawkEye
https://hawk-eye.io/2025/07/microsoft-365s-direct-send-exploited-to-bypass-defenses-with-internal-phishing/ - Microsoft 365's Direct Send Exploited to
Send Phishing Emails as Internal Users
https://cybersecuritynews.com/microsoft-365s-direct-send-exploited/ - Exploiting Direct Send: Attackers Abuse
Microsoft 365 to Deliver Internal Phishing
Attacks
https://www.proofpoint.com/us/blog/email-and-cloud-threats/attackers-abuse-m365-for-internal-phishing - Ongoing Campaign Abuses Microsoft 365’s
Direct Send to Deliver Phishing Emails
https://www.varonis.com/blog/direct-send-exploit
Kurzfassung RejectDirectSend
Die wesentlichen Dinge in Kürze. Bisher hat Exchange wie folgt funktioniert:
- Mails direkt an Exchange Online wurden
angenommen
Auch wenn der MX-Record für ihre Domain gar nicht auf Exchange Online verwiesen hat. Spammer hat das nicht interessiert. Siehe auch Exchange Online als Nebeneingang für Mailempfang - Die Mail-Adresse des Absenders konnte
ihre eigene Domain sein -> Phishing-Risiko
Das können Sie verhindern, indem Sie per SPF/DKIM/DMARC den Versand mit ihrem guten Namen verhindern. Siehe auch SPF, DKIM und DMARC jetzt!. - Dennoch kann der Phishing Filter die
Mails als "Junk-Mail" klassifizieren
Und damit sieht sie der Anwender nicht
Durch die globale Einstellung "RejectDirectSend" in ihrem Exchange Online Tenant können sie den Missbrauch ihrer Domain einfacher einschränken und dennoch legitime Absender zulassen. Sie sollten aber Vorarbeiten durchführen, damit legitime Mails weiter ankommen.
- Es geht nur um Mails von ihrer eigenen
SMTP-Domain von extern und anonym an ihren
Tenant.
Bei einer Hybrid-Umgebung können natürlich auch OnPremises Postfächer so per SMTP über Exchange Online erreicht werden
Reject Direct Send covers anonymous messages sent from your own domain to your
organization’s mailboxes. Enabling this setting will block any email sent to
your tenant that is sent anonymously using an address that matches one of your
accepted domains.
Quelle:
https://techcommunity.microsoft.com/blog/exchange/introducing-more-control-over-direct-send-in-exchange-online/4408790
- Relevant ist nur der Absender im SMTP-Envelope.
Nicht der angezeigte Absender aus dem Header
Mails anderer Domain oder auch von Microsoft Systemdiensten sind nicht betroffen.
For the sending domain, we are talking specifically about the P1 Mail From
envelope sender address here. The P2 From header is not checked by this feature.
Quelle:
https://techcommunity.microsoft.com/blog/exchange/introducing-more-control-over-direct-send-in-exchange-online/4408790
- Legitime einliefernde Server müssen über
einen Partner-Connector "autorisiert" werden
Dazu geben Sie ihre eigene SMTP-Domain und das Zertifikat bzw. IP-Adresse des Servers an. - Sie müssen SPF nicht publizieren, sollten es
aber
Durch die Aktivierung DirectSend schützen Sie ihren Tenant gegen Phishing in ihrem eigenen Namen aber Angreifer können ihren Namen immer noch zum Versand an andere Domains missbrauchen. Bitte veröffentlichen Sie ihre legitimen Mailserver mittels SPF-Eintrag und einem "-all" am Ende, damit auch andere Firmen sich besser schützen können.
Es gibt eine Einschränkung, die primär auf die Beschränkung auf den P1-Header zurückzuführen ist. Als Spammer, der durch RejectDirectSend blockiert wird, kann ich eine andere Domain beim "MAIL FROM" verwenden und im Header immer noch ihre Domain nutzen. Wenn die Mails über eine Weiterleitung bei ihnen ankommt und der Absender kein SRS - Sender Rewriting Scheme (SRS) unterstützt, wird die Mail abgelehnt.
- What is Direct Send and how to secure it
https://techcommunity.microsoft.com/blog/exchange/what-is-direct-send-and-how-to-secure-it/4439865
Prüfungen und aktivieren!
Jeder Exchange Online Tenant nimmt standardmäßig Mails aus der Internet an. Das können Sie abschalten, z.B. indem Sie den Exchange Online als Nebeneingang für Mailempfang mittels Partner-Connector für die Domain "*" auf erlaubte IP-Adressen einschränken. Das geht aber nur, wenn Sie einen 3rd Party-Spamfilter oder einen lokalen Exchange Server (Siehe auch Hybrid Hintereingang) als Empfänger nutzen. Wir können also davon ausgehen, dass tausende Tenants Mails aus dem Internet annehmen und sich auf den Spamschutz von Exchange Online Protection verlassen. Der ist gar nicht mal so schlecht und kann Absenderdomains anhand von SPF, DKIM und DMARC bewerten und ablehnen. Aber auch hier gibt es viel zu viele Domains, die keinen strengen SPF-Eintrag haben und damit kann es passieren, dass ein Angreifer eine Mail mit ihrer eigenen Absenderdomain an ihren Tenant sendet.
Oft erkennt Exchange Online dies als Phishing aber darauf sollten Sie sich nicht verlassen. Es ist ihre Domain und sie können selbst entscheiden, wer damit senden darf und wer nicht. Nun aber vorschnell eine Regel anzulegen, die sage: "Von Extern mit Absenderdomain = Firma -> Ablehnen" greift zu kurz, denn es kann ja durchaus legitime Absender geben, die Mails aus dem Internet an ihren Tenant senden und ihre Absenderdomain verwenden. Ehe Sie also "RejectDirectSend" aktivieren, sollten Sie diese Absender entweder umstellen, oder über einen eigenen Partner Connector für ihre Domain und einen SPF-Eintrag "-all" zulassen.
Das war die Kurzfassung. Wenn Sie diese Härtung umsetzen wollen, dann lohnt es sich die Langfassung zu lesen.
Anforderungen
Fälschung und Phishing ist ein permanentes Risiko und als Administrator sollten Sie alles daran setzen, dass ihre Anwender nur "saubere" Mails bekommen. Ein Exchange Online Tenant ist für all die SMTP-Domains zuständig, die sie als Administrator im registriert haben. All ihre Exchange Postfächer können nur mit einer Adresse aus diesen Domains eine Mail nach extern versenden und empfangen und müssen sich dazu authentifizieren. Nun gibt es aber auch den Fall, dass Absender mit ihrer Domain arbeiten, aber kein Postfach in Exchange Online haben und auch nicht über einen Hybrid Connector eine Mail mit dem erforderlichen Vertrauenslevel an Exchange Online zum Versand übergeben können. Sie sollen aber dennoch Mails an ihren Tenant senden. Klassische Anwendungsfälle sind:
- Scan2Mail-Geräte
Sie legen ein Papier auf die Glasscheibe, wählen im Display den Empfänger aus und der Scanner digitalisiert das Bild in eine PDF-Datei und sendet es per SMTP an den Empfänger. Eine Absenderadresse könnte "scanner@msxfaq.de" sein. - Monitoring
Es ist immer noch üblich, dass eine Überwachungslösung wie PRTG, Nagios, Icinga etc. bei Alarmen eine Mail an einen Administrator sendet. Mein PRTG-Server könnte also mit "monitoring@msxfaq.de" seine Meldungen an mein Postfach senden. - Skripts/Webformulare
Viele Administratoren haben schon immer gerne "Send-MailMessage" genutzt, um Meldungen per Mail an den Anwender oder Admin zuzustellen. Wenn ich ein Webformular für Feedback auf der MSXFAQ hätte, könnte die Absenderadresse "webform@msxfaq.de" lauten. - Newsletter/Informationssysteme
Exchange Online erzwingt verschiedene Exchange Online Message Rate Grenzen für den Empfang von Mails. Wenn ein System sehr viele Mails senden will, kann es sein, dass er irgendwann gedrosselt wird oder sie nutzen HVE - High Volume Email mit Exchange. - Weitere
Denken Sie an ihren automatischen Rechnungsausgang, Helpdesk-Systeme etc. Die Anwendungsfälle kann ich gar nicht alle aufzählen.
Sie könnten nun jedem Dienst ein Postfach in Exchange Online zuweisen. Das ist aber keine Lösung, denn dazu müsste der Versendet dann folgende Voraussetzungen erfüllen:
- Entra ID Konto mit Kennwort
- Exchange Online Konto mit Lizenz
- Support zur Anmeldung mit OAUTH/SAML und MFA
- Verbindung zu Exchange Online per SMTP/TLS mit TLS 1.2
Die meisten Systeme können mindestens eine der Voraussetzungen nicht, wobei wir wieder bei der Anforderung landen, dass solche Systeme "anonym" eine Mail an ihre internen Empfänger in ihrem Tenant senden müssen.
Fälschungen/Spoofing verhindern
Um aber Fälschungen zu erschweren, sollten Sie sicherstellen, dass Absender mit ihrer Domain auch wirklich zu ihrer Domain gehören. Dazu gibt es mit SPF eine effektive Methode. Sie könnten im SPF-Record ihrer Domain alle IP-Adressen aufführen, die mit ihrer Domain senden dürfen und alle andere mit "-all" verbieten. Allerdings rät Microsoft von einem "Hard Fail" ab.
While SPF provides protection from
spoofing of your domains, we recommend customers use a Soft
Fail SPF configuration due to the possibility of valid
routing scenarios falling foul of SPF failures. As such, no
feature existed to block Direct Send traffic for the many
customers who have no need to use it. To this end we have
developed the Reject Direct Send setting for Exchange Online
and are announcing the Public Preview for this feature today.
Quelle: Introducing more control over Direct Send in
Exchange Online | Microsoft Community Hub
https://techcommunity.microsoft.com/blog/exchange/introducing-more-control-over-direct-send-in-exchange-online/4408790
Das klingt nach "Wasch mich aber mach mich nicht nass". Aus meiner Sicht sollten sie immer einen strengen SPF-Eintrag setzen und dazu ermitteln, wer in ihrem Namen etwas senden darf und alle anderen Absender blocken lassen. Am besten setzen sie damit auch gleich DKIM und DMARC ein. Siehe SPF, DKIM und DMARC jetzt!
Nun müssen wir aber unterscheiden, ob jemand mit der eigenen Domain an den eigenen Exchange Tenant oder an fremde Mailsysteme senden will. Der SPF-Record gilt für alle Empfänger gleich. Hier kommt dann RejectDirectSend ins Spiel. Das normale Verhalten laut RC sollte wie folgt sein:
SPF-Einstellung | SPF-Ergebnis | Zielsystem | RejectDirectSend | Ergebnis | Beschreibung |
---|---|---|---|---|---|
~all |
SoftFail |
Fremdes Mailsystem |
(nicht relevant) |
Zugestellt |
Bei dem Beispiel versucht jemand ihr gute Domain als Absender zu missbrauchen. Das sie aber keinen oder "weichen" SPF-Eintrag für ihre Domain veröffentlichen, kann der Empfänger die Mail nicht sicher ablehnen |
~all |
SoftFail |
Eigener Tenant |
$False |
Zugestellt |
Auch eine Mail an ihren eigenen Exchange Online Tenant kann EOP nicht ablehnen, da sie selbst das mit dem fehlenden oder weichen SPF-Eintrag genau so veröffentlichen. |
-all |
HardFail |
Fremdes Mailsystem |
(nicht relevant) |
Reject |
Jedes gut konfigurierte Mailsystem sollte solche Mails direkt ablehnen, da es sehr wahrscheinlich ein Phishing-Versuch ist. Aber letztlich entscheidet der Admin des Zielsystems, ob er die Mail ablehnt, in eine Quarantäne ablegt oder nur mit einer Warnung versieht. Wenn Sie als Inhaber natürlich nicht alle Absender-Systeme im SPF-Record erfasst haben, dann haben Sie ein Problem. |
-all |
HardFail |
Eigener Tenant |
$False |
Zugestellt |
Exchange Online stellt ein Hardfail auf jeden Fall ins Postfach zu. Ich habe es extra mehrfach geprüft aber Exchange lässt die Mails tatsächlich durch. -> Das wird durch RejectDirectSend beeinflusst. |
-all |
HardFail |
Eigener Tenant |
$True |
Reject |
Ein Absender, der die SPF-Anforderung nicht erfüllt, kann die Mail gar nicht erst zustellen |
Übrigens: Microsoft veröffentlicht für seine Domains ein "SPF -all" aber keine DMARC-Policy.
C:\> nslookup -q=TXT msxfaqlab.onmicrosoft.com msxfaqlab.onmicrosoft.com text = "v=spf1 include:spf.protection.outlook.com -all" C:\> nslookup -q=TXT msxfaqlab.mail.onmicrosoft.com msxfaqlab.mail.onmicrosoft.com text = "v=spf1 include:outlook.com -all"
Höchste Zeit also, dass Sie dies für ihre Domain auch einmal überdenken.
Hinweis: Wir sprechen im folgenden nicht über Exchange Online als "Relay ins Internet" sonder nur um die Zustellung von Mails an Empfänger in ihrem eigenen Tenant.
Testserie -RejectDirectSend $false (Standard)
Wenn Sie sich mit der Exchange Online PowerShell verbunden haben, können Sie sehr einfach die aktuelle Einstellung ihres Tenants auslesen. Der Name des Parameters ist wichtig und insbesondere dass er durch das Präfix "Reject" negiert wird. Bei all meinen Tenants war die Standardeinstellung "$False".
Ein "Reject" ist auf "$False" gesetzt, d.h. DirectSend ist im Default "ERLAUBT". Wie wirklich sich das auf den Empfang von Mails über Port 25 ohne TLS auf ihren Tenant aus, wenn sie nichts anderes konfiguriert haben? Ich habe dazu mit folgendem Befehl eine Testmail direkt an meinen Exchange Online Tenant gesendet.
Send-MailMessage ` -To "user1@msxfaq.com" ` -From "drucker@msxfaq.com" ` -Subject "Test Direct Send" ` -Body "Test Direct Send Body" ` -SmtpServer "msxfaq-com.mail.protection.outlook.com" ` -Port 25
Die Absenderadresse gibt es in meinem Tenant nicht. Abhängig von SPF-Einstellungen und Connectoren habe ich folgendes Verhalten festgestellt:
RejectDirectSend | SPF | Connector | Ergebnis | Ergebnis |
---|---|---|---|---|
$false |
NONE SOFTFAIL |
Kein |
Zugestellt |
Wenn die Source-IP nicht im SPF-Record enthalten ist und kein "-All" ein Fail liefert, dann wird die Mail von Exchange Online angenommen, und in das Postfach des Benutzer zugestellt. |
$false |
FAIL |
Kein |
Zugestellt |
Die Mail wurde von Exchange Online angenommen, und in das Postfach des Benutzer abgelegt, obwohl SPF ein "-all" erzeugt hat. Ich hätte eine Ablehnung oder zumindest eine Ablage in der Quarantäne oder Junk-E-Mail erwartet |
$false |
FAIL |
Kein |
Junk-E-Mail |
Die Mail wurde einfach von Exchange Online angenommen aber in den Junk-E-Mail Ordner abgelegt. Das war zu erwarten, da der SPF=FAIL und die Absenderdomain als Phishing erkannt werden dürfte. |
$false |
PASS |
Kein |
Junk-E-Mail |
Danach habe ich die IP-Adresse des einliefernden Hosts mit in den SPF-Eintrag aufgenommen. Der nächste Versuch einer Mail ist immer noch in Junk-Mail gelandet. Zwar was nun der SPF-Check PASS. Exchange stellt die Mail aber auch so aber die Absenderdomain ist immer noch meine eigene und das wäre ein Phishing |
$false |
FAIL |
Partner Connectors mit der Source-IP |
Junk-E-Mail |
Das Anlegen eines Partner Connectors beschränkt die Einlieferung dieser Domain auf die vorgegeben IP-Adresse aber verleiht dem Absender noch keinen Vorteil. Die Mail landet dennoch in Junk-E-Mail |
$false |
PASS |
Partner Connectors mit der Source-IP |
Zugestellt |
Danach habe ich die IP-Adresse des einliefernden Hosts mit in den SPF-Eintrag aufgenommen. Der nächste Versuch einer Mail ist immer noch in Junk-Mail gelandet. Zwar was nun der SPF-Check PASS. Exchange stellt die Mail aber auch so aber die Absenderdomain ist immer noch meine eigene und das wäre ein Phishing |
Mit der Einstellung "RejectDirectSend:$false" konnte ich eine Mail auch mit meiner eigenen Domain von extern an Exchange Online zustellen, sobald es einen passenden Inbound Partner Connector gab UND der SPF-Eintrag die Source-IIP-Adresse zugelassen hat.
Der Schutz gegen eine anonyme Zustellung mit ihrer eigenen Absenderdomain ist nicht 100% sicher, wenn Sie nicht mit einen "SPF=-all" und der Angabe aller Server ihr System schützen.
Hinweis: Diese Testserie berücksichtig nicht DMARC. Ein DMARC p=Reject verhindert je nach Einstellung in Exchange Online nicht die Annahme aber die Zustellung ins Postfach des Empfängers.
Bisherige Lösungen
Das bedeutet, dass in der Standardeinstellung jeder von extern eine Mail mit ihren eigenen Domains direkt an ihren Tenant senden könnte. Was die natürlich verhindert sind Einstellungen wie:
- Partner-Connector mit "*" oder ihrer
Domain, die eine Zustellung anhand der
RemoteDomain beschränkt
Wenn Sie eingehende Mails über einen 3rd-Party-Spamfilter Exchange OnPremises an ihren Tenant zugesendet haben, konnten Sie den Exchange Online als Nebeneingang für Mailempfang mit einem Partner-Connector unterbinden. Alternativ konnten Sie einen Partner-Connector für ihre eigene Domain anlegen, in dem SIe aber alle legitimen IP-Adressen eintragen mussten. - Strenger SPF-Eintrag
Ein weiterer Weg ist ein strenger SPF-Eintrag, mit dem Sie die IP-Adresse der erlaubten Server für ihre SMTP-Domain bekannt geben und alle andere mit "-all" verbieten. Dann wird Exchange Online beim Empfang zumindest die Domain des "Envelope-From" gegen den SPF-Record prüfen um einfachen Missbrauch zu verhindern. Für einen besseren Schutz ist aber eine DMARC-Konfiguration für ihre Domain notwendig, damit in die DMARC-Validation auch der Header über das Alignment einbezogen wird. - Exchange Online "High Confidence Phish"-Schutz
Microsoft hat seinen eigenen Spamfilter insbesondere Richtung Phishing immer weiter ausgebaut um Missbrauch zu erkennen und solche Mails auszusortieren. Wer anonym von extern mit einer Adresse senden will, die einem internen Absender gehört, wird in der Regel nicht zugestellt.
Sie konnten als auch schon vor der Einführung von "RejectDirectSend" eine anonyme Zustellung an ihren Tenant wirksam unterbinden. Sie mussten aber aktiv werden.
Änderung durch RejectDirectSend
Durch den neuen Schalter "RejectDirectSend" ändern sich nun zwei Dinge, wenn sie diesen auf "$true" setzen.
- Unterbinden von externen Mails mit ihrer
SMTP-Domain ohne explizite Konfiguration
Damit Sie weiter Mails von Systemen mit ihrer eigenen SMTP-Domain bekommen, müssen Sie diese einliefernden Systeme explizit über einen Partner-Connector und SPF-Eintrag konfigurieren. - Lockern der
Exchange Online Message Rate Grenzen
Ein normaler Client kann nur eine gewissen Anzahl von Mails auch an interne Empfänger senden. Diese Limits werden mit der "DirectSend"-Konfiguration auch gelockert. Was das im Detail bedeutet, habe ich aber noch nicht gefunden.
Microsoft schreibt zu "DirectSend" folgendes:
"Direct Send is a method used to send
emails directly to an Exchange Online customer’s hosted
mailboxes from on-premises devices, applications, or
third-party cloud services using the customer’s own accepted
domain. This method does not require any form of
authentication because, by its nature, it mimics incoming
anonymous emails from the internet, apart from the sender
domain"
Quelle: Introducing more control over Direct Send in
Exchange Online
https://techcommunity.microsoft.com/blog/exchange/introducing-more-control-over-direct-send-in-exchange-online/4408790
Es geht hier nicht um Mails von ihrem System ins Internet sondern nur an ihre eigenen Postfächer, die nun in Exchange Online liegen. Direct Send behandelt Mails mit einer Absenderadresse aus ihrer eigenen Domain, die an ihren eigenen Tenant gesendet werden.
- Exchange Online Message Rate Grenzen
- Client SMTP submission: Authenticate
mail sent from your device or application
through a cloud mailbox
https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365#direct-send-send-mail-directly-from-your-device-or-application-to-microsoft-365-or-office-365
Konfiguration
Um den Vorteil von "Direct Send" nutzen zu können, müssen Sie mehrere Dinge berücksichtigen, damit folgendes Bild funktioniert:
In Form einer Checkliste sind dies folgende Einstellungen:
Einstellung | Erledigt |
---|---|
Client mit SMTP-VersandDer Versender der Nachrichten muss natürlich SMTP nutzen. Nachdem Sie "Direct Send" eingerichtet haben, können Sie hier als Absender eine Adresse ihrer eigenen SMTP-Domain verwenden, die im Tenant registriert ist. Tipp: Wenn Sie sicherstellen, dass Rückantworten an diese Adresse z.B. in einem Postfach landen, können sie leichter Fehler beim weiteren Versand erkennen. Der Versender muss sich nicht authentifizieren und auch kein TLS nutzen. Allerdings sollte der Client natürlich per DNS ihren Tenant auflösen. Dies erfolgt idealerweise über den MX-Record ihrer Domain. Ich habe mir aber angewöhnt einen eigenen DNS-Eintrag, z.B. "relay.msxfaq.de CNAME msxfaq-de.mail.protection.outlook.com" in einer von mit verwalteten DNS-Zone zu addieren und diesen im Gerät zu hinterlegen. So kann ich den Service auch schnell wieder umstellen. |
![]() |
NAT, Firewall, Public-IPDie meisten Absender werden hinter einer Firewall mit einer privaten IP-Adresse arbeiten und auf dem Weg zum Internet durch die Firewall mit "Network Address Translation (NAT)" arbeiten. Hier ist wichtig, dass im Internet eine "statische Public IP" genutzt wird. Nur dann können Sie diese Adresse auch korrekt im späteren Connector und SPF-Eintrag verwenden. Wer dynamische Adressen nutzten will, kann dies nur in Verbindung mit einem öffentlichen Zertifikat tun, welches der SMTP-Client bei Exchange Online vorweist. In der Firewall müssen Sie natürlich die privaten Source-IP-Adressen auch den Zugang zu den Exchange Online-Adressen über Port 25 erlauben Dies ist
eine gute Gelegenheit vorher
einmal zu prüfen, ob ihre
Firewall auch von innen nach
außen "dicht" ist. Wenn Sie
gleich ihre öffentliche
IP-Adresse für Direct Send
konfigurieren, sollten auch
wirklich nur legitime
interne Systeme diesen Weg
nutzen können. Nicht dass
eine Malware von intern
leichtes Spiel hat. |
![]() |
Partner ConnectorBIs hier kann der interne Absender schon einen Mail an Exchange Online senden und mit SPF=PASS bewertet werden. Dennoch ist für Exchange eine Mail aus einer "autoritativen Domain" im Tenant eine Fälschung. Daher benötigen wir nun noch einen Inbound Partner Connector. New-InboundConnector ` -Name "Inbound eigene OnPrem SMTPSender" ` -SenderDomains "msxfaq.de" ` -SenderIPAddresses 80.66.20.20/32 ` -RestrictDomainsToIPAddresses $true ` -RequireTls Damit "müssen" alle Mails von der Domain "msxfaq.de" über diese IP-Adresse kommen. Andere einliefernde Systeme werden direkt abgeblockt. Ich würde für die Einlieferung von Multifunktionsgeräten, ERP-Systemen etc. vielleicht eine Subdomain vorschlagen, um die eigentliche "Anwenderdomain" nicht zu stören. Also "scannername@scanner.msxfaq.de" oder "info@helpdesk.msxfaq.de" Wenn Sie noch andere Systeme haben, die von extern mit ihrer eigenen Domain an Exchange Online senden, dann müssen Sie diese hier ebenfalls anlegen. |
![]() |
SPF-EintragDie statische Adresse muss nämlich mit im SPF-Record der Absenderdomain mit addiert werden. Der SPF-Eintrag könnte dann wie folgt aussehen: @ TXT "v=spf1 include:spf.protection.outlook.com ip4:80.66.20.20/32 -all" Ohne SPF-Eintrag wird Exchange Online immer noch ein SPF=FAIL erkennen und da ihr Absender vermutlich keine DKIM-Signatur aufbringt, könnte die Mails sonst immer noch als Spam aussortiert werden. Generell sollten sie ihre SPF, DKIM, DMARC-Konfiguration korrekt einrichten, damit nicht andere Absender ihre Domain missbrauchen. Siehe auch SPF, DKIM und DMARC jetzt! |
![]() |
Organization KonfigurationZuletzt gibt es noch eine globale Konfiguration für ihren Tenant zu setzen Set-OrganizationConfig -RejectDirectSend $true Es braucht angeblich bis zu 30 Minuten, um die Einstellungen auf alle Exchange Online Server zu verteilen. Sie können also nicht direkt danach testen, ob alles wie erwartet funktioniert.
|
![]() |
Damit ist die Konfiguration abgeschlossen.
Testserie -RejectDirectSend $true
Nach der Umstellung habe ich meine Testserie wiederholt:
Wenn Sie die Tests nachstellen wollen, dann denken Sie daran, dass auch das Ein/Auschalten eines Connectors nicht sofort wirkt.
RejectDirectSend | SPF | Connector | Ergebnis | Ergebnis |
---|---|---|---|---|
$true |
PASS |
Partner Connector mit der Source-IP |
Zugestellt |
Das ist die reguläre Konfiguration mit aktiviertem "RejectDirectSend". Ich habe einen Partner-Connector für meine Domain mit der passenden IP-Adresse, die auch im SPF-Record hinterlegt ist |
$true |
FAIL |
Partner Connector mit der Source-IP |
Reject |
Wenn die einliefernde IP-Adresse nicht über einen SPF-Record erlaubt ist, wird die Mail direkt auf SMTP-Level mit folgendem Fehler abgelehnt: Send-MailMessage : Mailbox unavailable. The server response was: 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources. Allein der Partner Connector mit der IP-Adresse des einliefernden Servers gibt dem Absender keine Vorteile mehr. |
$true |
NONE SOFTFAIL |
Kein Partner Connector |
Reject |
Sofort nachdem der Partner Connector nicht mehr aktiv war, wurde die Mail direkt beim SMTP-Versand abgelehnt: Send-MailMessage : Mailbox unavailable. The server response was: 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources. |
$true |
PASS |
Kein Partner Connector |
Reject |
Send-MailMessage : Mailbox unavailable. The server response was: 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources.
|
Die Auswirkungen von "RejectDirectSend" sind direkt sichtbar. Eine Mail von meiner eigenen Domain kommt nur noch an, wenn ich einen SPF-Eintrag mit "-ALL" haben und mein absendendes System dort aufgeführt wird und ich mit einem Partner-Connector explizit noch einmal meine eigene Absenderdomain mit der IP-Adresse des einliefernden Systems freischalte. Das ist genau das Verhalten, was ich eigentlich haben möchte. Nach meinen Test reicht es dann auch nicht mehr, wenn der einliefernde Host ein SPF=PASS oder vielleicht ein DKIM=PASS erreicht.
Absender in GAL - Nicht erforderlich
Bei allen Prüfungen habe ich auch einen Absender genutzt, der nicht als MailKontakt oder MailUser in dem Tenant bekannt war. Exchange Online hätte ja auch prüfen können, ob es den Absender gibt und schon davon die Annahme abhängig machen. Meine Tests haben ergeben, dass ich den Userpart des Absenders in meiner Domain frei wählen kann. Das bedeutet zwei Dinge:
- Ungültige Adresse
Ich kann als Absende reine Adresse nutzen, die es nicht gibt. Die Folge ist, dass Fehler bei der Zustellung natürlich nicht bemerkt werden, da der NDR ja an die nicht vorhandene Adresse geht und damit ins Leere läuft. Sie können es natürlich machen aber ratsam ist es nicht. Wir kennen das von Firmen, die als "noreply@<firmendomain>" senden. Meine Einstellungen ist dazu: Wenn mir jemand eine Mail sendet und damit Kosten spart aber mir eine Rückantwort über den gleichen Weg verwehrt, scheint keine Kommunikation mit mir zu wünschen. Das ist aber ihre Entscheidung. Ich würde dann lieber eine "Shared Mailbox" anlegen, die bis zu 300 ProxyAddresses vereinen kann, um die Rückläufer einzusammeln - Phishing von eigenen Systemen
Sie haben einem eigenen System die bevorzugte Behandlung als "Partner mit ihrer eigenen Domain" eingeräumt. Da keine Absenderprüfung erfolgt, könnte ein solches System eine Mail als "ceo-name@<firmendomain>" an interne Empfänger senden. Die Empfänger könnten natürlich die anonyme Einlieferung anhand der Anzeige in der Absender-Adresse erkennen aber es bleibt ein Missbrauchpotential, das sie z.B. über eine Transport-Regel vielleicht lösen könnten. Es bleibt ein Restrisiko
Mit diesen Einschränkungen müssen sie aber leben, wenn sie anonym Mails an ihren Tenant senden wollen und dabei ihre eigene Absenderdomain verwenden müssen.
- Too many proxy addresses when you add or remove email addresses from an
Exchange Online recipient
https://learn.microsoft.com/en-us/troubleshoot/exchange/administration/too-many-proxy-addresses-error
RejectAnonymousDirectSend
Beim Vergleich mehrerer Exchange Online Tensants ist mir aufgefallen, dass es in allen Tenants den Parameter "RejectDirectSend" gab aber in einigen anderen es noch eine zusätzliche Einstellung "RejectAnonymousDirectSend" gibt.
PS C:\> Get-OrganizationConfig | fl reject* RejectAnonymousDirectSend : False RejectDirectSend : False
Diese Einstellung ist nicht in allen Tenants sichtbar und auch noch nicht dokumentiert. (Stand Juli 2025)
Sobald ich hierzu mehr weiß, reiche ich es nach
Spoofing mit P2, DMARC Strict wichtig
Die Konfiguration löst ein Problem aber nicht: Die meisten einfachen SMTP-Versender, für die eine solche Konfiguration aktiviert wird, können sich nicht per SMTP-AUTH anmelden und vor allem keine DKIM-Signatur aufbringen. Daher kann Exchange Online nur einen SPF-Check machen und ein SPF-Check bezieht sich nur auf den Absender des Umschlags (Envelope, P1). Ein Spammer könnte also damit sehr einfach eine Mail senden, in der der Header einen Absender aus ihrer Domain hat. Eine Mail könnten dann wie folgt aussehen:
IP-Adresse : Mailserver des Angreifers, die im SPF-Eintrag von" angreifer.example.com" ist Envelope-From: user@angreifer.example.com Envelope-To : rechnung@msxfaq.de Header-From : ceo@msxfaq.de Header-To : buchaltung@msxfaq.de Subject : Bitte Anzahlung leisten Body : Hallo Buchhaltung <LF>Bitte überweisen sie xxxx Euro an DE12 3456 7890
So eine Mail würde von Exchange Online mit einem SPF=PASS bewertet und wenn Sie für ihre eigene Domain keine strenge DMARC-Richtlinie erstellt haben und damit ein "Alignments" der beiden Absenderdomains (Envelope-From und Header-From) erfolgt, könnte man ihre Buchhaltung einfacher überlisten.Auf die Frage, ob Exchange Online neben der Envelope-Absenderadresse (P1) auch den Header prüft, antwortete Microsoft:
"We only check P1 domain for this."
https://techcommunity.microsoft.com/blog/exchange/introducing-more-control-over-direct-send-in-exchange-online/4408790/replies/4409412
Einschätzung
Schade, dass diese Funktion erst in 2025 gekommen ist. Als Mitinitiator von NoSpamProxy habe ich eine sehr strenge Sicht auf Mails und wie ein Absender diese klassifizieren sollte. Wer heute im geschäftlichen Verkehr mit E-Mails arbeitet, sollte SPF; DKIM und DMARC sowieso "streng" gesetzt haben und eingehende Spamfilter sollten bei einem SPF-HardFail schon alleine die Mail einfach ablehnen. Insofern ist es gut, dass Microsoft nun diese Funktion möglich macht aber es ist schlecht, dass es nicht Standardmäßig aktiviert wird. Es wäre ein einfaches, wenn Exchange Online in einer Übergangsphase einfach die Mails, die bei einem "RejectDirectSend:$True" nicht mehr ankommen, durch einen Header kennzeichnet. Es gibt ja auch die "Extern" und "Sie erhalten nicht oft Mails"-Hinweise bei eingehenden Mails, die beim Anwender mehr Sorgfalt und Aufmerksamkeit fördern sollen.
Wie viele Tenants empfangen Mails in einer Hybrid-Bereitstellung über einen konfigurierten Hybrid-Connector, der aber nicht mehr funktioniert? Bislang kommen solche Mails problemlos an, obwohl sie von der eigenen Domain kommen. Durch ein "SPF -ALL" würden solche Mails in der Exchange Online meist in der Quarantäne landen aber nicht abgelehnt werden.
Ich habe manchmal die Kunden, die Microsoft die "Schuld" für nicht zugestellt Mails geben wollen und nicht verstehen, dass Sie eigentlich selbst die größte Schuld tragen.
DirectSend oder genauer "RejectDirectSend" ist eine weitere Option, um eine anonyme Zustellung von eigenen Domains an den eigenen Tenant zu unterbinden und sie sollten diese aktivieren, nachdem Sie vorher alle legitimen Absender mit ihrer Domain zumindest im SPF-Record und in einem Partner-Connector eingetragen haben.
Weitere Links
- SPF, DKIM und DMARC jetzt!
- Exchange Online Message Rate Grenzen
- EXO Enhanced Filtering
- OnPremises Connector
- OnPremises Connector Attribution
- Exchange Online ohne Brückenkopf
- TERRL - Tenant External Recipient Rate Limit
- HVE - High Volume Email mit Exchange
- Hybrid Hintereingang
- Exchange Online als Nebeneingang für Mailempfang
- Directory Based Edge Blocking (DBEB)
- DBEB mit Hybrid
-
What is Direct Send and how to secure it
https://techcommunity.microsoft.com/blog/exchange/what-is-direct-send-and-how-to-secure-it/4439865 -
Introducing more control over Direct Send in
Exchange Online
https://techcommunity.microsoft.com/blog/exchange/introducing-more-control-over-direct-send-in-exchange-online/4408790?WT.mc_id=M365-MVP-9501 - High Volume Email: Continued support for
Basic Authentication & other important
updates
https://techcommunity.microsoft.com/blog/exchange/high-volume-email-continued-support-for-basic-authentication--other-important-up/4411197 - Introducing more control over Direct Send in Exchange Online
https://techcommunity.microsoft.com/blog/exchange/introducing-more-control-over-direct-send-in-exchange-online/4408790 - Direct Send: Send mail directly from your device or
application to Microsoft 365 or Office 365
https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365#direct-send-send-mail-directly-from-your-device-or-application-to-microsoft-365-or-office-365 - Set-OraganizationConfig -rejectdirectsend
https://learn.microsoft.com/en-us/powershell/module/exchange/set-organizationconfig?view=exchange-ps#-rejectdirectsend - MC1093237 - Microsoft Exchange Online: New Reject Direct Send parameter (preview)
https://mc.merill.net/message/MC1093237 - Exchange Online – Direct Send
https://danielgutermuth.de/microsoft/microsoft365/exchangeonline/exchange-online-direct-send/ - How to Disable Direct Send in Microsoft
365
https://www.alitajran.com/enable-disable-direct-send-microsoft-365/ - Exchange Online Adds New Control to
Enhance Email Protection for Businesses
https://petri.com/exchange-online-control-email-protection/