MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

EXO Phishing und SPF/DMARC-Check

Exchange Online hat einen Spamfilter, der je nach Lizenz unterschiedliche gut ist. Aber mittlerweile gehört ein einfacher SPF/DMARC-Check zum Standard und hier beschreibe ich einmal die Basisfunktion und Abhängigkeit zu Exchange DirectSend/RejectDirectSend.

Ich habe das Thema auch als Audiodatei für einen Podcast aufbereitet
exo_phishing_und_spfcheck.mp3

Als Schutz gegen Phishing mit der eigenen Domain gegen den eigenen Tenant könne Sie zusätzlich die Funktion DirectSend/RejectDirectSend aktivieren.

Phishingschutz per Default

Phishing ist ein großes Problem für Firmen, d.h. dass Angreifer sich als interne Personen ausgeben und interne Empfänger damit überlisten. Wenn es jemandem gelingt, sich als CEO auszugeben und per Mail eine Auszahlung o.ä. anweist und diese von der Buchhaltung nicht als Fälschung enttarnt und stattdessen ausgeführt wird, dann haben wir ein Problem.

Im Internet ist es aber auch nicht anders als bei der Briefpost. Bei einem Postbrief gibt es eigentlich keine "Absenderverifizierung" und natürlich gibt es Angreifer, die täuschend echte Postbriefe an Firmen mit Rechnungen senden, bei denen aber eine andere IBAN verwendet wird. Die Kosten mal eben ein schickes Briefpapier und Umschläge drucken zu lassen und etwas Porto zu investieren sind vertretbar, wenn Sie sich "lohnende Ziele" aussuchen und keine Massenmails senden.

Im Internet mit SMTP als Transport gibt es mit SPF, DKIM und DMARC schon starke Möglichkeiten, wie ein Absender seine Mails kennzeichnen kann und Empfänger basierend darauf die Mails ablehnen können.

Achtung:
Das ist aber kein Schutz gegen "ähnliche Domains", d.h. wenn ein Angreifer den Namen leicht abändert, z.B. "rn" statt" "m" im Namen verwendet.

Basiskonfiguration

Ich nehme für die folgenden Tests einen Exchange Online Tenant, der weitestgehend Standard ist. Ich habe weder den Exchange Online als Nebeneingang für Mailempfang über einen Partner Connector zugemacht noch Exchange DirectSend/RejectDirectSend konfiguriert. Mein Tenant nimmt einfach Mails an. Zum Test habe ich einfach die Microsoft Domain "msxfaqdev.onmicrosoft.com" genutzt. Microsoft setzt dazu per Default die folgenden DNS-Einträge:

       msxfaqdev.onmicrosoft.com text = "v=spf1 include:spf.protection.outlook.com -all"
_dmarc.msxfaqdev.onmicrosoft.com text = "v=DMARC1; p=reject;"

Microsoft veröffentlicht also, dass Mails von dieser Domain nur von Exchange Online selbst kommen können und alle anderen Absender nicht erlaubt sind. Die Informationen werden nicht nur von Exchange Online bei eingehenden Mails ausgewertet, sondern können natürlich von allen SMTP-Servern im Internet ausgewertet werden.

Hinweis: Diese strengen Einstellungen empfiehlt Microsoft übrigens auch eigene Domains, wie Sie im Microsoft 365 Admin Center sehen können.

Und dann habe ich von verschiedenen Clients eine Phishing-Mail an Exchange Online gesendet.

Hinweis:
Ich habe dazu einen Firmenanschluss mit statischer IP-Adresse und entsprechender Reputation genutzt und keinen DSL-Homeanschluss, der von Exchange Online schon direkt auf IP-Level geblockt wird.

Test 1: DMARC p=reject

Zuerst habe ich eine Mail mit einem internen Absender an den internen Absender gesendet.

Send-Mailmessage `
   -From clouduser1@msxfaqdev.onmicrosoft.com `
   -To clouduser1@msxfaqdev.onmicrosoft.com `
   -Subject "SPFTest1" `
   -SmtpServer msxfaqdev.mail.protection.outlook.com

Interessanterweise wurde die Mail von Exchange Online sogar angenommen. Sie ist aber nie im Postfach angekommen. Ein Blick ins Messagetracking hat ein interessantes Verhalten gezeigt. Ich finde nämlich gleich zwei Einträge:

 

Der untere Eintrag meldet einen Fehler bei der Zustellung der direkten Mail. Die Details liefern dazu:

Die Mail wurde laut den Details von einem Exchange Server in Frankfurt erst einmal angenommen und danach wurde dann eine SPF/DMARC-Prüfung durchgeführt. Meine Phishing-Testmail war natürlich nicht mit einer gültigen DKIM-Signatur versehen. Damit hat der SPF-Hardfail + DMARC das frühe Ende der Mail besiegelt.

Die Mail wurde also mit einem 550-Fehler intern abgelehnt, weil die DMARC-Richtlinie nicht gepasst hat. Da Exchange Online die Mail aber nicht direkt beim Empfang schon abgelehnt hat, muss Exchange genaugenommen einen NDR senden. Der NDR wird sogar generiert, wie die Zeile darüber dokumentiert. Allerdings wird diese Mail von einem Transport Agenten direkt verworfen.

Das kann man so machen und sollte man vermutlich auch so tun, damit Exchange Online nicht als NDR-Backscatter negativ auffällt.

Besser wäre es natürlich, wenn Exchange Online die Mail schon beim Empfang bewertet. NoSpamProxy macht die komplette SPF/DKIM-Prüfung direkt nachdem der einliefernde Server fertig ist und auf die "250 Accepted for delivery"-Meldung wartet.

Als Schutz gegen Phishing mit der eigenen Domain gegen den eigenen Tenant könne Sie zusätzlich die Funktion DirectSend/RejectDirectSend aktivieren.

Exchange Online könnte ja zumindest den SPF-Hardfail zusammen mit einer nicht vorhandenen DKIM-Signatur zum Anlass nehmen.

Test 2: DMARC p=quarantine

Die Ablehnung der ersten Testmail erfolgte, weil neben dem SPF-Check auch die DMARC-Policy auf p=reject stand. Das hat mich natürlich neugierig gemacht, wie sich eine andere Richtlinie auswirkt. Sie können im Microsoft 365 Admin-Center tatsächlich auch die DNS-Einträge über die "onmicrosoft.com"-Domain ändern:

Danach habe ich die gleiche Mail noch mal mit einem veränderten Betreff "SPFTest2" gesendet.

Send-Mailmessage `
   -From clouduser1@msxfaqdev.onmicrosoft.com `
   -To clouduser1@msxfaqdev.onmicrosoft.com `
   -Subject "SPFTest2" `
   -SmtpServer msxfaqdev.mail.protection.outlook.com

Im Messagtracking war die kurz darauf auch mit dem Status "Quarantined" zu finden.

Exchange Online hat auch diese Mail angenommen und sehr wohl erkannt, dass die Mail den SPF-Check wieder nicht bestanden hat aber dann anhand der DMARC-Richtline die Mail nur in die Quarantäne gelegt hat.

Aus meiner Sicht sollten Sie daher für einen effizienten Schutz ihre DMARC-Richtlinie auf "p=Reject" lassen

Ich habe die DMARC-Richtlinie wieder auf "p=reject" zurückgestellt. Eine nachfolgende Testmail hat bestätigt, dass die Mails wieder gelöscht und der NDR ebenfalls unterdrückt wird.

Test 3: SPF Only, ohne DMARC-Policy

Was macht Exchange Online, wenn eine Absenderdomain nur einen "SPF:-all"-Eintrag hat aber noch keine DMARC-Richtlinie veröffentlicht. Da ich aber bei der msxfaqdev.onmicrosoft.com den DMARC-Eintrag nicht löschen kann, habe ich dem Benutzer eine Adresse "Clouduser1@msxfaqdev.de" gegen und bei der Domain nur einen SPF-Eintrag gesetzt.

Send-Mailmessage `
   -From Clouduser1@msxfaqdev.de `
   -To Clouduser1@msxfaqdev.de `
   -Subject "SPFTest2" `
   -SmtpServer msxfaqdev.mail.protection.outlook.com

Die Mail wurde von Exchange Online als Spam erkannt und entsprechend in den "Junk-E-Mail"-Ordner verschoben. In den Details des Tracking ist aber kein Hinweis auf den SPF-Fail oder die nicht vorhandene DMARC-Policy

 

Die Mail im Junk-E-Mail Ordner zeigt im Header schon, dass die Mail einen spf=fail hat

Authentication-Results: spf=fail (sender IP is 80.66.20.27)
 smtp.mailfrom=msxfaqdev.de; dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=msxfaqdev.de;compauth=none
 reason=905
Received-SPF: Fail (protection.outlook.com: domain of msxfaqdev.de does not
 designate 80.66.20.27 as permitted sender) receiver=protection.outlook.com;
 client-ip=80.66.20.27; helo=FC-T14G5;
Received: from FC-T14G5 (80.66.20.27) by
 FR3PEPF00000486.mail.protection.outlook.com (10.167.240.6) with Microsoft
 SMTP Server id 15.20.9031.11 via Frontend Transport; Wed, 13 Aug 2025 08:37:25 +0000

Ich kann nur annehmen, dass Microsoft diese Bewertung mit in die Klassifizierung als "Spam" einbezogen hat.

Allerdings habe ich noch keine Einstellung gefunden, die allein bei einem SPF=Fail eine Mail ablehnt, löscht oder sicher in die Quarantäne liegt. Wer hier mehr Sicherheit haben möchte, könnte mit einer Transportregel vielleicht nach "spf=fail" suchen und solche Mails selbst behandeln.

Test 4: Phishing über Exchange Hybrid

Der dritte Test ist nun natürlich etwas aufwändiger. Der SPF-Eintrag für die Domain "msxfadev.onmicrosoft.com" beschränkt den Versand auf Server von Exchange Online. Der MX-Record verweist auch auf Exchange Online und die DMARC-Policy steht auf Reject. Als auch habe ich versucht, über einen anderen Tenant solche Mails einzuliefern. Ich habe daher einen lokalen Exchange Server mit einer Hybrid-Bereitstellung versehen und alle Mails über den Hybrid-Connector geroutet. Ich nutze also Exchange Online aus ausgehendes Relay und verstecke quasi meinen Exchange OnPremises Server hinter Exchange Online. Dann habe ich in Exchange Online einen Receive-Connector angelegt, der von der IP-Adresse meines Clients jede Mail annimmt und als "Open-Relay" weiter verarbeitet.

x

Die Mail habe ich vom linken Client per SMTP an den lokalen Exchange Server eingeliefert.

Send-Mailmessage `
   -From clouduser1@msxfaqdev.onmicrosoft.com `
   -To clouduser1@msxfaqdev.onmicrosoft.com `
   -Subject "SPFTest3" `
   -SmtpServer ex2019

Das OnPremises-Tracking zeigt das Routing zum Hybrid-Connector Richtung Exchange Online.

In Exchange Online habe ich folgende Header gesehen. Die Mails wurde natürlich in meinem ausgehenden Tenant mit einem SPF:Fail bewertet aber das sie dank Authentifizierung mittels Zertifikat dem Inbound OnPremises Hybrid Connector zugerechnet wurde, wurde die "action=oreject" angewendet, d.h. der eigentlich zu erwartende "Reject" wurde mittels "Overwrite" überstimmt.

X-MS-Exchange-Authentication-Results: spf=fail (sender IP is 80.66.20.27)
 smtp.mailfrom=msxfaqdev.onmicrosoft.com; dkim=none (message not signed)
 header.d=none;dmarc=fail action=oreject
 header.from=msxfaqdev.onmicrosoft.com;
Received-SPF: Fail (protection.outlook.com: domain of
 msxfaqdev.onmicrosoft.com does not designate 80.66.20.27 as permitted sender)
 receiver=protection.outlook.com; client-ip=80.66.20.27;
 helo=mail.netatwork.de;
X-OriginatorOrg: netatwork.de
X-MS-Exchange-CrossTenant-Id: de21c301-a4ae-4292-aa09-6db710a590a6
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=de21c301-a4ae-4292-aa09-6db710a590a6;Ip=[80.66.20.27];Helo=[mail.netatwork.de]
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem

Im Messagetracking des ausgehenden Exchange Tenants sehen wir dann, dass die Mail angenommen und weiter nach extern über den MX-Record geroutet wurde:

Hinweis: Das zeigt wie kritisch die lokale Konfiguration ihrer Umgebung ist und welcher Absender sich bei ihrem Exchange Online Tenant über einen "Hybrid OnPrem Connector mit Zertifikat" sich ausweisen kann.
keine SRS

Beim Zieltenant ist die Mail kurz danach im Messagetracking aufgetaucht aber wurde angenommen und in Junk-E-Mail verschoben:

Im Junk-E-Mail-Ordner des Benutzers war die Phishing-Mail nicht nur mal so gelandet, sondern mit dem Kennzeichen "unverified" versehen worden:

Wenn ich die Mail öffne, dann sagt Outlook, dass sie den Absender nicht verifizieren konnten.

Da war ein Blick in die Header dann mal angebracht. Die folgenden Abschnitte sind in der Reihenfolge im Header zu lesen d.h. oben sind die letzten und unten die früheren Informationen.

  • ARC Bewertung im Ziel-Tenant 
    Der SMTP-Transport in MSXFAQDEV bewertet die Mail anhand der Einlieferung durch den anderen "bösen" Tenant, bei dem ich den Absender über einen Org-Connector spoofen konnte. Aus Sicht des Zieltenants ist "2a01:111:f403:e20b::" die einliefernde IP-Adresse.
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=fail (sender ip is
 2a01:111:f403:e20b::) smtp.rcpttodomain=msxfaqdev.onmicrosoft.com
 smtp.mailfrom=msxfaqdev.onmicrosoft.com; dmarc=fail (p=none sp=none pct=100)
 action=none header.from=msxfaqdev.onmicrosoft.com; dkim=none (message not
 signed); arc=pass (0 oda=0 ltdi=1)
Authentication-Results: spf=fail (sender IP is 2a01:111:f403:e20b::)
 smtp.mailfrom=msxfaqdev.onmicrosoft.com; dkim=none (message not signed)
 header.d=none;dmarc=fail action=none
 header.from=msxfaqdev.onmicrosoft.com;compauth=fail reason=601
Received-SPF: Fail (protection.outlook.com: domain of
 msxfaqdev.onmicrosoft.com does not designate 2a01:111:f403:e20b:: as
 permitted sender) receiver=protection.outlook.com;
 client-ip=2a01:111:f403:e20b::;
 helo=BEUP281CU002.outbound.protection.outlook.com;

Ich verstehe aber nicht, warum diese Adresse nicht einen SPF=pass liefert, denn die Domain MSXFAQDEV.onmicrosoft.com schließt sehr wohl die Microsoft 365 Sender mit ein:

C:\> nslookup -q=TXT msxfaqdev.onmicrosoft.com
msxfaqdev.onmicrosoft.com       text =  "v=spf1 include:spf.protection.outlook.com -all"

C:\> nslookup -q=TXT spf.protection.outlook.com

spf.protection.outlook.com text = "v=spf1 ip4:40.92.0.0/15  ip4:40.107.0.0/16 
                                          ip4:52.100.0.0/15 ip4:52.102.0.0/16 
                                          ip4:52.103.0.0/17 ip4:104.47.0.0/17 
                                          ip6:2a01:111:f400::/48  
                                          ip6:2a01:111:f403::/49  
                                          ip6:2a01:111:f403:8000::/51  
                                          ip6:2a01:111:f403:c000::/51
                                          ip6:2a01:111:f403:f000::/52  
                                          -all"

Das Subnetz 2a01:111:f403:c000::/51  erstreckt sich dabei von  2a01:111:f403:c000:: bis 2a01:111:f403:dfff:ffff:ffff:ffff:ffff. Da ist meine Adresse nicht dabei. Also schauen wir weiter.

  • Vorherige Spambewertung
    Auch wenn ich die Mail über einen "Hybrid OnPremises Connector" samt Zertifikat über einen lokalen Exchange Server an meinen Exchange Online Tenant gesendet habe, wurde die von Exchange Online dennoch als "Spam" klassifiziert. Bei der Mails war nämlich weder der Absender noch der Empfänger in meiner Organisation und für Exchange online ist das daher keine "originating" Mail. Die Bewertung wurde mit einem ARC-Seal versehen 
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=qGyGtgUfC....VMlsw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=47DEQpj.....FU=; b=W39JQb......5tQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=fail (sender ip is
 80.66.20.27) smtp.rcpttodomain=msxfaqdev.onmicrosoft.com
 smtp.mailfrom=msxfaqdev.onmicrosoft.com; dmarc=fail (p=none sp=none pct=100)
 action=none header.from=msxfaqdev.onmicrosoft.com; dkim=none (message not
 signed); arc=none (0)
X-MS-Exchange-Authentication-Results: spf=fail (sender IP is 80.66.20.27)
 smtp.mailfrom=msxfaqdev.onmicrosoft.com; dkim=none (message not signed)
 header.d=none;dmarc=fail action=none header.from=msxfaqdev.onmicrosoft.com;
Received-SPF: Fail (protection.outlook.com: domain of
 msxfaqdev.onmicrosoft.com does not designate 80.66.20.27 as permitted sender)
 receiver=protection.outlook.com; client-ip=80.66.20.27;
 helo=mail.netatwork.de;

Der ausgehende Tenant weiß nun also, dass die Mail höchstwahrscheinlich Spam ist und routet diese Mail über einen anderen Server-Pool. Dies ist von Microsoft auch so dokumentiert.

To prevent our IP addresses from being blocked, all outbound messages from Microsoft 365 datacenter servers that are determined to be spam are sent through the high-risk delivery pool.
Quelle: Outbound delivery pools
https://learn.microsoft.com/en-us/defender-office-365/outbound-spam-high-risk-delivery-pool-about

Damit ist auch klar, warum dann der eingehende Tenant anhand der Source-IP-Adresse den SPF-Check nicht erfolgreich ausführen konnte und auch nicht sollte.

Microsoft hat also auch an solchen Missbrauchsfälle gedacht, bei denen ein Angreifer über einen eigenen Tenant mit einer fremden SMTP-Domain etwas senden könnte. Exchange Online hat in dem Fall auch kein SRS-Rewriting (EXO SRS - Sender Rewriting Scheme (SRS) )des Absenders vorgenommen.

Allerdings ist auch hier die Mail zwar im Junk-E-Mail-Ordner gelandet aber  

Test 5: DMARC=None

Zuletzt habe ich noch einen Mail mit einer schwachen DMARC-Policy gesendet. Exchange Online Protection hat ja für Quarantäne und Reject die Einstellungen korrekt angewendet. Mit p=none sagt der Absender aber, dass DMARC nicht beachtet werden sollte. Mein "SPFTest 5" wurde wieder direkt an Exchange Online gesendet.

Send-Mailmessage `
   -To clouduser1@msxfaqdev.onmicrosoft.com `
   -SmtpServer msxfaqdev.mail.protection.outlook.com `
   -Subject "SPFTest5" `
   -From clouduser1@msxfaqdev.onmicrosoft.com

Die Mail wurde von Exchange Online angenommen, als Spam klassifiziert und in die Quarantäne des Benutzers abgelegt.

Weitere Details, warum diese Mail so bewertet wurde und welchen Einfluss der SPF auf die Bewertung hatte, gibt es nicht.

Authentication-Results: spf=fail (sender IP is 80.66.20.27)
 smtp.mailfrom=msxfaqdev.onmicrosoft.com; dkim=none (message not signed)
 header.d=none;dmarc=fail action=none
 header.from=msxfaqdev.onmicrosoft.com;compauth=fail reason=601
Received-SPF: Fail (protection.outlook.com: domain of
 msxfaqdev.onmicrosoft.com does not designate 80.66.20.27 as permitted sender)
 receiver=protection.outlook.com; client-ip=80.66.20.27; helo=FC-T14G5;

Eigene Tests

Wenn Sie mal ihren Tenant mit unterschiedlichen SPF-Records ausprobieren wollen, habe ich einige Subdomains mit den vier verschiedenen SPF-Einstellungen veröffentlicht.

_spf.spfhard.msxfaqdev.de  -all
_spf.spfsoft.msxfaqdev.de   ~all
_spf.spfask.msxfaqdev.de   ?all
_spf.spfnone.msxfaqdev.de   <kein>

Wenn Sie also versuchen als "user@spfhard.msxfaqdev.de" eine Mail zu versenden, dann sollte jeder Spamfilter die Mails am besten ablehnen. Exchange Online macht dies nur wenn es auch eine DMARC-Richtlinie gibt, die ich aber nicht veröffentlicht habe.

Zusammenfassung

Microsoft macht SPF-Checks, wenn Sie einen SPF-Record veröffentlichen und beachtet auch die DMARC-Richtlinien, wenn sie eine haben. Ohne eine DMARC-Richtlinie "p=Reject" wird Exchange Online solche Phishing-Mails mit ihrer eigenen Domains als Absender annehmen und dann in die Quarantäne routen. Microsoft hat es nicht vorgesehen, eine Mail direkt abzulehnen, wenn der SPF-Check einen "HardFail" liefert und die Mail nicht anhand von DKIM gerettet wird.

Ich finde das schade, denn wenn ich als Absender einen "SPF -all" setze, dann möchte ich, dass niemand eine Mail von fremden Servern mit meiner Absenderadresse annimmt und insbesondere mein Tenant das nicht tun sollte.

Umgekehrt bedeutet dies für die eigenen Domains, dass wir möglichst schnell neben dem "SPF -all" auch noch eine strenge DMARC-Policy "p=reject" einrichten, weil nur dann solche Fälschungen nicht mehr bei Millionen Exchange Online Postfächern in die Quarantäne zugestellt werden und Anwender womöglich doch noch drauf reinfallen. Daher ist es für einen sicheren Tenant so wichtig, die Funktion Exchange DirectSend/RejectDirectSend zusätzlich zu aktivieren.

Weitere Links