MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

B2B Mail und Default Domain

Auf der Seite Cloud Notification Mails habe ich beschrieben, wie die verschiedenen Microsoft Dienste ihre Benachrichtigungsmails an interne und externe Empfänger versenden. Im Januar hat sich Verhalten geändert, ohne dass ich eine Meldung im Message Center gefunden habe. Eine Mails gehen nun über ihren EXO Tenant und das hat Auswirkungen.

Fehlerbild

Auslöser was, wie so oft, die Meldung eines Kunden, dass er keine Gäste mehr einladen konnte, Die Einladungen, die bislang als "invite@microsoft.com" direkt von Microsoft versendet wurden, erscheinen mittlerweile im Exchange Online Messagetracking mit einem Fehler:


Messagetracking Exchange Online

Auch beim ausgehenden Spamfilter (NoSpamProxy) haben wir gesehen, dass die Mail von Exchange Online ausgehend direkt abgewiesen wurden.


Messagetracking NoSpamProx

Das war auch so erwartet, wenn eine Mail mit dem Absender *@<tenantname>.onmicrosoft.com versendet werden sollte. Diese MOERA - Microsoft Online Email Routing Address sollten sie nie zum Versand nutzen und Microsoft erzwingt dies indirekt, indem es die Anzahl der ausgehenden Mails mit dieser Domain limitiert. Aber selbst wenn der Versand versucht worden wäre, hätten die meisten Gegenstellen beim SPF-Check schon die Mail abgewiesen.

Analyse

Am Anfang war noch nicht klar, war hier genau passiert, denn wenn Microsoft Mails nun über den Tenant des Kunden mit einer Absenderadresse des Kunden versendet, dann funktioniert dies bei den meisten Kunden eigentlich problemlos. Probleme gibt es nur, wenn die Exchange Hybrid Konfiguration z.B. "Centralized Mail Transport" nutzt oder der Versand von Exchange Online ins Internet über ein 3rd Party-Relay erfolgt. Das mag nicht die Mehrzahl der Tenants betreffen aber gerade Firmen in der Migration oder mit lokalen Relays und natürlich all die Firmen, die nicht auf Exchange Online Protection und Defender for Office 365 setzen, sondern 3rd Party Gateways für Disclaimer, SMIME oder einfach besseren Spamschutz davorstellen, sind dadurch betroffen.

Durch die Analyse des Message Trackings und insbesondere der SMTP-Header der nun anders gerouteten Mails war schnell klar, dass Microsoft eine globale Konfiguration geändert hat. Ich habe dazu in meinem MSXFAQDEV-Tenant einige Tests gemacht und einen externen Benutzer erst als Gast eingeladen und dann in Teams addiert. Im Postfach des Empfängers kamen drei Mails an

Im Exchange Online Messagetracking habe ich die gleichen Mails gesehen:

Zuerst habe ich aus meinen MSXFAQDEV-Tenant einen externen Benutzer als Gast eingeladen. Hier sehe ich schon mal die neue Absenderadresse "invites@msxfaq.net".

Wenn ich mir dann den Header der Mail anschaue, dann sehe ich nur zwei "Received"-Zeilen. Dieser Tenant hat keinen Connector zu einem vorgelagerten Spamfilter und auch kein Centralized Mail Transport zu einer OnPremises Umgebung.

Der Absender im Header ist "invites@msxfaq.net". Interessanter finde ich die grün markierten Bereiche. Die Mail wurde per HTTP "eingeliefert" und "X-MS-Exchange-CrossTenant.AuthAs: Internet" als auch "X-MS-Exchange-ServerADCheck: 1" zeigt an, dass diese Mail irgendwie als authentifiziert bzw. verifiziert klassifiziert und dem Tenant "X-OriginatorOrg: msxfaq.net" bzw. X-MS-Exchange-CrossTenant-Id zugerechnet wird.

Die Mail wurde dann von Exchange Online direkt per MX-Record an "kundenserver.de" gesendet.

Ich habe den Test auch mit einem Tenant gemacht, in dem keine Exchange Online Lizenz mehr vorhanden ist und daher z.B. kein Hybrid Mode eingerichtet werden kann. Aber auch hier wurden die Mails durch den Tenant geroutet.

Die nachfolgenden Einladungen ins Teams durch den Benutzer werden mit der Absenderadresse des Einladenden versendet. Hier macht Teams/Exchange schon immer ein Impersonate".

Bestätigung durch Microsoft

Problem ist wirklich die "Gast-Einladung", welche früher mit der Adresse "invites@microsoft.com" gesendet wurde und seit einem nicht bezeichneten Zeitpunkt durch den Tenant mit "invites@<primarydomain>" versendet werden. Ein Ticket im Kundentenant liefert nach sehr kurzer Zeit folgende Antwort:

Vielleicht war die Mail eine Antwort einer KI aber bestätigt, dass Microsoft irgendwann in Januar 2026 einen Change gestartet hat, der hier am 2. Februar im Kundentenant angekommen ist und die "B2B"-Mail zur Einladung eines Gasts mit "invites@<primaryDomain" kommen.

Heilung

Da wir nun wissen, was passiert ist und wie sich Microsoft 365 beim Versand von B2B-Mails verhält, können wir nun die Konfiguration anpassen. Hier gibt es sogar mehrere Optionen:

  • Primary Domain anpassen
    Aus meiner Sicht ist das die beste Option. Sie ändern im Entra ID-Portal unter Domains einfach in eine SMTP-Domain, die sie auch aktiv nutzen. Sie können dies im Entra ID-Portal ändern

    Alternativ ist dies auch im Microsoft Admin Center unter Domains möglich.
    Es kann nur eine "Primary Domain" geben und die Änderung hat auch Einfluss auf die weitere Erstellung neuer Objekte, z..b Office 365 Groups, User etc., wenn Sie nicht explizit einen UPN oder Mailadresse etc. angeben.

    Quelle: Domains FAQ https://learn.microsoft.com/en-us/microsoft-365/admin/setup/domains-faq?view=o365-worldwide#how-do-i-set-or-change-the-default-domain-in-microsoft-365
  • Rückbau Centralized Mail Transport
    Wenn Centralized Mail Transport ihr Problem ist, dann sollten sie sowieso überlegen, ob diese eine dauerhafte Konfiguration bleiben soll. Es gibt nur ganz wenige Gründe, Mails aus einem Exchange Online Tenant nach Extern immer über eine lokale Umgebung zu senden, z.B. Disclaimer oder Archiv-Lösungen, die nicht direkt an Exchange Online angebunden werden können. Dann könnte Exchange Online die Mails direkt versenden und damit weiter die invites@<tenantname>.onmicrosoft.com-Adresse nutzen. Ratsam ist das aber nicht, da der Versand mit dieser Domain weiteren Einschränkungen unterliegt.
    Limiting Onmicrosoft Domain Usage for Sending Emails
    https://techcommunity.microsoft.com/blog/exchange/limiting-onmicrosoft-domain-usage-for-sending-emails/4446167
  • Transportregel und Outbound Connector für Direktversand
    Wenn Sie heute Mails aus ihrem Tenant per Send-Connector über eine 3rd Party Lösung oder per Centralized Mail Transport über Exchange OnPremises versenden, dann könnten sie in Exchange Online einen "Outbound Connector" ins Internet anlegen, der per Transportregel auf die Absenderadresse invites@<tenantname>.onmicrosoft.com triggert. Die Einschränkungen der onmicrosoft.com-Domain bleiben aber auch hier bestehen

SPF-Fail

Es ist übrigens keine Lösung, die Mails mit der onmicrosoft.com-Domain über ihren eigenen OnPremises Server oder ein 3rd Party Gateway zu routen, da Sie den SPF-Eintrag dieser Domain nicht ändern können.


Quelle: https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure

Der Wert ist wie folgt eingestellt:

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

msxfaqdev.onmicrosoft.com       text = "mscid=VLbfhK/B8.....=="
msxfaqdev.onmicrosoft.com       text = "v=spf1 include:spf.protection.outlook.com -all"

Die Hoheit über die "<tenantname>.onmicrosoft.com"-Domain hat Microsoft aber sie können im Microsoft 365 Admin Center durchaus einige Einträge selbst addieren. Von Microsoft verwaltete Einträge, z.B. TXT-Einträge für DKIM sind nicht änderbar. Der bereits vorhandene SPF-Eintrag wird, Stand Feb 2026, gar nicht erst angezeigt und ich kann ich ändern oder überschreiben:


Quelle: https://admin.cloud.microsoft/#/Domains/Details/msxfaqdev.onmicrosoft.com

Nehmen Sie mit, dass ein Versand mit einer Adresse der Domain "*@<tenantname>.onmicrosoft.com" nur direkt von Exchange Online ins Internet möglich ist.

NoReply-Mails

Wenn wir schon beim Wechseln der Default Domain sind, dann sollten sie auch gleich die "Noreply"-Adresse anpassen. Auch hier sendet Microsoft in der Standardeinstellung verschiedene Mails als "noreply@<tenantname>.onmicrosoft.com". Das funktioniert natürlich auch nicht, wenn sie ausgehende Mails nicht direkt per SMTP von Exchange Online ins Internet routen, sondern über 3rd-Party-Relay-Systeme gehen oder Centralized Mail Transport nutzen.

  • NoReply-Adresse - Warum sie keine Mails mit "noreply@<firmendomain" senden und im Microsoft 365 Tenant eine eigene Serviceadresse konfigurieren sollten

MC1234575 - Teams Event Mails

Am 18. Feb 2026 ist noch eine weitere Meldung im MessageCenter meines Tenants erschienen, die noch eine weitere Nutzung der <tenantname>.onmicrosoft.com-Domain aufführt und eine Änderung erfordert.

Interessant ist hier, dass laut Text das "Enforcement" am 31. Jan 2026 ausgerollt wurde und die Meldung am 18. Feb wohl etwas spät kommt. Allerdings gab es schon im Okt 2025 eine "Vorwarnung" als MC1176301 gab. Als Administrator sollte n Sie wirklich regelmäßig das Microsoft 365 Message Center kontrollieren. Sie können sich diese Meldungen problemlos per Mail senden, in einen Planner schreiben oder per Graph automatisiert abrufen lassen.

Aktionen

Kontrollieren Sie ihre Default Domain. Wenn dies noch die "<tenantname>.onmicrosoft.com"-Domain ist, dann überlegen, Sie, ob diese Einstellung für ihr Unternehmen passt. Selbst wenn Sie direkt ins Internet senden und die Funktion im Grunde gegeben ist, sollten Sie die Beschränkungen beim Versand kennen.

We will be introducing throttling to limit messages sent from your organization’s onmicrosoft.com domains to 100 external recipients per 24 hour rolling window
Quelle: https://techcommunity.microsoft.com/blog/exchange/limiting-onmicrosoft-domain-usage-for-sending-emails/4446167

Ganz losgelöst ist es eine wenig professionelle Außenwirkung und auf dem Niveau von Handwerken, die zwar eine eigene Webseite unter ihrem Namen haben aber immer noch die gute alte T-Online.de-Mailadresse darunter schreiben.

Es ist an der Zeit, dass Sie jeglichen Versand über ihre von Microsoft gestellte Domain "*@<tenantname>.onmicrosoft.com" unterbinden. Mit der Änderung im Jan 2026 sehen Sie diese Mails nun im Exchange Message Tracking.

Tipp: Sie können auch einen DMARC-Eintrag für ihre "<tenantname>.onmicrosoft.com"-Domain addieren, um Aussendungen zu erkennen.

Allerdings sollten Sie vorab prüfen, ob ihre bestehenden Prozesse auf eine neue "Default-Domain" ausgerichtet ist. Bestehende Objekte betrifft es nicht aber so bekommen z.B. neue Teams  oder Shared Mailboxen in der Cloud dann die neue Default Domain als UPN/Mail-Adresse.

Weitere Links