Microsoft 365 und gefälschte Absender: was der Tenant für die eigene Domain nicht erledigt

Eine Umstellung auf Microsoft 365 gilt meist an dem Tag als abgeschlossen, an dem die Postfächer umgezogen sind. Der MX-Eintrag zeigt auf Microsoft, der Autodiscover-Eintrag sitzt, der SPF-Eintrag trägt das neue include, Outlook verbindet sich. Genau diese Einträge fragt der Einrichtungsassistent im Admin Center ab. DKIM steht dort unter „Erweiterte Optionen“ und ist als optional markiert, DMARC kommt in der Liste gar nicht vor.

Der Mailverkehr läuft damit vom ersten Tag an, die Absenderdomain lässt sich aber weiterhin von jedem Server aus fälschen. Das ist kein Versäumnis der Plattform, sondern eine Zuständigkeitsgrenze: Die Einträge, die eine Domain gegen gefälschte Absender schützen, stehen in ihrer DNS-Zone, und die verwaltet in der Regel der Registrar oder Webhoster, nicht Microsoft.

Was der Tenant von sich aus erledigt

Für die Startdomain, die jeder Tenant bei der Registrierung erhält, nimmt Microsoft dem Betreiber fast alles ab. Nachrichten aus einer Domain wie contoso.onmicrosoft.com werden laut Microsoft Learn automatisch mit DKIM signiert, SPF ist vorkonfiguriert. Nur der DMARC-Eintrag fehlt auch dort, lässt sich aber im Admin Center anlegen, weil Microsoft diese Zone selbst verwaltet.

Auf der Empfangsseite ist die Plattform ebenfalls gut aufgestellt. Ist in der Antiphishing-Richtlinie „DMARC-Eintragsrichtlinie berücksichtigen“ eingeschaltet, was Microsoft empfiehlt, landen eingehende Nachrichten, die an der DMARC-Prüfung einer fremden Domain mit p=quarantine scheitern, im Junk-Ordner. Bei p=reject werden sie schon während der SMTP-Übertragung mit 550 5.7.1 abgelehnt. Microsoft 365 setzt also die Regeln anderer Domains durch. Die eigene Domain profitiert davon nur, wenn sie selbst eine Regel veröffentlicht, die fremde Empfänger durchsetzen können, und genau diese Regel kann der Tenant nicht schreiben.

Die Grenze verläuft an der DNS-Zone

In der DMARC-Anleitung formuliert Microsoft diese Grenze ausdrücklich, fast gleichlautend steht sie in der SPF-Anleitung:

Bei DKIM ist die Lage gemischt. Microsoft erzeugt und verwahrt die Schlüssel, die privaten Schlüssel sind für den Kunden nicht zugänglich. Damit Empfänger die Signatur prüfen können, müssen aber zwei CNAME-Einträge in der eigenen Zone auf Microsofts öffentliche Schlüssel verweisen. Die Dokumentation nennt das „eine Mischung aus Prozeduren in Microsoft 365 und Prozeduren bei der Domänenregistrierungsstelle der benutzerdefinierten Domäne“.

Unterstützt der Registrar das Verfahren Domain Connect, schreibt Microsoft 365 die für seine Dienste erforderlichen Einträge zwar selbst in die Zone. Auch dort bleibt DKIM aber eine Zusatzoption, und einen DMARC-Eintrag sieht der Ablauf nicht vor. Liegt die Zone beim Webhoster der Website, braucht das Projektteam dort einen eigenen Zugang. Ohne ihn bleibt jede der drei Aufgaben liegen, gleich wie sorgfältig der Tenant konfiguriert ist.

Was die Messung bei Microsoft-365-Domains zeigt

Wie oft diese Aufgabe tatsächlich liegen bleibt, lässt sich von außen messen, denn SPF, DKIM und DMARC stehen öffentlich im DNS. Eine Auswertung der DMARC- und SPF-Einträge deutscher Unternehmen hat das für 9.935 Unternehmensdomains mit Sitz in Deutschland am 8. Oktober 2026 getan. Microsoft 365 ist dort auf 56,3 % der Domains erkennbar, bei 37,5 % nimmt Microsoft die Mails direkt an. Von diesen Microsoft-365-Domains sind nur 42,8 % wirksam gegen Absenderfälschung geschützt, also mit durchgesetzter DMARC-Richtlinie und gültigem SPF. Bei weniger als der Hälfte der Domains, die ihre Mail über Microsoft 365 empfangen, ist DMARC demnach so eingerichtet, dass es schützt.

Beim Signieren zeigt sich dieselbe Lücke: Bei 33,1 % dieser Domains ist für die eigene Domain kein DKIM-Schlüssel nachweisbar. Geprüft wurde nur der bei Microsoft übliche Selektor selector1, der DKIM-Nachweis ist also eine Untergrenze. Auch sonst hat die Messung Grenzen: Die Stichprobe stammt aus Wikidata und enthält vor allem bekanntere Firmen, die Werte gelten eher als Obergrenze, und erfasst ist nur, was im DNS steht.

DKIM aktivieren: Portal, zwei CNAME-Einträge, ein Schalter

Der Ablauf beginnt im Microsoft Defender-Portal unter E-Mail & Zusammenarbeit › Richtlinien & Regeln › Bedrohungsrichtlinien › E-Mail-Authentifizierungseinstellungen, Registerkarte DKIM. Eine neu hinzugefügte Domain steht dort auf „Deaktiviert“ mit dem Status NoDKIMKeys. Der erste Versuch, den Schalter umzulegen, endet mit einer Fehlermeldung, die bereits die benötigten Werte enthält; danach lautet der Status CnameMissing, und im Detailbereich stehen beide Werte unter „CNAMEs veröffentlichen“ zum Kopieren bereit.

Die Hostnamen sind in allen Tenants gleich. Die Ziele haben sich im Mai 2025 geändert: Neu hinzugefügte Domains verweisen auf ein Ziel der Form selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft, wobei Microsoft den Buchstaben vor „-v1“ selbst vergibt. Ältere Domains behalten das bisherige Format, das auf die onmicrosoft.com-Domain des Tenants zeigt. Beide Formate dürfen für denselben Selektor nicht nebeneinander bestehen, und die Werte in Microsofts Anleitung dienen nur der Veranschaulichung; gültig ist, was das Portal oder Get-DkimSigningConfig ausgibt.

Sobald Microsoft die Einträge erkennt, laut Dokumentation nach einigen Minuten oder länger, lässt sich die Signatur einschalten. Ein TXT-Eintrag mit dem öffentlichen Schlüssel anstelle des CNAME wird nicht unterstützt, weil der CNAME die Schlüsselverwaltung an Microsoft delegiert.

Warum selector2 kein Überbleibsel ist

Von den beiden Selektoren ist immer nur einer aktiv. Der zweite kommt erst bei einer Schlüsselrotation zum Einsatz, und ohne seinen CNAME-Eintrag lässt sich nicht rotieren. Wer nur selector1 anlegt, weil die Signatur damit schon funktioniert, verbaut den späteren Schlüsselwechsel. Eine Rotation dauert laut Microsoft vier Tage (96 Stunden), bis der neue Schlüssel signiert.

Hier lohnt der Abgleich mit der Technischen Richtlinie TR-03182 „E-Mail-Authentifizierung“ des BSI, Version 1.0 vom 24. Januar 2024. Sie verlangt RSA-Schlüssel zwischen 1024 und 2048 Bit und eine Erneuerung des Schlüsselmaterials alle sechs Monate, ersatzweise eine dokumentierte Begründung. In Microsoft 365 ist beim Anlegen per PowerShell 1024 Bit voreingestellt; 2048 Bit lassen sich wählen, greifen aber erst mit der nächsten Rotation für den dann aktiven Selektor.

Tenant oder DNS-Hoster: die Aufteilung

Die Übersicht trennt die Arbeitsschritte nach dem Ort, an dem sie stattfinden. Für eine eigene Domain entsteht keiner der schützenden Einträge allein im Tenant, und keiner davon ist für die Zustellung nötig. Deshalb verläuft eine Migration ohne sie reibungslos.

DMARC stufenweise einführen

Microsoft nennt zwei Voraussetzungen: SPF für alle versendenden Domains und Subdomains, DKIM mit der eigenen Domain. Der Grund liegt im Prüfmechanismus. Eine Nachricht besteht DMARC nur, wenn SPF oder DKIM erfolgreich ist und die geprüfte Domain zur sichtbaren Absenderadresse passt. Ohne DKIM hängt das Ergebnis allein am SPF, und das bricht bei jeder Weiterleitung. Für die Einführung empfiehlt Microsoft einen Stufenplan, beginnend mit einer Subdomain mit wenig Mailaufkommen; die Hauptdomain kommt zuletzt.

1. Beobachten Eintrag mit p=none und rua-Adresse; die Berichte zeigen, welche Server im Namen der Domain senden.
2. Absender nachziehen Jede legitime Quelle aus den Berichten in SPF aufnehmen oder mit der eigenen Domain signieren lassen.
3. Aussortieren Auf p=quarantine erhöhen; fehlschlagende Mails landen beim Empfänger im Spam oder in der Quarantäne.
4. Abweisen Auf p=reject erhöhen; Empfänger lehnen gefälschte Mails ab.

Ein Detail der Microsoft-Anleitung ist inzwischen überholt. Sie schlägt vor, den Parameter pct in Schritten von 10 bis 100 Prozent anzuheben. RFC 9989, im Mai 2026 als Standards-Track-Dokument der IETF erschienen, ersetzt die bisherige Spezifikation RFC 7489 und führt pct nur noch als historisch, weil Empfänger Zwischenwerte selten korrekt umsetzten. An seine Stelle tritt der Testmodus t=y, bei dem Empfänger eine Stufe milder verfahren als angegeben. Vorsicht ist auch aus einem zweiten Grund geboten: Ausgehende Mails, die bei quarantine oder reject am Ziel an DMARC scheitern, leitet Microsoft über einen Zustellpool mit hohem Risiko, ohne Ausnahmemöglichkeit.

Was p=none leistet und was nicht

Der Modus p=none ist als Messphase gedacht. Er fordert Berichte an, verlangt aber keine Maßnahme gegen Nachrichten, die die Prüfung nicht bestehen; laut Microsoft greifen dann nur die übrigen Filter des Empfängers. Eine Domain auf p=none ist damit genauso fälschbar wie eine ohne Eintrag. Der Unterschied ist, dass der Inhaber davon erfahren kann, sofern jemand die Berichte liest.

Die TR-03182 zieht hier eine klare Linie. Das BSI erwartet quarantine oder reject, weil nur diese den Empfängern Schutz bieten, und nennt reject als langfristiges Ziel. Verpflichtend ist zudem mindestens eine rua-Adresse (TR-03182-06-M). Für Microsoft-365-Kunden ist eine weitere Vorgabe relevant: Die Berichte enthalten personenbezogene Daten und sind laut TR in der EU und DSGVO-konform zu verarbeiten. Microsoft verweist für die Auswertung auf Dienste aus dem Partnerkatalog der Microsoft Intelligent Security Association und rät zu einem eigenen Postfach oder einer Gruppe statt eines Benutzerpostfachs. Ob ein Dienst die EU-Vorgabe erfüllt, gehört vor die Auswahl.

Outlook als Empfänger: die Regeln seit Mai 2025

Im Blog von Microsoft Defender for Office 365 kündigte Microsoft am 2. April 2025 an, dass Domains mit mehr als 5.000 Mails pro Tag an Outlook.com-Adressen (hotmail.com, live.com, outlook.com) SPF und DKIM bestehen und DMARC mit mindestens p=none veröffentlichen müssen, ausgerichtet an SPF oder DKIM, möglichst an beiden. Mit einer Aktualisierung vom 29. April 2025 wurde aus der geplanten Zustellung in den Junk-Ordner eine Abweisung: Nicht konforme Nachrichten erhalten seit dem 5. Mai 2025 den Fehler „550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.“

Die Schwelle zielt auf Massenversender. Aufschlussreicher ist die Logik dahinter: Die Anforderung ist schon mit p=none erfüllt. Eine Domain kann also allen Zustellregeln genügen und trotzdem ungeschützt sein. Zustellbarkeit und Schutz der Absenderdomain sind zwei verschiedene Ziele, und als Empfänger setzt Microsoft nur das erste durch. Die TR-03182 trennt beides ausdrücklich: Wer DMARC nur für bessere Zustellraten nutzt, erfüllt die Richtlinie nicht, denn wer einen DMARC-Eintrag veröffentlicht, muss die Berichte auch regelmäßig auswerten.

Weitere Absender und die Frage der Zuständigkeit

Ein DMARC-Eintrag mit reject gilt für alle Mails mit der Domain im Absender, nicht nur für die aus dem Tenant. Newsletter-Werkzeuge, Ticketsysteme, Webshops oder Multifunktionsgeräte, die im Namen der Domain senden, brauchen einen Platz im SPF-Eintrag oder eine DKIM-Signatur mit der eigenen Domain. Für Dienste außerhalb der direkten Kontrolle empfiehlt Microsoft eine eigene Subdomain. Subdomains erben die DMARC-Richtlinie der Hauptdomain, brauchen aber eigene SPF- und DKIM-Einträge.

Daraus folgt die organisatorische Seite. In einen Migrationsplan gehören drei Punkte ausdrücklich hinein: wer Schreibzugriff auf die DNS-Zone hat, wer die DMARC-Berichte auswertet und bis wann die Richtlinie auf reject steht. Ohne diese Zuordnung entsteht der Zustand, den die Messung zeigt: ein zeitgemäßer Mailbetrieb, dessen Absenderdomain niemand schützt.

Häufige Fragen

Ist DMARC in Microsoft 365 standardmäßig aktiv?

Für eigene Domains nicht. Microsoft 365 legt keinen DMARC-Eintrag an, und es gibt dafür weder ein Portal noch ein PowerShell-Cmdlet. Der TXT-Eintrag unter _dmarc entsteht beim Registrar oder DNS-Hoster. Nur für die onmicrosoft.com-Domain des Tenants lässt sich DMARC im Admin Center anlegen, weil Microsoft diese Zone selbst verwaltet.

Wo werden die DKIM-CNAME-Einträge für Microsoft 365 angelegt?

In der DNS-Zone der eigenen Domain, also beim Registrar oder DNS-Hoster. Die Hostnamen lauten selector1._domainkey und selector2._domainkey. Die Zielwerte unterscheiden sich je Tenant und Domain und stehen im Defender-Portal unter den E-Mail-Authentifizierungseinstellungen oder in der Ausgabe von Get-DkimSigningConfig. Erst danach lässt sich die Signatur einschalten.

Warum zeigt das Defender-Portal den Status CnameMissing?

Microsoft hat die CNAME-Einträge noch nicht erkannt. Das dauert laut Dokumentation einige Minuten oder länger. Als häufige Fehler nennt Microsoft einen Hostnamen mit doppelt angehängter Domain, einen TXT-Eintrag statt eines CNAME und einen abweichenden Zielwert, etwa ohne das Partitionszeichen des seit Mai 2025 gültigen Formats.

Reicht p=none für Microsoft 365?

Für die Zustellregeln von Outlook.com reicht es, denn Microsoft verlangt von Großversendern mindestens p=none. Gegen gefälschte Absender schützt p=none nicht, weil es Empfänger zu keiner Maßnahme auffordert. Die BSI-Richtlinie TR-03182 erwartet deshalb quarantine oder reject und nennt reject als langfristiges Ziel.

Was gilt für Domains, die gar keine Mails versenden?

Auch sie lassen sich als Absender fälschen. Microsoft empfiehlt für solche geparkten Domains einen DMARC-Eintrag, der jeden Versand untersagt, und einen SPF-Eintrag v=spf1 -all, aber keine DKIM-Einträge. Die BSI-Richtlinie TR-03182 verlangt für sie zusätzlich einen Null-MX-Eintrag und DMARC reject mit Berichtsadresse.