External Sender Identification

Die Abwehr von Phishing ist eine kontinuierliche Herausforderung an Firmen. Anwender sind leider nicht immer erfahren genug, solche Attacken zu erkennen. Viele Firmen haben daher über Transportregeln schon eine Art "Disclaimer" an eingehende Mails addiert. Diese Funktion kommt nun auch direkt in Exchange und Outlook.

Beachten Sie dazu auch die Seite Cloud Notification Mails und Externe Mails kennzeichnen. Auch einige Mails von Systemdiensten ihres Tenants werden als "Extern" gekennzeichnet

Transport-Regel vs. Systemintegriert

Schon in der Vergangenheit habe ich bei verschiedenen Firmen mit Transportregel gearbeitet, um externe Mails zu kennzeichnen. Wir haben wahlweise im Betreff etwas angehängt aber meist wurde in die Mail an den Anfang dann ein "EXTERNAL" in der ein oder anderen Form addiert. Solche Änderungen im Body haben gleich mehrere unschöne Nachteile:

  • Digitale Signatur
    Wenn die eingehende Mail digital signiert ist und kein Signaturgateway davor die Signatur prüft aber dann entfernt oder neu signiert, dann verändert eine Transport-Regel den Body. Die Signatur wird ungültig und der Anwender sieht eine Fehlermeldung.
  • Reply-Kette
    Oft entwickelt sich aus einer Mail eine ganze Kette von Antworten (Thread). Die Anwender müssten dann die eingefügten Warnungen immer wieder entfernen, damit sie nicht im zitierten Abschnitt widerholt werden

Es ist daher schon sinnvoll, wenn ein Mailclient andere Informationen heranzieht, um den Status entsprechend anzuzeigen. Die Meldung kann sichtbar aber nicht störend angezeigt werden und stört nicht weiter die Verarbeitung.

Wenn ihr Tenant später schon "External"-Kennzeichnungen unterstützt, dann sollten Sie die Anwender informieren und dann die Transportregeln wieder deaktivieren.

Clients

Ich war natürlich neugierig, wie sich die Darstellung auf dem Client ändert. Dazu sollten Sie wissen, dass nicht alle Outlook-Versionen damit zurecht kommen. Microsoft schreibt dazu:

Use the Set-ExternalInOutlook cmdlet to modify the configuration of external sender identification that's available in supported versions of Outlook.
Quelle: https://docs.microsoft.com/de-de/powershell/module/exchange/set-externalinoutlook

Leider listet Microsoft nicht weiter, welche Versionen von Outlook hier "kompatibel" sind. Allerdings gibt es schon erste "Bilder", die eine entsprechende Anzeige in Outlook Web App, Outlook for IOS und Outlook for Android zeigen. In Outlook WebApp ist die Funktion schon mal vorhanden, dass hier die Nachricht als "Extern" gekennzeichnet wird. in meinem Outlook 365 Version 2103 Build 13901.20148 Click to Run ist die Information noch nicht zu sehen.

Client Aussehen

Outlook on the Web

Outlook 365 Windows

Outlook 365 Version 2103 Build 13901.20148 zeigt noch keine entsprechende Information

Outlook for IOS

Bei Outlook IOS ist mittlerweile auch das "Extern" vor der Mailadresse zu sehen.

Outlook for Android

Bild fehlt noch

Ich bin mal gespannt, wann vielleicht auch andere Programme diese Informationen in der Mail auswerten können oder sogar ein Standard draus werten könnte.

Einstellung per EXO PowerShell

Aktuell ist diese Funktion standardmäßig ausgeschaltet.

PS C:\> Get-ExternalInOutlook | fl enabled,AllowList

Enabled    : False
AllowList  : {}

Der einfachste Weg ist eine generelle Aktivierung:

Achtung: Wenn Sie heute schon mit Transportregeln zur Kennzeichnung externer Mails arbeiten, dann sollten Sie die Umsetzung abstimmen um Doppelkennzeichnungen zu verhindern.

Set-ExternalInOutlook `
   -Enabled $true

Nun gibt es natürlich Domains, die aus Sicht des Exchange Online Tenants zwar extern sind aber dennoch "vertrauenswürdig" sind. Diese Domains oder sogar einzelne Mailadressen können Sie per "Allowlisting" addieren. Allerdings ist das Feld auf maximal 30 Einträge und 1 kByte beschränkt.

In meinem Test-Tenant funktionierten nicht alle Parameter, wie ich mir das gewünscht hätte. Die Tests wurden mit folgender Konfiguration durchgeführt:

PS C:\ > Get-OrganizationConfig | fl *version
 
ObjectVersion               : 16500
PreviousAdminDisplayVersion : 0.10 (14.0.100.0)
RBACConfigurationVersion    : 0.1 (15.20.3933.31)
AdminDisplayVersion         : 0.20 (15.20.3933.31)
ForestConfigVersion         :
ExchangeVersion             : 0.1 (8.0.535.0)

Bei einem Tenant mit einem älteren Stand gab es die Probleme nicht. Kontrollieren Sie im Moment also immer ihre Einstellungen.

Aufruf, Ergebnis Status Ergebnis

Ausgangssituation (Default)

PS C:\ > Get-ExternalInOutlook | fl enabled,allowlist
Enabled    : False
AllowList  : {}

Das waren die Ausgangswerte in meinem Tenant

Aktivieren mit einer Domain

PS C:\ > set-ExternalInOutlook -Enabled $true -AllowList 'nospamproxy.de'
PS C:\ > Get-ExternalInOutlook | fl enabled,allowlist
Enabled    : True
AllowList  : {}

Das Flag "enabled" wird aktiviert aber die AllowList ist leer geblieben.

Konfiguration mit ADD

PS C:\> Set-ExternalInOutlook -Enabled $true -AllowList @{add="netatwork.de"}
PS C:\> Get-ExternalInOutlook | fl enabled,allowlist
Enabled   : True
AllowList : {netatwork.de }

Wenn ich die Domains mit "ADD" eintrage, dann funktioniert es

Addieren einer weiteren Domain

PS C:\> Set-ExternalInOutlook -Enabled $true -AllowList @{add="nospamproxy.de"}
PS C:\> Get-ExternalInOutlook | fl enabled,allowlist
Enabled   : TrueAllowList : {netatwork.de, nospamproxy.de}

Das hat auch problemlos funktioniert

Domain setzen

PS C:\> Set-ExternalInOutlook -Enabled $true -AllowList "msxfaq.de","msxfaq.org"
PS C:\> Get-ExternalInOutlook | fl enabled,allowlist
Enabled   : True
AllowList : {netatwork.de, nospamproxy.de, msxfaq.de, msxfaq.org}

Überraschung: meine Domains wurden addiert und haben die bestehende Liste nicht überschrieben.

Setzen mit einer Domain ohne Anführungsstriche

PS C:\> Set-ExternalInOutlook -Enabled $true -AllowList carius.de
PS C:\> Get-ExternalInOutlook | fl enabled,allowlist
Enabled   : True
AllowList : {netatwork.de, nospamproxy.de, msxfaq.de, msxfaq.org}

Auch hier hätte ich erwartet dass die Liste überschrieben wird

Einzeldomain löschen

PS C:\> Set-ExternalInOutlook -Enabled $true -AllowList @{remove="msxfaq.de"}
PS C:\> Get-ExternalInOutlook | fl enabled,allowlist

Enabled   : True
AllowList : {netatwork.de, nospamproxy.de, msxfaq.org}

Das hat dann aber wieder funktioniert.

Domainliste leeren

Set-ExternalInOutlook -Enabled $true -AllowList $null
Set-ExternalInOutlook -Enabled $true -AllowList “”

Beide Versuche haben die Liste nicht geleert

Ich gehe aber davon aus, dass Microsoft dies bald gelöst hat. Sie können also schon die Werte richtig setzen, wenn Sie denn die richtige Parameter nutzen.

Die Änderungen können angeblich 24-48 Stunden dauern. Ich vermute, dass die Änderungen im Tenant durch eine Replikation auf die "Ege-Server" weltweit übertragen werden, anhand der die Klassifizierung erfolgt.

Sonderfälle

Natürlich gibt es neben dem "ein Absender - ein Empfänger" noch weitere Kombinationen.

Fall Ergebnis

Thread beginnt mit einer intern gesendeten Mail an an interne und externe Empfänger und ein externer Empfänger antwortet

Der komplette Thread wird als "Extern" angezeigt

Externe Mail über Exchange Online Protection und Exchange Hybrid an On-Premises Postfach

Noch zu prüfen

Mail von On-Premises über Hybrid Connector zum Online User, wobei die From-Domain nicht in der AllowList steht

Noch zu prüfen

Mail von einer externen Domain aus der AllowList, die nicht per SPF/DKIM geprüft werden kann

Noch zu prüfen

Nachträgliche Änderung der AllowList. Ändert sich dann die Klassifizierung?

Noch zu prüfen

Die Checks musste ich wegen Hafnium noch etwas zurückstellen. Zudem sind noch nicht alle meine Test-Tenants umgestellt.

Internals

Natürlich wollte ich wissen, woran Outlook die Kennzeichnung fest macht und wie sich die Einstellungen während der Umstellung verhalten. Ich habe also folgendes gemacht

  • 12:11 Testmail von extern, während "ExternalInOutlook=False" war
    Damit ist eine Mail ohne Kennzeichnung angekommen
  • 12:20 "ExternalInOutlook=False" auf True gesetzt
    Die Aktivierung kann laut Microsoft 24-438 Stunden dauern
  • 13:36:Testmail von extern
    Diese Mail wurde auch noch nicht gekennzeichnet
  • 18:23:Testmail von extern
    Diesmal wurde die Mail gekennzeichnet
  • 18:28: "ExternalInOutlook=True" auf False gesetzt
    Auch dies wird wieder etwas dauern

Die Mails habe ich per Thunderbird und SMTP  über IONOS als Provider an meinen Exchange Online Tenant gesendet und mit Outlook on the Web angezeigt. Hier

Wenn ich mir das anschaue, dann sieht man, dass die Mail um 18:23 korrekt gekennzeichnet ist aber bestehende Mails nicht nachverarbeitet wurden. Die Einstellung scheint also nicht auf den Outlook Client per Richtlinie zu wirken, der dann einfach anhand der bereits vorhandenen Header u.a. die Mails als Extern erkennt, sondern der Exchange Online Transport muss hier irgendetwas anders setzen. Damit war meine Neugier natürlich geweckt, dieses Flag zu finden und zu prüfen, ob man dies auch anderweitig setzen kann. Daher habe ich mir die Mails mit Microsoft Graph genauer angeschaut.

Beim direkten Vergleich der Mails von 18:23 und 13:36 haben sich aber nur die erwarteten Felder geändert aber keinen Hinweis auf ein Property.

Im zweiten Schritt habe ich mir dann die kompletten SMTP-Header der beiden Mails betrachtet und hier wurde ich im Header "X-MS-Exchange-ExternalInOutlookResult" fündig:

X-MS-Exchange-ExternalInOutlookResult: IsExternal
X-MS-Exchange-ExternalInOutlookResult: NotEnabled 
X-MS-Exchange-ExternalInOutlookResult: IsInternal 

Wenn Sie das Feature abschalten, steht dort ein "NotEnabled" drin und wenn Sie die Funktion aktivieren, dann steht dort entweder ein  "isExternal" oder "IsInternal" drin. Outlook nutzt also NICHT die bekannten Felder wie:

X-MS-Exchange-Organization-MessageDirectionality: Incoming
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEnX-MS-Exchange-CrossTenant-FromEntityHeader: Internet

Sie können sich sicher denken, was als nächstes kommt. Ich habe natürlich versucht das Feld zu spoofen:

 

Interessant fand ich hier aber nun, dass der Header tatsächlich zweimal in der Mail auftaucht. 

Im Posteingang habe ich aber nun den Status "Znverified". In der Mail selbst sehe ich aber schon, dass die Mail als "outside" gelistet wird aber wohl der fehlende SPF/DKIM-Check

Sobald ich wieder eine Mail mit SPF/DKIM=PASS sende, sehe ich die Mail mit "External" aber ohne das "Unverified". Allerdings habe ich keinen Header gefunden, der das "Unverified" triggert. In der "Fälschung"-Mail war nur folgender Eintrag

Authentication-Results: spf=fail (sender IP is 80.66.20.27)
 smtp.mailfrom=carius.de; dkim=none (message not signed)
 header.d=none;dmarc=fail action=none header.from=carius.de;compauth=fail
 reason=001
X-MS-Exchange-ExternalInOutlookResult: IsExternal

In der korrekten Mail waren drei "Authentication"-Einträge"

Authentication-Results: spf=pass (sender IP is 2a01:111:f403:c20c::4)
 smtp.mailfrom=Netatwork.de; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=Netatwork.de;compauth=pass
 reason=100
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=netatwork.de; dmarc=pass action=none header.from=netatwork.de;
 dkim=pass header.d=netatwork.de; arc=none
Authentication-Results-Original: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=Netatwork.de;
X-MS-Exchange-ExternalInOutlookResult: IsExternal

Auch eine weiteren Testmail war nur folgender Eintrag, um die Mail als "External" und nicht als "Unverified" zu kennzeichnen

Authentication-Results: spf=pass (sender IP is 212.227.126.134)
 smtp.mailfrom=carius.de; dkim=pass (signature was verified)
 header.d=carius.de;dmarc=pass action=none header.from=carius.de;compauth=pass
 reason=100
X-MS-Exchange-ExternalInOutlookResult: IsExternal

Also habe ich versucht eine Mail zu senden, in der nicht nur das Flag sondern auch gleich ein AuthHeader mitgeliefert wird:

Dennoch war auch diese Mail "Unverified" und im Header waren beide Einträge enthalten.

Authentication-Results: spf=fail (sender IP is 80.66.20.27)
 smtp.mailfrom=carius.de; dkim=none (message not signed)
 header.d=none;dmarc=fail action=none header.from=carius.de;compauth=fail
 reason=001
Authentication-Results-Original: spf=pass (sender IP is 1.2.3.4)
 smtp.mailfrom=carius.de; dkim=pass (signature was verified)
 header.d=carius.de;dmarc=pass action=none header.from=carius.de;compauth=pass
 reason=100
X-MS-Exchange-ExternalInOutlookResult: IsInternal
X-MS-Exchange-ExternalInOutlookResult: IsExternal

Wie genau Outlook die Felder auswertet, kann ich nicht sagen. Hier wären sicher noch weitere Tests notwendig.

Interessant finde ich, dass Exchange hier seine "Header Firewall" nicht nutzt und meine von extern gesetzte "X-MS-Exchange-ExternalInOutlookResult"-Header nicht entfernt oder überschreibt.

Deaktivierung

Natürlich habe ich danach die Einstellung wieder abgeschaltet und mit etwas Verzögerung eine externe Testnachricht gesendet, die aber korrekt SPF/DKIM-signiert war. Sie kam auch ohne Probleme und ohne sichtbare Kennzeichnung an:

Im Header stand aber, wie erwartet das Feld:

X-MS-Exchange-ExternalInOutlookResult: NotEnabled

Interessant finde sich aber, dass auch die früher als "Extern" gekennzeichneten Nachrichten nicht mehr  als solches markiert waren. Im Header stand aber immer noch das "X-MS-Exchange-ExternalInOutlookResult: IsExternal" drin.

Ich muss das so interpretieren, dass nicht nur der Header gesetzt wird, sondern zumindest "Outlook on the Web" per Provisoining mitgeteilt bekommt, ob es das Feld auswerten soll.

Früher empfangene Mails haben natürlich weiterhin das "NotEnabled" und werden nicht entsprechend gekennzeichnet. Es gibt wohl keinen Prozess, um nachträglich die Kennzeichnung von bereits empfangenen Mails zu aktualisieren. 

Hinweis:
In dem Zuge noch eine Auffälligkeit: Es macht einen Unterschied, ob ich mir in OWA in Exchange Online die Header direkt im Browser anzeige oder die Mail als EML/MSG-Datei herunterlade. Im Browser als auch in der per Outlook geöffneten MSG-Datei sehe ich die Header. In der heruntergeladenen EML-Datei aber fehlen einige Header. Als wenn Exchange hier nur eine Teilmenge anzeigt.

Transportregel

Für einen Einsatz z.B. in NoSpamProxy o.ä. habe dann noch geprüft, ob eine Transportregel das Feld setzen/überschreiben kann, wenn ich es von extern zwar einliefern kann, aber Exchange Online ein eigenes Feld addiert. Dazu habe ich mir eine Regel mit meiner Absenderdomain addiert:

Das hat aber nichts geholfen, denn die Regel wurde zwar ausgeführt, aber das Feld wurde nicht "ersetzt" sondern Microsoft hat sein Feld einfach ein zweites Mal addiert.

X-MS-Office365-Filtering-Correlation-Id: a64f5c9a-2a63-43fc-4331-08de664e73fa
X-MS-Exchange-ExternalInOutlookResult: IsRule
X-MS-Exchange-ExternalInOutlookResult: NotEnabled
X-Microsoft-Antispam-Mailbox-Delivery:
	wl:1;pcwl:1;ucf:0;jmr:0;auth:0;dest:I;ENG:(910005)(944506478)(944626604)(920097)(811242)(255002)(410001)(930201)(20251009147)(140003);
X-Microsoft-Antispam-Message-Info:
	=?us-ascii?Q?T8yCk/D52uvOScX7C6+yZy4fxWG7XsxxJ8eEM53HRS4mIeh9X579PNobj0DZ?=

Ich habe danach die Funktion noch mal aktiviert, um zu sehen, ob sich etwas verändert. Die Mail und alle früher ebenfalls empfangenen Mails wurden dann wieder als Extern gekennzeichnet

 

Im Header war die Zeile "X-MS-EXchange-ExternalInOutlookResult" wieder zweimal vorhanden

Mir ist es nicht gelungen, durch eine Transportregel den bestehenden Eintrag zu überschreiben oder dahinter zu setzen.

Anscheinend addiert Microsoft den Header erst kurz vor dem Ablegen der Mail im Postfach. Damit ist auch verständlich, dass Transportregeln und Header-Firewall nicht funktionieren.

API mit Microsoft Graph

Aufgrund der Exchange Online EWS Abschaltung 2026 beschränke ich mich auf Microsoft Graph. Die Information über "ExternalInOutlookResult" steht leider nicht direkt in den Metadaten einer Mail, sondern stehen nur in den Internet-Headern. Diese lassen sich z.B. in Graph Explorer wie folgt für das eigene Postfach abrufen.

https://graph.microsoft.com/beta/me/messages?$select=internetMessageHeaders&$top=1

In der Antwort finden wir dann alle InternetHeader und dazwischen auch "X-MS-Exchange-ExternalInOutlookResult".

Ich habe aber keinen weg gefunden, per Graph eine Mail als EML oder MSG-Datei hochzuladen. Anscheinend geht auch das wieder nur per IMAP4 oder der Graph /mport/Export-API, wobei ich nicht weiter geprüft habe.

Einschätzung

Auch wenn es nach einer Kleinigkeit aussieht, finde ich den Ansatz von Microsoft sehr gut, externe und damit nicht verifizierte Mails zu kennzeichnen. Als Administrator sollten Sie aber darauf achten, dass nur solche Domains auf die AllowList kommen, die auch korrekt per SPF, DKMIM und DMARC eine Verifizierung des Absenders zulassen und nicht zugelassende Quellen per "REJECT-Policy" auch unterbinden. Alternativ können Sie in Exchange auch einen "Partner Connector" zu diesen Domänen einrichten, die z.B. TLS erzwingen.

Vergessen Sie aber nicht, ihre Anwender über diese neue Funktion zu Informieren. Nur dann funktioniert der Schutz, wenn die Anwender das "Extern" zu deuten wissen und entsprechend sensibel damit umgehen.

Weitere Links