UnifiedGroups Mailrouting

In Exchange Online gibt es mit den Office 365 Groups bzw. Microsoft Teams einen neuen Empfängertyp, den Sie mit Exchange On-Premises so nicht kennen. Auf dieser Seite möchte ich die verschiedenen Szenarien und Fallstricke erläutern.

Einsatzbereich

Eine "UnifiedGroup" ist sowohl ein Mailverteiler aber auch irgendwie ein Postfach, wie folgende Abfrage ergibt:

Get-UnifiedGroup "uclabor.de" | fl PrimarySMTPAddress,EMailAddresses,Database,ismailboxconfigured,Recip*

PrimarySmtpAddress   : uclabor.de@msxfaq.de
EmailAddresses       : {SMTP:UCLabor.de@netatwork.onmicrosoft.com,
                       SPO:SPO_<guid>@SPO_<tenantguid>}
Database             : EURPR04DG050-db097
IsMailboxConfigured  : True
RecipientType        : MailUniversalDistributionGroup
RecipientTypeDetails : GroupMailbox

Für Exchange ist es erst einmal ein Mailverteiler, über den Emails an mehrere Personen, hier die Mitglieder im Team oder der Office 365 Gruppe, verteilt werden. Die Mails landen im Postfach der Gruppe und werden an die Mitglieder verteilt. Das "Gruppenpostfach" können Sie einfach in Outlook, per OWA oder in SharePoint anzeigen.

Sharepoint: https://carius.sharepoint.com/sites/EventTeam 
OWA https://outlook.office365.com/mail/group/msxfaq.net/eventteam/email 
Teams: https://teams.microsoft.com/l/team/<id>%40thread.tacv2/conversations?tenantId=<guid>

Dennoch gibt es auch zu dieser "Gruppe" ein Postfach, wie Sie per Statistikabfrage einfach sehen können:

Get-MailboxStatistics "uclabor.de" | fl displayname,itemcount,TotalItemSize

DisplayName   : UCLabor.de
ItemCount     : 51
TotalItemSize : 1.628 MB (1,707,083 bytes)

Bleiben wir aber mal beim Mailrouting.

Default Domain ".onmicrosoft.com"

Wenn Sie nichts abweichend konfigurieren, dann bekommt jede Office 365 Gruppe eine Mailadresse aus der Domäne <tenantname>.onmicrosoft.com. Sie können daher mit einem Exchange Online Postfach direkt diese Gruppe anschreiben. Auch aus dem Internet könnte die Gruppe erreicht werden, denn Microsoft pflegt sogar einen MX-Record hierfür:

C:\>nslookup -q=MX msxfaq.onmicrosoft.com

Nicht autorisierende Antwort:
msxfaq.onmicrosoft.com  MX preference = 0, mail exchanger = msxfaq.mail.protection.outlook.com

Allerdings gibt es eine hier eine Einschränkung:

Get-UnifiedGroup "uclabor.de" | fl PrimarySMTPAddress,EMailAddresses,RequireSenderAuthenticationEnabled 

PrimarySmtpAddress                 : uclabor.de@netatwork.de
EmailAddresses                     : {SMTP:uclabor.de@netatwork.de, smtp:UCLabor.de@netatwork.onmicrosoft.com, SPO:SPO_
                                     7c5d52e1-df62-4892-9011-abbb776a4ee0@SPO_de21c301-a4ae-4292-aa09-6db710a590a6}
RequireSenderAuthenticationEnabled : True

Die Standardeinstellung für "RequireSenderAuthenticationEnabled" steht hier auf "$true" und damit ist eine Zustellung von anonymen Absendern schon einmal unterbunden.

Routing-Szenarien

Je nach ihrer Umgebung gibt es verschiedene Szenarien, die hinsichtlich Mailrouting (Eingehend/Ausgehend) aber auch Spamfilter interessant sind. Denken Sie daran, dass Sie für die Domain "<tenantname>.onmicrosoft.com" weder den MX-Record noch einen SPF-Eintrag beeinflussen können.

Szenario Beschreibung

Exchange Online Only

Sie nutzen NUR Exchange Online. Ihr MX-Records verweist auf ihren Tenant und die "<tenantname>.onmicrosoft.com" verweist sowieso auf den Tenant. Auch ausgehende Mails von diesen Postfächern in der Cloud werden von Microsoft versendet.

Falls sie Exchange komplett in der Cloud betreiben aber mit ADSync arbeiten, dann haben sie immer noch einen lokalen Exchange Server für das Provisioning und ggfls. Mailrouting. Der ist aber hier nicht zu betrachten, da er keine Hybrid-Bereitstellung braucht.

Exchange Hybrid mit Split Routing und On-Prem-MX

Gruppen mit einer "<tenantname>.onmicrosoft.com"-Adresse können ganz einfach selbst Mails an andere Firmen über Exchange Online senden. Ihre On-Premises-Umgebung merkt davon nichts. auch eingehende Mails an diese Domain landen über den MX-Record direkt in der Cloud, was hinsichtlich Compliance, Archive, Spamfilter, Disclaimer natürlich zu beachten ist.

Wenn ihre Groups aber eine Adresse aus ihrer regulären Maildomain haben, dann landet diese erst "On-Premises" und sie müssen Sorge dafür tragen, dass die Mails auch weiter geleitet werden, z.B. durch Kontakte oder Groups Writeback. Standardmäßig sind diese Empfänger nur "autorisierte Absender" erreichbar.

Exchange Hybrid mit Split Routing und Cloud MX

Wer nahe am Ende der Exchange Migration in die Cloud ist oder auch die lokalen Exchange Postfächer durch Exchange Online Protection absichert, leitet seinen MX-Record der regulären Domäne die Cloud. Damit wird die Erreichbarkeit der und der Versand durch Office Groups einfacher.

Sie sollten im Hybrid-Mode aber trotzdem prüfen, ob sie im On-Premises Exchange die Cloud-Objekte ebenfalls anlegen. So können lokale Anwender diese Empfänger im Adressbuch finden.

Exchange Hybrid mit Cloud Routing

Eine Variante des vorigen Modells "Exchange Hybrid mit Split Routing und Cloud MX" nutzt die Cloud auch zum Versand der Mails ins Internet. Der lokale Exchange Server sendet einfach alle Mails an Exchange Online zur Weiterverteilung. Das vereinfacht die Zustellung, wenn Sie lokal keine Kontakte für Cloud-Only-Objekte pflegen wollen.

Exchange Hybrid mit Hybrid Centralized Mail Transport

Ein "Sonderfall" ist "Hybrid Centralized Mail Transport", bei dem alle Mails aus ihrem Tenant, also auch Absender mit einer "<tenantname>.onmicrosoft.com"-Domäne über ihren "On-Premises"-Server laufen. So können sie lokale Lösungen (Archiv, Tracking, Disclaimer etc.) weiter nutzen. Allerdings muss ihr Spamfilter dann auch damit umgehen, dass von "innen" Mails mit der Domains "<tenantname>.onmicrosoft.com" nach extern kommen können.

Viel kniffliger ist aber, dass die Empfänger im Internet für diese Domain keinen SPF-Eintrag prüfen können und mit aktiver SPF-Prüfung dieser Check sogar fehlt schlägt.

C:/>nslookup -q=TXT msxfaq.onmicrosoft.com

msxfaq.onmicrosoft.com text = v=spf1 include:spf.protection.outlook.com -all

Hier müssen Sie also drauf vertrauen, dass die Empfängerseite auch noch einen DKIM-Check macht, um die Mail nicht mit einem SPF-Fail abzulehnen. Eine andere Lösung gibt es hier nicht. Sie können das Problem "reduzieren", indem Sie auf Centralized Mail Transport verzichten und Microsoft diese Mails selbst versendet. Über Transportregeln könnten Sie dann alle anderen "nomalen Mails" wieder über "On-Premises" routen. Oder sie verpassen alle Groups eine andere Maildomain, für die sie selbst autoritativ sind.

Hybrid Routing

Wenn Sie nur Exchange Online nutzen, dann können Sie diesen Abschnitt überspringen. Wer zusätzliche aber noch Exchange On-Premises samt eingerichtetem Hybrid-Mode hat, sollte weiter lesen. Der Hybrid Configuration Wizard legt bei der Einrichtung auch eine SMTP-Route zum Tenant mit passendem Inbound-Connector auf der anderen Seite. Die Standardeinstellungen sind:

Get-SendConnector "Outbound to Office 365"

AddressSpaces                : {SMTP:msxfaq.mail.onmicrosoft.com;1}
DNSRoutingEnabled            : True
Enabled                      : True
Identity                     : Outbound to Office 365
IgnoreSTARTTLS               : False
Name                         : Outbound to Office 365
Port                         : 25
RequireTLS                   : True
SmartHostAuthMechanism       : None
SmartHosts                   : 
SmartHostsString             : 
SmtpMaxMessagesPerConnection : 20
UseExternalDNSServersEnabled : False

Damit könnten Sie glauben, dass schon alle erledigt ist. Aber das ist ein Irrtum. Es gibt zwar nun die Microsoft 365 Gruppe mit einem Exchange Online Empfänger in der Cloud aber die lokale Exchange Installation kennt davon natürlich nichts. Sie können natürlich eine Mail manuell adressieren, aber dagegen sprechen gleich mehrere Dinge:

  • Vertipper
    Das Risiko, dass ein Anwender sich bei der Adresse vertippt, ist groß. Wenn die Microsoft 365 Gruppe von Anwendern erreicht werden soll, dann ist ein sichtbarer Eintrag im Adressbuch sinnvoll.
  • Leitweg
    Beim Hybrid-Mode enthält der Send-Connector zum Tenant per Default nur die Domäne "<tenantname>.mail.onmicrosoft.com". Die Gruppe hat aber eine andere Adresse. Ihre lokale Exchange Umgebung wird daher die Mail "ins Internet" senden und über den MX-Record und Exchange Online Protection wieder annehmen.
  • Spamfilter
    Je nach Konfiguration des "Inbound Connectors" kommt die Mail an oder wird von Exchange Online als "Spoofing" angesehen. Sie könnte als in der Quarantäne hängenbleiben.
  • Anonymen Einlieferung
    Wenn Sie Mail nicht über den Hybrid Connector zum Tenant gesendet wird, dann kommt sie bei Exchange Online "aus dem Internet" und damit "anonym" an. Die Mail wird angenommen, da per Default die Gruppe ja auf RequireSenderAuthenticationEnabled:$True steht und das wollen Sie sicher nicht öffnen, nur damit ihre eigenen Benutzer diese Gruppe erreichen können

Microsoft hat selbst eine Beschreibung veröffentlicht, wie Microsoft 365 Gruppen mit Exchange Hybrid zu konfigurieren sind.

So ganz glücklich bin ich mit der Beschreibung aber nicht, denn sie löst nicht alles Probleme. (Stand Nov 2020). So beschreibt Microsoft, dass man für eine eigene Domain folgendes addieren sollte

Set-SendConnector `
   -Identity "Outbound to Office 365" `
   -AddressSpaces "contoso.mail.onmicrosoft.com","groups.contoso.com"

Das funktioniert aber nur, wenn de MX-Record für die "M365 Gruppe-Domain" auch zu Exchange Online verweist. Und es wird kein Wort zur Default Domain "<tenantname>.onmicrosoft.com" verloren. Ich würde daher besser den Connector wie folgt anpassen:

Set-SendConnector `
   -Identity "Outbound to Office 365" `
   -AddressSpaces "contoso.mail.onmicrosoft.com","contoso.onmicrosoft.com","groups.contoso.com" `
   -DNSRoutingEnabled $false `
   -SmartHosts contoso-mail-onmicrosoft-com.mail.protection.outlook.com

Allerdings muss man dann sicher sein, dass Microsoft nicht irgendwann mal etwas an dem Eintrag "<tenantname>-mail-onmicrosoft-com.mail.protection.outlook.com" ändert. So sollte es aber sichergestellt sein, dass diese Domains zwingend durch den SendConnector zum Tenant übertragen werden und damit dort auch als "authentifiziert" ankommen und zugestellt werden.

Angeblich gib es noch das ein oder andere Problem, z.B.

Delivery of external mail to a group fails if you've enabled centralized mail flow: If centralized mail flow is enabled, mail sent by an external user to a group fails to be delivered, even though the group allows email from external senders.
Quelle: Configure Microsoft 365 Groups with On-Premises Exchange hybrid https://docs.microsoft.com/en-us/exchange/hybrid-deployment/set-up-microsoft-365-groups

Ich habe das noch nicht nachgestellt, aber ich vermute, dass damit eine Mail an das durch ADSync geschriebene lokale Gruppenobjekt gemeint ist. Mit einem Kontakt habe ich die Funktion nutzen können. Beschreibung siehe weiter unten.

Eigene Domain für M365 Gruppen

Auf Dauer ist eine Domäne "<tenantname>.onmicrosoft.com" natürlich nicht schön. Da bietet es sich an, die primäre Adresse der Gruppe zu ändern. Das ist per Exchange Online PowerShell sehr einfach möglich:

set-UnifiedGroup "uclabor.de" `
   -PrimarySmtpAddress uclabor.de@msxfaq.net

Wie bei Exchange üblich wird diese Adresse dann auch bei den Emailaddresses als primäre Adresse gesetzt und bisherige Adressen werden zur sekundären Adresse:

Get-UnifiedGroup "uclabor.de" | fl PrimarySMTPAddress,EMailAddresses

PrimarySmtpAddress : uclabor.de@msxfaq.net
EmailAddresses     : {SMTP:uclabor.de@msxfaq.net,
                     smtp:UCLabor.de@msxfaq.onmicrosoft.com,
                     SPO:SPO_<guid>@SPO_<tenantguid>}

Eine weitere effektive Möglichkeit, die dann auch alle Gruppen automatisch angewendet wird, sind die Empfängerrichtlinien.

New-EmailAddressPolicy `
   -Name UnifiedGroups `
   -IncludeUnifiedGroupRecipients `
   -EnabledEmailAddressTemplates "SMTP:@teams.uclabor.de" `
   -Priority 1
Set-EmailAddressPolicy `
   -Name UNifiedGroups `
   -EnabledEmailAddressTemplates "SMTP:@teams.msxfaq.net","smtp:@msxfaq.mail.onmicrosoft.com" `
   -Priority 1

Die Richtlinien werden natürlich nur an Objekte angehängt die ein "EmailAddressPolicyEnabled:$true" haben. Sie müssen sich natürlich auch für die neue Gruppe Gedanken über das Mailrouting machen. Eine direkte Zustellung an Office 365 ist mit einer eigenen SMTP-Domain für die Microsoft 365-Gruppen natürlich einfach. Wenn sie generell aber alle Mails über eigenen Spamfilter wie z.B. NoSpamProxy laufen lassen oder für die Gruppen die gleiche Domäne wie für Anwender nutzen, dann ist der nächste Abschnitt wichtig.

Ich empfehle für Microsoft 365 Groups besser eine eigene SMTP-Domain zu nutzen anstatt ein "Sharing" mit der primären Domäne.

Achtung: Sie können natürlich der Gruppe auch eine Mailadresse aus einer anderen Domäne zugreifen. Denken Sie aber daran, dass der MX-Record vielleicht nicht direkt auf Office 365 verweist und ihr Spamfilter dann damit umgehen muss, dass Mails von Office 365 und eigenen Absendern von "draussen" kommen, obwohl sie eigentlich intern sind.
Dies betrifft Insbesondere Planner (Kommentare sind im Hintergrund Mails an die Gruppe) und Teams Voicemail.

Groups Writeback oder Kontakte

Die Exchange On-Premises-Welt kann bei passen eingerichtetem Send-Connector natürlich E-Mails an die Microsoft 365 Gruppen in der Cloud übermitteln. Aber so ganz ohne lokale AD-Objekte geht es dann doch nicht

  • Eindeutige Adressen
    Speziell wenn die Microsoft 365 Gruppen die gleiche Domain wie die sonstigen Empfänger nutzen, müssen Sie Dubletten verhindern. Die Cloud kennt per ADSync idealerweise alle Empfänger, so dass neue Gruppen keine Konflikte haben. Aber wenn Sie die Gruppen nicht dem lokalen Exchange Server bekannt machen, kann der vielleicht Empfänger mit in der Cloud bereits vergebenen Adressen anlegen.
  • Eigener Spamfilter
    Ein zweiter Aspekt ist die dringend empfohlene Empfängerprüfung. Mails an nicht existente Empfänger sollten schon beim Einliefern abgelehnt werden. Dazu muss ihr eigener Spamfilter natürlich eine vollständige Liste der Empfänger haben.

Microsoft hat hierfür die Funktion Groups Writeback mit ADSync vorgesehen, die aber aktuelle (Stand Nov 2020) nur mit AzureP1-Lizenz genutzt werden kann. Das ist für Kunden mit Microsoft 365, AzureP1 oder EMS kein Problem aber für Kunden mit Office 365-Plänen gibt es diese Option nicht.

Daher gibt es die zwei Optionen

Objekt Office 365 Group MailContact

Anlage durch

ADSync

Manuell/Skript

Targetaddress

Primäre Adresse

Skript kann Cloud Adresse nutzen

Member

werden übertragen

nicht sichtbar

ProxyAddresses

Nur die primäre Adresse wird übertragen!

Auch sekundäre Adressen sind übertragbar

Ein Kontakt können Sie ohne zusätzliche Lizenz anlegen aber Sie müssen ihn natürlich auch selbst pflegen. So ein Verzeichnisabgleich ist nicht zu unterschätzen, da es ja nicht nur um die einmalige Anlage des Objekts geht sondern auch Umbenennungen und Löschungen nachzuführen sind.

Beachten Sie den Sonderfall "Targetaddress" bei einer Gruppe, welche Exchange anweist, diese Mail nicht als Loop zu senden sondern über SendConnectoren nach extern zuzustellen. Ein passende SendConnector ist erforderlich. Wenn On-Prem Objekte und M365-Gruppen die gleiche Domain nutzen, darf die Domain nicht autoritativ sein.

Groups Writeback schreibt nur die primären Adressen in das Feld "ProxyAddresses", obwohl ADSync auch mehr könnte. Der Grund hat sich mir noch nicht erschlossen.

Generell sind bei solchen Aktionen umfangreiche Tests ratsam, um alle möglichen Sonderfälle zu verifizieren.

Mit einem Kontakt können Sie aber auch das Thema "Routing" sehr elegant lösen:

  • Die M365-Gruppen bekommt eine "<tenantname>.mail.onmicrosoft.com" Adresse
    Das ist sehr einfach per Empfängerrichtlinie zusätzlich möglich
  • Hybrid Connector
    Hier ist dann nichts mehr erforderlich, da die Domain "<tenantname>.mail.onmicrosoft.com" eh schon durch den HCW konfiguriert wurde
  • TargetAddress
    Aus der Microsoft 365 Gruppe werden dann einfach die "Emailaddresses" 1:1 zum kontakt übertragen und die "<tenantname>.mail.onmicrosoft.com"-Adresse wird zur TargetAddress
  • Weitere Felder
    Vergessen sie nicht auch Displayname etc. und vor allem die Einstellung "RequireSenderAuthenticationEnabled" zu übernehmen.

Damit kann auch der On-Premises Exchange Server den Empfänger Verarbeiten und ihre Spamfilter kennt auch die Adressen der Objekte in der Cloud. Allerdings beschreibt Microsoft auf seiner Seite noch den ein oder anderen Sonderfall. Einer ist:

Mail sent to a group's secondary SMTP address fails to be delivered: When multiple email addresses are added to a group, only the primary SMTP address is written back to your On-Premises Active Directory. If an On-Premises user tries to send a message to the secondary SMTP address of a group, the message will fail to be delivered. To prevent this issue, configure only one SMTP address on each group.
Quelle: Configure Microsoft 365 Groups with On-Premises Exchange hybrid https://docs.microsoft.com/en-us/exchange/hybrid-deployment/set-up-microsoft-365-groups

Bei der Verwendung eines Kontakts konnte ich dieses Problem aber nicht nachstellen.

Externe Erreichbarkeit

Standardmäßig kann ein Team immer nur von authentifizierten Absendern erreicht werden. Dafür sorgt schon die Standardeinstellung von RequireSenderAuthenticationEnabled.

Get-UnifiedGroup "uclabor.de" | fl PrimarySMTPAddress,RequireSenderAuthenticationEnabled 

PrimarySmtpAddress                 : uclabor.de@netatwork.de
RequireSenderAuthenticationEnabled : True

Aber was $true ist, kann natürlich auch auf "$false" gesetzt werden.

Set-UnifiedGroup `
   -identitiy "uclabor.de" `
   -RequireSenderAuthenticationEnabled:$false

In Verbindung mit Groups Writeback ist natürlich interessant, ob die Änderung auch das On-Premises-Objekt betrifft. Überraschenderweise scheint das nicht der Fall zu sein.

Eine Änderung der Einstellung in der Cloud hat bei ADSync keine Änderungen übertragen.

Auf dem lokalen Objekt ist der Wert "msExchRequireAuthToSendTo" weiterhin auf $true.

Die Herausforderung bei den durch ADSync angelegten lokalen Objekten ist, dass es zwar "Gruppen" sind aber Get-Recipient und andere Commandlets diese nicht finden und damit auch nicht bearbeiten können. Das macht es natürlich aufwändig, denn diesen Wert können Sie dann nur an Exchange vorbei per LDAP/ADSI ändern.

Aus meiner Sicht ist das ein ein Fehler, der aber nur auffällt, wenn sie Office 365 Groups über "On-Premises" routen. Er könnte also immer weniger wichtig sein, wenn mehr und mehr Firmen kein Exchange On-Premises und Hybrid mehr nutzen.

Anders sieht es natürlich aus, wenn Sie die Funktion "Groups Writeback" gar nicht nutzen und stattdessen einfach selbst ihre Kontakte manuell oder per Skript pflegen. Das On-Premises-Objekt ist dann natürlich keine "Gruppe" sondern nur ein Kontakt und Sie können auch nicht per LDAP ermitteln, wer hier "Member" ist. Aber alle anderen Funktionen sind dafür vorhanden.

Eine Liste der Office 365 Gruppen samt Mailadressen können Sie problemlos per Exchange Online PowerShell und "Get-UnifiedGroup" in eine CSV-Datei exportieren und dann mein vereinfachtes Import-Skript CSV2Mailcontact verwenden

Versand als Gruppe

Die Änderung der primären Adresse einer Microsoft 365-Gruppe verändert auch das Verhalten beim Versand einer Mail als diese Gruppe. Das passiert z.B. bei einer Termineinladung mit dem Kanal, dass die Einladung "von der Gruppe im Auftrag des Organisators" versendet wird.

Dies gilt nur für Benutzer in Exchange Online, die das "Send-As"-Recht auf die Office 365 Gruppen bekommen haben oder einen Termin als Gruppe versenden. Für den Versand als "On-Premises" Benutzer müssen Sie die Rechte am On-Premises-Platzhalterobjekt setzen.

Ich habe zum Test einen Termin in einem Kanal des Teams "Event Team" mit Microsoft Teams geplant.

Teams und nicht ein eventuell lokales Outlook muss dann die Einladung an alle Mitglieder des Teams und auch den einen extern eingeladenen Anwender senden:

Sie sehen dass der Absender auf "Frank Carius im Auftrag von Event Team" lautet. Entsprechend sehen auch die Felder im Header aus. Interessant sind hier die markierten Felder, die durch "From" und "Sender" das "Im Auftrag von" erreichen.

Auch finde ich interessant, dass die Einlieferung per "mapi" erfolgt. Sie sehen aber auch, dass das Team selbst auch noch mal in den Empfängern enthalten ist und damit alle Team-Mitglieder ebenfalls die Einladung bekommen.

Es gibt hier keine Unterscheidung nach Kanälen und wen letztlich der Termin in dem Kanal interessiert. Selbst wenn sie niemand "einladen" wird der Termin an alle Team-Mitglieder verteilt. Beachten sie das, wenn sie einen Termin in "Teams" statt in Outlook planen, weil Sie ihn an den Kanal "kleben" wollen.

Versand und SPF

Bei dem obigen Beispiel sehen Sie aber auch, dass ich externe Personen einladen kann aber auch alle Gäste in meine Team die Einladung bekommen. Die Gäste können also auch "extern" sein. Und da gibt es einen Fall, der von Teams und Microsoft nicht berücksichtigt wurde und mit SPF zu tun hat.

Wer mag, kann jetzt mal innehalten und überlegen, in welchem Fall der Versand einer Einladung hier fehlt schlägt.

Wenn Sie keine eigene Domains für die Office 365 Groups vorsehen, dann sendet die Gruppe als "<gruppenname>@<tenantname>.onmicrosoft.com". Microsoft hat für diese Domain nur nicht nur einen MX-Record sondern auch einen SPF-Eintrag veröffentlicht:

PS C:\> Resolve-DnsName -Type TXT -Name carius.onmicrosoft.com | fl

Name    : carius.onmicrosoft.com
Type    : TXT
TTL     : 86390
Strings : {v=spf1 include:spf.protection.outlook.com -all}

Aus dem Message Tracking von Exchange und dem Header der Mail ist sehr wohl ersichtlich, dass auch die Mails des Teams Backend sehr wohl über den Exchange Online Tenant geroutet und damit auch den Connectoren unterworfen werden. Solange Exchange Online die Mails direkt nach extern, d.h. Richtung Internet sendet, funktioniert alles.

Probleme gibt es aber aber immer dann, wenn sie als Kunde ihre ausgehenden Mails von Exchange Online nicht direkt routen. Da gibt es mindestens zwei Fälle:

  • Hybrid Centralized Mail Transport
    Es gibt durchaus Firmen, die alle Mails immer erst über die die On-Premises Umgebung routen. Das kann erforderlich sein, um z.B.: Zusatzfunktionen wie Disclaimer, Archivierung etc. umzusetzen. Oder sie sind gerade am Anfang einer Migration zu Exchange Online und haben einfach noch nicht die Zeit gehabt, das ausgehende Mailrouting hinsichtlich DKIM, SPF etc. umzustellen. Dazu gehören ja auch "Partner Connectoren", bei denen Sie zu anderen Firmen besonders konfigurierte Verbindungen geschaltet haben.
  • Cloud Spamservice
    Der zweite Fall sind externe Dienstleister, die für sie das Filtern von Spam übernehmen und dazu auch ausgehende Mails verarbeiten um interne Fehlkonfigurationen und Angriff nach extern zu unterbinden. Natürlich liefert Exchange Online Protection als Bestandteil von Exchange Online eine ähnliche Funktion aber 3rd-Party-Lösungen wie z.B.: NoSpamProxy können z.B. auch SMIME/PGP auf dem Transport umsetzen.

Wenn Sie hier die Gruppen nicht mit eigenen Domänen versehen, über die Sie auch die SPF-Records setzen können, dann müssen Sie ihre Routing so anpassen, das Exchange Online diese ausgehenden Mails selbst versendet. Das ist gar nicht so einfach möglich, denn einen Connector "Von Office 365 zu Internet", den Sie dann über eine Transportregel anhand der Quelldomäne ansprechen, können Sie aktuell (Stand Nov 2020) nicht einrichten. Sie müssten also invers arbeiten, d.h. per Default gehen alle Mails direkt raus, außer es sind Exchange Online Absender, die dann über den Hybrid Connector zu Exchange On-Premises oder einem vorgelagerten Service laufen.

Versand und DKIM

Um es Mailsammlern nicht so einfach zu machen, habe ich die Domains leicht erkennbar verändert.

In meinem Beispiel waren die Voraussetzungen natürlich deutlich erschwert, denn ich habe als "frank@carius2.de" eine Einladung über das Team als "Event Teams@msxfaq2.net" an ein Firmenkonto gesendet, welches per NoSpamProxy auch schon etwas genauer hinschaut. Im Exchange Online Messagetracing habe ich dann gesehen, dass die Mail von meinem Benutzer an die verschiedenen Empfänger verteilt wird aber die Zustellung an den Gastbenutzer nicht möglich war.

Ein Blick auf die Details zeigt sofort, dass die andere Seite, hier also NoSpamProxy, die Mail abgelehnt ,hat:

Die Fehlermeldung deutet darauf hin, dass hier SPF/DKIM irgendwie nicht gepasst hat:

DMARC validation failed: 
   Rfc5322FromDomain: msxfaq.net, 
   ValidationResult: DkimAndSpfAlignmentFailed, 
   OrganizationalDomain: msxfaq.net, 
  DkimAlignment: False, 
   SpfAlignment: False, 
   ApplicablePolicy: Reject, 
   EffectivePolicy: Reject

Auch bei der grafischen Anzeige in der NoSpamProxy GUI konnte ich zwar sehen, dass die SPF-Prüfung als auch eine DKIM-Prüfung noch korrekt war.

Hier noch mal die SPF-Einträge der beiden Domains

carius.de   "v=spf1 include:_spf.perfora.net include:_spf.kundenserver.de include:spf.protection.outlook.com -all"
msxfaq.net  "v=spf1 a mx include:spf.protection.outlook.com include:spf.server-he.de -all"

Beide Einträge erlauben zwar auch Office 365 als Absender aber ansonsten wird mit einem "-all" abgewiesen. Aber das wäre noch kein Grund die Mail abzulehnen. Daher müssen wird uns auch noch die DMARC-Einträge dazu anschauen.

_dmarc.carius.de  text = "v=DMARC1; p=reject; rua=mailto:xxx; ruf=mailto:xxx"
_dmarc.msxfaq.net text = "v=DMARC1; p=reject; rua=mailto:xxx; ruf=mailto:xxx"

Allein die Existenz der DMARC-Einträge sorgt dafür, dass kompatible MTAs den "Header-From" auswerten. Der Header-From der Mail war dabei "msxfaq2.net"

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=carius.onmicrosoft.com; s=selector2-carius-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=SyQHx/Xh6Va4uV1WhjBU7oPvy8Kn/zGGmgpM4HQeB9I=;
 b=xxxxxxxxxxxxxxx=
X-NetatworkMailGateway-Sender: frank@carius2.de
From: Event Team <EventTeam2@msxfaq2.net>
To: "Carius, Frank (O365 Carius)" <frank@carius2.de>, "Carius, Frank (NAW)"
	<frank.carius@netatwork2.de>, Event Team <EventTeam@msxfaq2.net>
Subject: Test-Meeting aus Kanal 3
Thread-Topic: Test-Meeting aus Kanal 3
Thread-Index: Ada5HCAK/x3BKCnbxku+hRSZnzTROg==
Sender: "Carius, Frank (O365 Carius)" <frank@carius2.de>

Sie sehen aber auch dass der Envelope-From, den NoSpamProxy dankenswerterweise als "X-NetatworkMailGateway-Sender: frank@carius2.de" addiert, und der "From:" sich unterscheiden. Mit DMARC wird der "From" des Header herangezogen und mit DKIM verifiziert. Das funktioniert aber nicht, das die einzige DKIM-Signatur die für meinen Tenant war. Ich hatte einfach "vergessen", die Domain "msxfaq.net" mit DKIM zu kennzeichnen. Als dann auch noch Header und Eventlope unterschiedlich waren, wurde die Mail abgelehnt.

Wenn Sie DMARC nutzen, dann sollte die Absender-Domain auch mit DKIM gesichert sein.

Nachdem ich dann msxfaq.net auch noch für DKIM aktiviert habe, konnte NoSpamProxy as Empfänger auch die Signatur für diese Domain prüfen und die Mail durchleiten. Hier der Header nach Aktivierung von DKIM:

X-NetatworkMailGateway-Sender: frank@carius2.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=msxfaq2.net;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=xxxxxxxxk=;
 b=xxxxxxxx=
From: Event Team <EventTeam@msxfaq2.net>
To: "Carius, Frank (O365 Carius)" <frank@carius2.de>, "Carius, Frank (NAW)"
	<frank.carius@netatwork2.de>, Event Team <EventTeam@msxfaq2.net>
Subject: Test-Meeting aus Kanal 4
Sender: "Carius, Frank (O365 Carius)" <frank@carius2.de>

Office 365 hat die "HeaderFrom"-Adresse genutzt, um eine passende DKIM-Signatur anzufügen.

Externe Mails und Gäste im Team SRS/SPF

Sie könnten nun annehmen, dass wir alle Fälle verarbeitet haben. Dem ist aber leider noch nicht so. Die Thematik lässt sich noch steigern, wenn Sie eine Gruppe oder ein Team von extern erreichbar machen und eine externe Person dieses Teams enthalten ist. In dem Fall wird die Mail von dem externen Absender über die Gruppe oder das Team wieder an die Gäste verteilt. Exchange muss in dem Fall wie bei einem List-Server die Absenderadresse umschreiben, damit die Mail auch wieder ankommt. Das folgende Bild soll das etwas genauer beschreiben

Ich sende nun von einem ganz anderen Absender eine Mail an die Office 365 Group, welche wieder Gäste als Mitglied hat.

Ohne eine entsprechende Freischaltung wird die Mail natürlich schon vom Tenant abgelehnt:


Aber ich kann die Unified Group ja auch anonym erreichbar machen.

set-UnifiedGroup `
   -identity"Event team" `
   -RequireSenderAuthenticationEnabled $false

Danach wurde die Mail auch angenommen und an die Mitglieder verteilt.

Allerdings landet die Mail nicht im Ziel, sondern wird wieder von NoSpamProxy abgewiesen. Beim Absender kommt folgendes an:

Die Details dazu helfen weiter:

NoSpamProxy mag diese Mail nicht und Microsoft liefert hier schon die "SenderAddress" mit und weiter unten dann den kompletten Header.

Sender Address: EventTeam+SRS=1K0sh=EW=msxfaq.com=admin@msxfaq.net
Recipient Address: frank.carius@netatwork.de

Hier sehen wir sehr gut, dass der "Mail FROM" im Envelope umgeschrieben wurde. Das ist schon mal sehr lobenswert, denn der Tenant ist ja nicht für "msxfaq.com" autoritativ. Aber dann müssen wir uns noch den Envelope anschauen.

From: Admin <admin@msxfaq.com>
To: "EventTeam@msxfaq.net" <EventTeam@msxfaq.net>

Hier erscheint der "reale Absender" und die Zieladresse der ersten Mail. Auch das ist sinnvoll, damit das Gast im Team sowohl den echten Absender als auch den Empfänger sehen kann. Damit aber so eine Mail nicht von einem Spamfilter abgelehnt wird, muss der Versender natürlich mithelfen. Einen SPF-Eintrag für "msxfaq.com" wird der Tenant nicht haben. Daher muss DKIM herhalten. In der Mail finde ich nun zwei Signaturen:

Die erste Signatur wird für die Domain "carius-onmicrosoft.com" generiert. Das kann Exchange Online gerne machen aber ist ohne belang, da die als "d=carius.onmicrosoft.com" angegebene Domain eh nicht verwendet wird.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=carius.onmicrosoft.com; s=selector2-carius-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=xxxxxxxx=;
 b=xxxxxxxxx=

Die zweite Signatur hingegen ist die originale Signatur des ersten Absenders, der die Mail zur Gruppe gesendet hat. Diese Signatur würde der Mail helfen, die Spamfilter zu überstehen, da Sie zu "Header From" passt.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=msxfaq.com;
 s=selector2;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=4mbYTVZ5GdynSBjkwDiL07yG9BWrTKv5YpAcJ5rWvaQ=;
 b=dYGDoBgerf9CvaufK6HMpImVKAzAsOk5TNxicvM+sygQ5N4pc1SHqBsU98IPsGXdh+xxxxxxxx=

Leider ist aber genau diese Signatur nicht mehr gültig, da Microsoft das Feld "X-MS-Exchange-SenderADCheck" mit einbezieht und dieses auf dem Weg durch den Tenant der Gruppe von "1" auf "0" gesetzt wird.

X-MS-Exchange-SenderADCheck: 0

Damit ist auch diese Signatur keine Hilfe.

Die "Envelope-From"-Adresse ist natürlich eine "Sender Rewriting Scheme"-Adresse und würde sogar den SPF-Test bestehen. Das reicht aber auch nicht, da ich einen DMARC-Eintrag habe und damit SPF alleine nicht reicht.

Ich werde nun aber sicher nicht meine DMARC-Richtlinie absichtlich abschalten.

Sonderfall: Mail an einen Kanal

Einen letzten Sonderfall möchte ich noch der Vollständigkeitshalber erwähnen. Auch ein Kanal in einem Team kann eine Maildresse bekommen. Jeder Teams-Nutzer kann diese Adresse "abfragen".

Die Adresse liegt dann aber in einer eigenen SMTP-Domain, die von Microsoft vorgegeben wird:

Diese Adresse eines Kanals hat die Form:

<%Kanalname%> - <%teamname%> <%id%.miele365.onmicrosoft.com@emea.teams.ms>

Sie können leider keinen eigenen eingehenden Spamfilter vor diese Adresse setzen und auch keine Mails mit dieser Adresse versenden.

Auch für diese Empfänger kann natürlich ein Kontakt und ein Routing über Hybrid angelegt werden. Ein eventuell mit einem Partner-Connector gehärteter Tenant ist aber nicht betroffen, da diese Mails „emea.teams.ms“ gehen und das Exchange Online Routing des eigenen Tenant umgehen.

Weitere Links