MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

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

Hinweis:
Wenn Sie ihre Domains mit SPF -all und DMARC p=reject korrekt abgesichert haben, kommen auch keine Fälschungen bei ihren Anwender an. Die RejectDirectSend-Einstellung kann aber immer noch helfen, da Exchange Online die Mails dann direkt ablehnt und nicht annimmt und löscht. Siehe auch EXO Phishing und SPF/DMARC-Check

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.

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.

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
(none)

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
(none)

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. Übrigens ist das auch die Vorgabe von Microsoft im Admin Center bei der Einrichtung einer Domain:


Quelle: Domains - Microsoft 365 admin center

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.

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-Versand

Der 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-IP

Die 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.
Hinweis: Wenn Anwender intern mit IMAP4/SMTP arbeiten, dann nutzen sie nicht den Port 25, sondern meist 587 oder seltener 465 zum Versand.

Partner Connector

BIs 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                    $false

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-Eintrag

Die 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 Konfiguration

Zuletzt 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.

RejectAnonymousDirectSend

Beim Vergleich mehrerer Exchange Online Tenants 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 nicht dokumentiert. Im Juni 2025 gab es aber folgende Auskunft:


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/replies/4420423

Vermutlich gab es hier wohl schon früher Überlegungen, die aber während der Entwicklung dann andere Defizite aufgezeigt haben und nicht weiter verfolgt wurden. Der Rückbau dauert aber wohl noch.

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