ARC mit Exchange Online

Exchange Online unterstützt SPF, DKIM, DMARC, DANE aber auch ARC. Diese Seite betrachtet die ARC-Funktion von Exchange Online und wie sie im Header von eingehenden Mails die entsprechenden Zeilen interpretieren.

SPF, DKIM und ARC

Sie können heute keinen Mailserver ohne Spamfilter betreiben. Aber auch beim Versand sollten Sie als seriöse Firma für ihre Domains der Welt helfen ihre Mails zu qualifizieren. Dazu gehört die Veröffentlichung der eigenen ausgehenden Mailserver über einen SPF-Record. Das reicht aber nicht, denn Anwender sehen den Absender vom Anschreiben aber nicht vom Umschlag. Wer mit DMARC wird auch die Domain auf dem Anschreiben einbezogen. Mittels DKIM können Absender ihre Mails über eine digitale Signatur als authentisch kennzeichnen. Dazu wird z.B. über Absender, Empfänger, Betreff, Datum aber auch der Body ein Hashwert gebildet, der dann mit einem privaten Schlüssel signiert wird. Der Empfänger kann die Signatur über den per DNS zur Domain veröffentlichen öffentlichen Schlüssel verifizieren.

SPF funktioniert aber nur, wenn der empfangende Server die Mail direkt vom Absender bekommt. Umleitungen funktionieren nicht. DKIM löst das Problem, wenn die Mail nicht verändert wird. Genau das passiert aber bei Weiterleitungen, wenn ein eigentlich legitimes Relay-System z.B. eine Warnung in den Betreff oder den Anfang der Mail schriebt, dass die Mail extern war.

Das Zielsystem "B" mit dem Postfach kann dann weder SPF noch DKIM prüfen. Die einliefernde IP-Adresse ist "P.P.P.P" und nicht im DNS-Eintrag der Zone "A.TLD" aufgeführt. Da das Relay in der Mail auch noch eine Warnung in den Nachrichtentext addiert hat, passt auch der Hashwert nicht mehr bei der DKIM-Prüfung.

Hier kommt ARC zum Tragen, dass das eigentlich vertrauenswürdige Relay-System seinerseits DKIM prüft und dann die Mail selbst noch einmal signiert.

Das Relay kann natürlich nicht mit der Domain "A.tld" signieren sondern nur mit seiner Domain "p.tld" (Vereinfachtes Bild). Aber das empfangende System kann ein Vertrauen aussprechen, d.h. "b.tld" vertraut "p.tld" als Signierer für beliebige Domains. ARC und DKIM sind keine Bausteine, um Spam-Nachrichten zu erkennen sondern helfen "gute" Nachrichten anhand des Absender verifizieren zu können.

Exchange Online und ARC-Trust

Genau das können Sie in Exchange Online als Administrator konfigurieren. Sie addieren im Security Center einfach die Domain, mit welcher die Zwischenstation signiert.


https://security.microsoft.com/authentication

Das können Sie natürlich auch per Exchange Online PowerShell setzen:

Set-ArcConfig `
   -Identity Default `
   -ArcTrustedSealers "p.tld","nospamproxy.de"

Wenn nun eine Zwischenstation eine entsprechender ARC-Seal anbringt, dann kann das Ziel das nicht nur prüfen sondern vertraut auch darauf, dass zumindest eine DKIM-Signatur damals korrekt war.

ARC-Header

Die Funktion und Informationen zu ARC finden Sie im SMTP-Header einer Mail. Wenn Sie eine Mail mit Outlook oder SMTP an ihren eigenen Mailserver einliefern, dann sollte er ausgehend die Mails per DKIM signieren und gerne auch mit einem ArcSeal. Bei Exchange Online sollten Sie dazu die entsprechenden DKIM-Einträge in ihrer DNS-Zone anlegen und prüfen, dass DKIM-Signierung aktiv ist:

Wenn Sie dann eine Mail von einem Postfach aus ihrer Domain in die Welt senden, kann der Empfänger die folgenden Header sehen. Ich habe mir dazu eine Mail von diesem Tenant an mein Postfach gesendet und per POP3 abgeholt:

Hier sehen wir nun jede Menge markierte Bereiche. Wir lesen die Mail von unten nach oben:

Zeile 

Feld

Bedeutung

28/29/30

 
From/To/Subject

Das ist die eigentliche Mail mit dem vorgeblichen Absender und Empfänger

25-27 

 
Received

Der erste "Received"-Header sagt mir, dass ich die Mail per MAPI an den ersten Exchange Online Server eingeliefert haben

16-20

 
DKIM-Signature

Exchange Online hat die Mail mit einer DKIM-Signatur versehen. Meine Absenderdomain (Zeile 28) ist "msxfaqdev.onmicrosoft.com" und die Domain finden Sie auch im Feld "d=". Über den Selector "s=selector1-msxfaqdev-onmicrosoft-com" können Sie den dazu passenden Schlüssel per DNS abrufen:

C:\> nslookup -q=TXT selector1-msxfaqdev-onmicrosoft-com._domainkey.msxfaqdev.onmicrosoft.com

selector1-msxfaqdev-onmicrosoft-com._domainkey.msxfaqdev.onmicrosoft.com text = "v=DKIM1; k=rsa; p=MIIBIj.....AB;"

Das Feld "h=" führt die Felder auf, die in die Hash-Berechnung einbezogen werden sollen. Die Errechnung der Hashwerte und Prüfung erspare ich mir hier.

12-15

 
ARC-Authentication-Results

Interesssant ist, dass Microsoft selbst seine eigenen ausgehende Mails prüft und als "ARC-Authentication-Results"-Header mit beifügt. Die Mail hat hier Exchange Online noch nicht verlassen. Die erfolgreiche Prüfung ist aber die Basis für die nächsten Zeilen. Es könnte ja auch eine Mails sein, welche von OnPremises über einen Hybrid-Connector eingeliefert und durch Exchange versendet wird. Hier wäre Exchange Online dann nicht zwingend die Instanz, die DKIM prüft.

7-11

 
ARC-Message-Signature

Die vorherige DKIM-Prüfung wird nun genutzt, um eine ARC-Message-Signature anzufügen. Das Format ist einer DKIM-Signatur sehr ähnlich.

6

 
ARC-Seal

Zusätzlich wird die Nachricht auch noch mit einem ARC-Seal versehen. Auch hier sagt "d=microsoft.com", dass Microsoft das Feld addiert hat und die Gegenstelle die Gültigkeit wieder per DNS prüfen kann.

C:\> nslookup -q=TXT arcselector10001._domainkey.microsoft.com

arcselector10001._domainkey.microsoft.com text = "v=DKIM1; k=rsa; p=MIIBI......B"

3-5 

Received

Jetzt erst wurde die Mail von Microsoft an einen IONOS-Mailserver geroutet, der dann diesen Header addiert hat.

2

 
Authentication-Results 

IONOS protokolliert hier die Ergebnisse seiner Prüfung und meldet ein DKIM=PASS

NA

 
Received-SPF 

Dieser Header ist in dieser Mail nicht zu finden gewesen aber in anderen Mails habe ich ihn gefunden´.

NA

 
Authentication-Results-Original

Diesen Header sehe ich, wenn eine von einem authentifizierten Client, z.B. Outlook, eingeliefert Mail vom ersten Exchange Online Server geprüft wird.

Wir wissen nun, welche Felder vom Versender addiert werden und welche Felder bei, Empfänger hinzu kommen. 

Eingehende Steuerung

In Grenzen können Sie für ihren Tenant sogar die Bewertung eingehender Mails anpassen. Die Standardeinstellungen sind: 


https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-about?view=o365-worldwide#spoof-settings

Die Einstellmöglichkeiten zur DMARC-Übersteuerung finden Sie wieder im Microsoft Defender Admin Portal:


Quelle: https://security.microsoft.com/antiphishing

Bei mir waren die Einstellungen so, dass Exchange Online sich an die Empfehlungen der Absenderdomain hält.

dmarc=fail action=oreject

Selbst wenn sie vielleicht alles richtig eingestellt haben, kann es sein dass Exchange Online die Mail dennoch zustellt und nicht ablehnt. Wenn Sie dann in den Header schauen, dann steht da vielleicht ein "action=oreject", was letztlich bedeutet, dass Exchange Online die "reject"-Vorgabe des Absender ignoriert hat. Microsoft steht da etwas in einer Zwickmühle, denn es gibt Firmen, die eine "DMARC-Policy=reject" veröffentlichen aber dann nicht alle Mails der Domain die Anforderungen an SFP und DKIM erfüllen. Anscheinend gibt es dann viele Absender, die den Fehler bei Microsoft suchen, wenn ihre Mails nicht zugestellt werden. Ebenso wird es einige Exchange Online-Kunden geben, die "vermisste Mails" oder Mails in der Quarantäne ebenfalls Microsoft ankreiden.

Kontrollieren Sie dann bitte ihre Einstellungen im Defender Portal.

ARC und Inbound Connector

Auf der empfangenden Seite hat mich interessiert, ob es einen Unterschied bei der Behandlung gibt, wenn die Mail über den "Standard Connector" bei Exchange Online ankommt, über NoSpamProxy als Cloud-Relay oder sogar über einen "Hybrid Connector" von einem OnPremises Server eingeliefert wird. Ich habe wieder einige Test-Mails versendet

Szenario  Beschreibung
Hybrid Connector
Kein DKIM
DMARC=none

Internet (noDKIM/DMARC-None) ->  Exchange 2019 -> Hybrid  -> Exchange Online 

Diese Mail war nicht DKIM-signiert. Im Exchange Online Postfach sind nur folgende Header sichtbar geworden:

Authentication-Results: spf=fail (sender IP is 80.66.20.27)
 smtp.mailfrom=carius.de; dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=carius.de;
Received-SPF: Fail (protection.outlook.com: domain of carius.de does not
 designate 80.66.20.27 as permitted sender) receiver=protection.outlook.com;
 client-ip=80.66.20.27; helo=mail.netatwork.de;

Es fehlen natürlich die Header die "DKIM-Signature", "ARC-Message-Signature" und "ARC-Seal". Exchange prüft aber auch bei einer eingehende Mail über den Hybrid Connector (Org to EXO) sowohl SPF, DKIM und DMARC. Die IP-Adresse war natürlich nicht im SPF-Record und ohne DKIM-Signatur kann auch das nur ein "FAIL" werden. Damit die Mail dennoch ankommt, habe ich die DMARC-Policy auf "none" gestellt.
Hybrid Connector
Kein DKIM
DMARC=reject 

Internet (noDKIM/DMARC-Reject) ->  Exchange 2019 -> Hybrid  -> Exchange Online

Ich habe den Test dann noch einmal mit einer Domain wiederholt, die eine DMARC-Policy=reject hat. Auch hier waren die Header identisch. Wir sehen aber das "action=oreject"

Authentication-Results: spf=fail (sender IP is 80.66.20.27)
 smtp.mailfrom=msxfaq.net; dkim=none (message not signed)
 header.d=none;dmarc=fail action=oreject header.from=msxfaq.net;
Received-SPF: Fail (protection.outlook.com: domain of msxfaq.net does not
 designate 80.66.20.27 as permitted sender) receiver=protection.outlook.com;
 client-ip=80.66.20.27; helo=mail.netatwork.de;

Auch hier sind eigentlich SPF=Fail und DKIM=none und DMARC weist den Empfänger eigentlich an, die Mail abzulehnen. Aber das "oreject" ist ein "Overwrite Reject".

 
Kein Connector
DMARC=reject

Exchange Online mit DKIM -> Exchange Online

Ich habe dazu einfach auf meiner msxfaqdev.onmicrosoft.com als Absender einmal DMARC=reject und DKIM aktiviert und dann eine Mail an meine msxfaqlab.onmicrosoft.com gesendet. Entsprechend gibt es hier dann einige Header zu sehen. Die Reihenfolge ist wieder von unten nach oben und die "Received"-Zeilen und Hashwerte sind gekürzt

Received: from FR6P281MB3950.DEUP281.PROD.OUTLOOK.COM by FR0P281MB1770.DEUP281.PROD.OUTLOOK.COM
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
 b=eVRrhf....==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:C...;
 bh=zZjQ....=; b=zR2YB....fQ==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
 40.107.149.125) smtp.rcpttodomain=msxfaqlab.onmicrosoft.com
 smtp.mailfrom=msxfaqdev.onmicrosoft.com; dmarc=pass (p=reject sp=reject
 pct=100) action=none header.from=msxfaqdev.onmicrosoft.com; dkim=pass
 (signature was verified) header.d=msxfaqdev.onmicrosoft.com; arc=pass (0
 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=msxfaqdev.onmicrosoft.com]
 dkim=[1,1,header.d=msxfaqdev.onmicrosoft.com]
 dmarc=[1,1,header.from=msxfaqdev.onmicrosoft.com])
Received: from FR4P281CA0273.DEUP281.PROD.OUTLOOK.COM by FR6P281MB3950.DEUP281.PROD.OUTLOOK.COM
Received: from FR1PEPF00000F0F.DEUP281.PROD.OUTLOOK.COM by FR4P281CA0273.outlook.office365.com
Authentication-Results: spf=pass (sender IP is 40.107.149.125)
 smtp.mailfrom=msxfaqdev.onmicrosoft.com; dkim=pass (signature was verified)
 header.d=msxfaqdev.onmicrosoft.com;dmarc=pass action=none
 header.from=msxfaqdev.onmicrosoft.com;compauth=pass reason=100
Received-SPF: Pass (protection.outlook.com: domain of
 msxfaqdev.onmicrosoft.com designates 40.107.149.125 as permitted sender)
 receiver=protection.outlook.com; client-ip=40.107.149.125;
 helo=FR5P281CU006.outbound.protection.outlook.com; pr=C
Received: from FR5P281CU006.outbound.protection.outlook.com by FR1PEPF00000F0F.mail.protection.outlook.com
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=WgWiG.....==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Mes....
 bh=zZjQv....;
 b=BuwkUD7....==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=msxfaqdev.onmicrosoft.com; dmarc=pass action=none
 header.from=msxfaqdev.onmicrosoft.com; dkim=pass
 header.d=msxfaqdev.onmicrosoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=msxfaqdev.onmicrosoft.com; s=selector1-msxfaqdev-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=zZjQvN....;
 b=Pibi...
Received: from BEZP281MB1864.DEUP281.PROD.OUTLOOK.COM by BE1P281MB3042.DEUP281.PROD.OUTLOOK.COM 
Received: from BEZP281MB1864.DEUP281.PROD.OUTLOOK.COM with mapi id 15.20.8182.018
From: Frank Carius DEV <adminfc@msxfaqdev.onmicrosoft.com>
To: Frank Carius <fcadmin@msxfaqlab.onmicrosoft.com>
Subject: Test EXO->EXO
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=msxfaqdev.onmicrosoft.com;

Wir starten unten mit Authentication-Results-Original als erste Prüfung nach der Einlieferung. und sehen dann die ersten DKIM und ARC-Signaturen, ARC-SEALs. Der Header "Received-SPF" zeigt an, dass hier wohl der Übergang von einem Tenant zum anderen Tenant erfolgt ist. Alles danach ist dann die Empfangsseite und daher folgt ein "Authentication-Results" und zwei Stationen weiter dann "ARC-Authentication-Results".

In den "ARC-Authentication-Results" sehen Sie nun auch, dass er die vorherigen ARC-Seals und DKIM-Bewertungen bestätigen konnte. Und dann bringt Exchange Online beim Empfänger tatsächlich noch mal ein ARC-Seal auf, obwohl die Mail eigentlich direkt im Postfach landet. Aber es könnte ja noch eine Weiterleitung danach kommen.

Partner Connector

Wenn ich die Mail eingehend über einen Partner-Connector zuordne, dann ändert sich nichts zum Empfang ohne Connector.
 

Im November 2024 scheint Exchange Online jede eingehende Mail, egal über welchen Weg sie eingeliefert wird, auf DKIM zu prüfen und die Ergebnisse der Prüfung auch im Header zu protokollieren aber Mails, die über einen "Partner Inbound Connector" oder den "Default Inbound Connector" kommen, werden auch noch einmal mit einem ARC-Seal versehen.

Damit ist aber noch nicht geklärt, wie nun Defender mit dem Ergebnis der Prüfung umgeht. Das steuern Sie als Administrator im Defender Admin Center (https://security.microsoft.com/antiphishing) unter der "Anti-Phishing"-Policy.

Microsoft hat das schon richtig eingeordnet, denn SPF, DKIM und DMARC sind keine Antispam-Komponenten sondern helfen gegen Phishing mit einer fremden SMTP-Domain.

Defender AntiPhishing Center
https://security.microsoft.com/antiphishing

Announcing New DMARC Policy Handling Defaults for Enhanced Email Security
https://techcommunity.microsoft.com/blog/exchange/announcing-new-dmarc-policy-handling-defaults-for-enhanced-email-security/3878883

Anti-phishing policies in Microsoft 365
https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-about?view=o365-worldwide

Microsoft 365: "action=oreject" and what to do about it
https://support.valimail.com/en/articles/9143109-microsoft-365-action-oreject-and-what-to-do-about-it  

ARC über Hybrid-Versand

Sie können bei einer Hybrid-Bereitstellung den lokalen Exchange Server auch so konfigurieren, dass er alle Mails über den Hybrid Connector zu Exchange Online sendet und Exchange Online diese Mails dann ins Internet routet. Dazu muss der Exchange Online Service natürlich sicher sein, dass die Mail von einem authentifizierten Absender kommt. Eine korrekte Konfiguration des Hybrid Mailrouting mit einem "Organization Connector" ist hier natürlich erforderlich. Die Mail lief folgende Stationen:


SMTP -> Exchange 2019 --(Hybridconnector)--> Tenant1 -> NoSpamProxy ---(MX)--->Tenant2

Der OnPremises Exchange 2019 hat keinerlei SPF/DKIM/DMARC-Unterstützung und auf dem Exchange Online von Tenant1 war zu dem Zeitpunkt DKIM-Signierung nicht aktiviert. Im Zielpostfach sind einige Header auftauchen, habe ich die Header aufgeteilt und lesen Sie die Tabelle von unten nach oben.

Header Bedeutung  
Received: from BE1P281MB3203.DEUP281.PROD.OUTLOOK.COM (2603:10a6:b10:6b::11)
 by BEZP281MB1864.DEUP281.PROD.OUTLOOK.COM with HTTPS; Fri, 22 Nov 2024
 00:34:48 +0000
Received: from FR4P281CA0048.DEUP281.PROD.OUTLOOK.COM by BE1P281MB3203.DEUP281.PROD.OUTLOOK.COM
Received: from FR3PEPF00000486.DEUP281.PROD.OUTLOOK.COM by FR4P281CA0048.outlook.office365.com

Die letzten Stationen bis zum Postfach.

 
Authentication-Results: spf=pass (sender IP is 193.37.132.219)
 smtp.mailfrom=netatwork.de; dkim=fail (signature syntax error)
 header.d=none;dkim=pass (signature was verified)
 header.d=Netatwork.de;dmarc=pass action=none
 header.from=Netatwork.de;compauth=pass reason=100

Der SPF=Pass steht auch im Header "Authentication-Results" aber anscheinend stört sich Exchange Online an der "a=ed25519-sha256"-Signatur.

 
Received-SPF: Pass (protection.outlook.com:
 domain of netatwork.de designates 193.37.132.219 as permitted sender)
 receiver=protection.outlook.com;
 client-ip=193.37.132.219;
 helo=de-s111-gw2.mail.cloud.nospamproxy.com; pr=C

Die eingehende Prüfung der Absenderdomain "netatwork.de" gegen den SPF-Eintrag war erfolgreich. 

 
Received: from de-s111-gw2.mail.cloud.nospamproxy.com by FR3PEPF00000486.mail.protection.outlook.com
Received: from 40.93.77.5 by de-s111-gw2.mail.cloud.nospamproxy.com

NoSpamProxy hat Tenant2 über MX-Record aufgelöst und an Tenant2 zugestellt.

 
Received: from 40.93.77.5 by de-s111-gw2.mail.cloud.nospamproxy.com

Exchange Online von Tenant1 hat die Mail an NoSpamProxy zum Versand übertragen.

 
DKIM-Signature: v=1; c=relaxed/relaxed; d=Netatwork.de; s=dkim1e;
 t=1732235683; bh=ZN5YeR....;
 h=Subject:Subject:From:From:Date:Date:ReplyTo:ReplyTo:Cc:Cc:Message-Id:Message-Id;
 a=ed25519-sha256; b=Obfsof....
DKIM-Signature: v=1; c=relaxed/relaxed; d=Netatwork.de; s=dkim1r;
 t=1732235683; bh=ZN5YeR......;
 h=Subject:Subject:From:From:Date:Date:ReplyTo:ReplyTo:Cc:Cc:Message-Id:Message-Id;
 a=rsa-sha256; b=d1wAJO...

NoSpamProxy addiert zwei DKIM-Signaturen mit den beiden Hashverfahren a=ed25519 und a=rsa-sha256. Mehrere DKIM-Signaturen sind kein Problem und der Empfänger sollte auch alle durchprobieren. Solange eine DKIM-Signatur gültig ist, ist DKIM=pass.

 
From: "Carius, Frank (NAW)"
To: "adminfc@msxfaq.net" 
Subject: Test NAW->EXO->NSP->INET->EXO

Hier habe ich den Absender und Empfänger als Teil des Header belassen, weil ich damit zeigen kann, dass der nächste Header unterhalb dieser Felder steht.

 
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=Netatwork.de;

Dieser Header war unter den Feldern "To/From/Subject", was ich etwas suspekt finde. Ich habe leider nicht die Mail über den Hybrid Connector mitgeschnitten aber ich vermute, dass Exchange Online diesen Header addiert, denn Exchange 2019 macht eigentlich keine DKIM/DMARC-Authentication.

Genaugenommen könnte ich auch noch auf dem Exchange Online Server von Tenant1 für die Absenderdomain zusätzlich DKIM aktivieren. In dem Fall hätte die Mail dann drei DKIM-Signaturen. Der "Selector" von NoSpamProxy unterscheidet sich ja vom Selector von Microsoft 365, so dass dies problemlos möglich ist.

Weitere Links