Cloud Notification Mails

Ich bin sicher, dass Sie auch die Benachrichtigungen von Microsoft Diensten bekommen, wenn Sie aus Sicht der Cloud etwas verpassen könnten. Für Teams gibt es die gesonderten Seiten Teams Channel Mail und UnifiedGroups Mailrouting. Aber es gibt noch viel mehr Nachrichten von Microsoft, die möglichst nicht im Spamfilter hängen bleiben sollten. Sie können aber nicht einfach die IP-Adressen von Microsoft freischalten, da Sie ja auch von anderen Tenants genutzt werden können. Diese Seite fasst die verschiedenen Quellen und deren technischen Besonderheiten zusammen.

Übersicht

Auch wenn Microsoft und viele "Berater" das Thema Modern Work, (Siehe auch Mail, Blog, Sharing) stressen und Mails als "Tod" anzeigen, landen auch in meinem Postfach immer wieder Nachrichten verschiedener Prozesse. Mail ist eben immer noch das primäre Mittel, um eine Person über eine offene Aktivität zu informieren.

Zu diesen und anderen Nachrichten haben ich mit den Header angeschaut, um die folgenden Informationen zu extrahieren:

  • Header-From Absender
    Das ist die Adresse, die Outlook anzeigt.
  • DKIM
    Wurde die Mail per DKIM signiert und war die DKIM-Signatur gültig? Wenn es über mehrere Relays gegangen ist, ist natürlich die DKIM-Signatur zum Absender maßgeblich. Wenn die Mails durch einen eigenen Mailrelay laufen, kann
  • SPF
    von welchem IP-Bereich wurde die Mail versendet und hatte Sie einen gültigen SPF-Eintrag
  • Transport
    Über welchen Eingang ist die Mail angekommen. Zieladresse war immer eine Firmenadresse, deren MX-Record auf einen anderen Eingang verwiesen hat aber dann wieder zu, Postfach zu Exchange Online geroutet wurde

Das waren meine Ergebnisse vom Feb 2022. Das Verhalten kann sich jederzeit ändern:

Service "Header-From"-Absender DKIM SPF Transport Beschreibung

Azure ADSync Errros

<Azure-noreply@microsoft.com>

Entfällt

Entfällt

Internet über MX-Record

Wenn ihre ADSync-Instanz auf Replikationsfehler stößt, kann es Globale Administratoren und manuell hinterlegte Mailadressen informieren.

Azure AD Gast Einladungen

invites@microsoft.com

Entfällt

Entfällt

Internet über MX-Record

52.101.57.24

Eine Einladung als Gast in einem anderen Tenant mitzuarbeiten, wird per MX-Record zugestellt-.

Teams Group Mail
Intern

Event Team 
<EventTeam2@msxfaq2.net>
Event Team 
<EventTeam2@msxfaq.onmicrosoft.com>

Entfällt

Entfällt

Interne SMTP-Zustellung

Eine Meldung vom Kanal an einen Benutzer im gleichen Tenant wird direkt intern per SMTP zugestellt.

Teams Group Mail
Extern

Event Team 
<EventTeam2@msxfaq2.net>
Event Team 
<EventTeam2@msxfaq.onmicrosoft.com>

Check
dkim=pass

Check

OK

Internet über MX-Record

40.107.14.132

Nachrichten an externe Empfänger werden per MX-Record zugestellt. Mit eigenen Domains müssen Sie die Office 365 Server im SPF-Eintrag und als DKIM-Eintrag addieren.

Teams Benachrichtigung

Displayname in Teams
<noreply@email.teams.microsoft.com>

dkim=pass

NoSPF

Internet über MX-Record

40.107.244.64

Wenn Sie auf Nachrichten in Teams nicht reagieren, bekommen Sie in der Regel nach ca. einer Stunde eine Benachrichtigung.

SharePoint Benachrichtigung

SharePoint Online
<no-reply@sharepointonline.com>	

dkim=pass

OK

Internet über MX-Record

40.107.14.132

Hier sind keine Besonderheiten zu erwarten.

SharePoint/Onedrive Passcodes

no-reply@notify.microsoft.com

dkim=pass

OK

Internet über MX-Record

Seit Juli 2022 nutzt Microsoft diese Adresse als Absender für Benachrichtigungen.

  • MC394980 [OneDrive for Business, SharePoint Online] SharePoint & OneDrive External Sharing One-Time Passcode mails will now come from no-reply@notify.microsoft.com [MC394980]

Viva

Microsoft Viva 
<viva-noreply@microsoft.com>

Entfällt

NA

Lokale Zustellung!

Die Mail wird nicht per SMTP übertragen oder zugestellt. Die "Internet Header" sind leer. Die Mail wurde direkt ins Postfach abgelegt. Sie erscheint aber nicht einmal im Exchange Messagetracking.

Message Center

Microsoft 365 Message center
<o365mc@microsoft.com>

dkim=pass

OK

Internet über MX-Record

52.234.172.97

Neue Funktionen ihres Tenants werden nicht nur im Portal angezeigt, sondern können auch per Mail zugestellt werden.

Azure DevOps

Azure DevOps
<azuredevops@microsoft.com>

dkim=pass

OK

Internet über MX-Record

52.185.106.244

Auch die Entwickler-Meldungen kommen von Microsoft

Microsoft Defender

Microsoft 365 Defender
<defender-noreply@microsoft.com>

dkim=pass

OK

Internet über MX-Record

13.74.143.28

Wenn jemand meinen lokalen DC per LDAP auf suspekte Weise abfragt, bekomme ich von Defender for Identity eine Mail.

Planner/Tasks

Microsoft Planner
<noreply@planner.office365.com>

dkim=fail (body hash did not verify)

OK

Internet über MX-Record

40.107.0.99

Interessant, dass Benachrichtigungen von Planner mit korrekten SPF aber defektem DKIM-Eintrag ankommen.

Yammer

Microsoft 365 Partner Community in Yammer
<noreply@yammer.com>

dkim=pass

OK

Internet über MX-Record

40.107.93.138

Bei Yammer sind keine Besonderheiten zu beachten

Microsoft 365 Subscription

Microsoft 365
<Microsoft365@email.microsoft365.com>

dkim=fail (body hash did not verify)

OK

Internet über MX-Record

68.232.192.175

Wie bei Planner waren die Mails zu meinen Rechnungen und Abonnements dank SPF in Ordnung aber DKIM war nicht korrekt.

Defender

Office365Alerts@microsoft.com

dkim=none (message not signed)

OK

Interne SMTP-Zustellung

EUR03.map.protection.outlook.com
(40.107.4.57)

Im Feb 2022 waren diese Mails interessanterweise nicht DKIM-signiert.

Voicemail

"Carius, Frank" <+49160xxxxx>

dkim=none (message not signed)

Fail

Interne SMTP-Zustellung

Sprachnachrichten werden direkt intern per SMTP zugestellt und umgehen den EXO Spamfilter. Da macht es auch nicht, wenn Sie nicht DKIM-signiert sind.

Microsoft TAP

TAP Provisioning 
<tapprovxxx@microsoft.com>

dkim=pass

OK

Internet über MX-Record

52.101.57.14

Falls sie mal einen Tenant in ein TAP-Programm bringen wollen, dann bekommen Sie auch direkt Mails von Microsoft

Partner Portal

Microsoft Partner Center 
<msftpc@microsoft.com>

dkim=pass

OK

Internet über MX-Record

52.234.172.105
Wenn Sie als Partner einem Kunden eine Einladung zur GDAP - Granular Delegated Admin Privileges senden und der Kunden zusagt, bekommen Sie als Partner eine Mail von Microsoft

Partner Portal

Microsoft 
<microsoft-noreply@microsoft.com>

dkim=pass

OK

Internet über MX-Record

waws-prod-sg1-0571f057.cloudapp.net
207.46.225.107	
Das Ende einer GDAP - Granular Delegated Admin Privileges -Konfiguration wird interessanterweise von anderen Servern und mit einer anderen Absenderadresse versendet.

Ich bin sicher, dass es noch weitere Systemnachrichten gibt. Die Liste kann daher erweitert werden:

Meistens MX-Record

Wenn Sie sich die Spalte "Transport" der Tabelle anschauen, dann habe ich alle Fälle "Grün" markiert, die vom Absender per MX-Record zugestellt werden. Es gibt aber noch weitere Fälle. Was bedeutet das für ihren Spamfilter?

  • MX-Record
    Die meisten Mails werden per MX-Record an ihren Eingangsserver zugestellt. Das kann Exchange Online sein aber auch hier hat Microsoft selbst keinen eingebauten Vertrauensvorschuss. Aber die meisten Mails sind zumindest korrekt DKIM-signiert und nutzen per SPF veröffentlichte IP-Adressen. Ein eigener Spamfilter kann daher die verwendeten Domains quasi "belohnen", damit die Mails nicht in einer Quarantäne landen oder sogar abgewiesen werden.
  • Internes SMTP
    Es gibt aber einige Mails, die sich nicht am MX-Record orientieren, sondern direkt in Exchange Online eingeliefert werden. Interessanterweise haben alle Mails auch die Header von Exchange Online Protection mit den Validierungsergebnissen. Es ist also keine "Hintertür". Allerdings müssen Sie aufpassen, dass die Dienste natürlich nur Empfänger erreichen können, die in Exchange Online bekannt sind. Mit dem Exchange Hybrid-Mode ist es natürlich dennoch möglich, auch OnPremises-Postfächer zu erreichen. Ich habe aber keine Prüfung angestellt, wie diese Dienste reagieren, wenn die Empfänger nicht bekannt sind. Ich kann nur hoffen, dass dann doch ein Fallback auf MX-Records kommt.
  • Lokale Zustellung
    Einen Ausnahmefall habe ich bei den Nachrichten von Viva festgestellt, welche gar keinen SMTP-Header haben und auch nicht im Exchange Messagetracking sichtbar sind. Hier scheint der Service direkt die Information ins Postfach des Anwenders abzulegen. Die verwendete Schnittstelle (EWS, MAPI/HTTP, GRAPH o.ä.) konnte ich noch nicht ermitteln.

Microsoft hat dazu auf der Seite zu "Tenant Attribution" etwas geschrieben:

FAQ #3 – Does mail between Office 365 tenants always use MX records?
Yes - except when we’re not expected to.
Quelle: https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143

Auf der Seite werden dann mehrere Fälle aufgeführt, bei denen Exchange Online beim Versand nicht den MX-Record nutzt. Das gilt aber nur für Exchange Online und nicht all die anderen Dienste, die ich auf dieser Seite beschrieben habe.

DKIM, SPF und eigene Spamfilter

Auch hier weise ich auf die Besonderheit von SPF, DKIM und DMARC hin. Es kann ja sein, dass die Benachrichtigungsmails über den MX-Record bei ihrem eigenen Spamfilter landen. Der kann und sollte die Prüfungen vornehmen aber dann die Mails von diesen Absendern entsprechend positiv bewerten. Auf jeden Fall sollten Sie die False-Positive-Rate für diese Absender gering halten.

Ihr eigener Spamfilter sendet diese Mails aber natürlich weiter zu Exchange Online, wenn das Postfach in der Cloud liegt. Das kann der Spamfilter direkte machen, wenn er z.B. selbst ein Service in der Cloud ist. Wenn Sie einen lokalen Exchange Hybrid Connector Server haben, dann können Sie dort diese Mails einwerfen und die Hybrid Connectoren die Zustellung übernehmen.

Sie sollten aber auf jeden Fall bei Exchange Online sicherstellen, dass diese Mails als "vertrauenswürdig" angesehen werden, denn zumindest die SPF-Prüfung wird fast fehl schlagen. Fast alle verwendeten Domains haben mittlerweile ein "-all" am Ende und ein korrekt konfigurierter Spamfilter sollte daher erst einmal keine Mails von anderen IP-Adressen annehmen. Das betrifft dann auch ihren eigenen Spamfilter, der ja mit seiner eigenen IP-Adresse bei Exchange Online ankommt.

Exchange Online Protection kann aber auch den DKIM-Eintrag prüfen, und wenn Sie die Mail nicht verändern, dann ist diese Prüfung gültig. So sieht das z.B. bei Mail von Yammer aus, die durch NoSpamProxy bei Exchange Online Protection geprüft wird:

spf=fail (sender IP is 198.32.123.5) 
   smtp.mailfrom=yammer.com; 
dkim=pass (signature was verified) 
   header.d=yammer.com;
dmarc=pass 
   action=none 
   header.from=yammer.com;
   compauth=pass reason=100

Die einliefernde IP-Adresse des eigenen Mailservers ist natürlich einer meiner Mailrelays und dementsprechend sicher nicht auf der SPF-Allow-Liste der von Microsoft genutzten Absender-Domains. Würde Exchange Online Protection hier nun die Mail abwehren, dann könnte ich nie davor einen eigenen Service schalten.

Daher müssen Sie mit einem eigenen Service dafür sorgen, dass ihr Service freigeschaltet wird, z.B. durch einen "Inbound Connector", der Exchange Online sagt, dass diese Mails von ihrem OnPremises-Server kommen.

Ansonsten finden die Anwender ihre Mails entweder im Junk-E-Mail-Ordner oder der Administrator in der Server Quarantäne.

Weitere Links