M365 Exchange Online | Domain-Spoofing verhindern

Der From-Header einer E-Mail ist ein reines Textfeld. Jeder Absender darf hineinschreiben, was er will, und genau das tun Angreifer bei CEO-Fraud und Rechnungsbetrug. Deine Domain steht dann im Postfach des Empfängers, obwohl die Nachricht nie deinen Tenant gesehen hat. SPF und DKIM allein ändern daran nichts, weil beide Verfahren andere Bezeichner prüfen als den, den der Nutzer sieht. Erst DMARC verbindet die Prüfergebnisse mit dem sichtbaren Absender und macht aus zwei Einzelmaßnahmen eine durchsetzbare Richtlinie.

SPF prüft die Envelope-Adresse, also den Bezeichner aus dem SMTP-Kommando MAIL FROM (auch 5321.MailFrom oder P1-Absender). Die Domain in diesem Bezeichner muss nichts mit der Domain im From-Header (5322.From, P2-Absender) zu tun haben. Ein Angreifer registriert eine eigene Domain, veröffentlicht dafür einen sauberen SPF-Record, versendet über einen autorisierten Server und setzt im From-Header trotzdem buchhaltung@deine-domain.de. SPF liefert ein sauberes Pass, weil geprüft wurde, was der Angreifer selbst kontrolliert.

DKIM hat dasselbe strukturelle Problem aus anderer Richtung. Die Signatur beweist, dass die signierten Header und der Body seit dem Signieren unverändert sind und dass die Signaturdomain aus dem d=-Tag die Verantwortung übernimmt. Auch hier gilt: Die Signaturdomain muss nicht die Absenderdomain sein. Eine Nachricht kann mehrere gültige DKIM-Signaturen tragen, und ein Angreifer signiert eben mit seiner eigenen Domain.

Der fehlende Baustein heißt Identifier Alignment. DMARC verlangt, dass mindestens einer der authentifizierten Bezeichner zur Domain im From-Header passt: entweder die SPF-geprüfte MAIL-FROM-Domain oder die DKIM-Signaturdomain. Passt keiner von beiden, fällt DMARC durch. Zwei Modi stehen zur Wahl: Relaxed (Standard) verlangt dieselbe Organisationsdomain und erlaubt Subdomains, Strict verlangt eine identische Zeichenkette. In der Praxis reicht Relaxed für nahezu alle Szenarien, weil Bounce-Subdomains und Versanddienste sonst reihenweise scheitern.

Eine Konsequenz für die Praxis: DMARC wertet ausschließlich die SPF-Prüfung der MAIL-FROM-Identität aus. Ein SPF-Pass, der nur über die HELO-Identität zustande kommt, hilft DMARC nicht weiter.

Am 20. Mai 2026 hat der RFC-Editor die überarbeitete DMARC-Spezifikation veröffentlicht. RFC 9989 beschreibt das Kernprotokoll, RFC 9990 das aggregierte Reporting, RFC 9991 die Failure-Reports. Zusammen lösen diese Dokumente RFC 7489 und RFC 9091 ab. DMARC ist damit erstmals ein Standards-Track-Dokument der IETF (Proposed Standard) und nicht mehr nur informativ.

Für deine bestehenden Records ist das kein Bruch. Die Versionskennung bleibt v=DMARC1, und die Tags p, sp, adkim, aspf, rua, ruf und fo behalten ihre Bedeutung. Drei Punkte solltest du trotzdem kennen, weil sie deine Rollout-Strategie betreffen.

Erstens ist das pct-Tag entfallen. RFC 9989 widmet der Entfernung einen eigenen Anhang. An seine Stelle tritt t=y als Testmodus: Der Empfänger wendet dann eine Stufe unterhalb der deklarierten Richtlinie an, aus p=reject wird also faktisch Quarantäne. Unbekannte Tags müssen ignoriert werden, ein stehengebliebenes pct=100 schadet also nicht. Eine gestaffelte Prozentzahl unter 100 hat dagegen keine spezifizierte Wirkung mehr.

Zweitens ersetzt der DNS Tree Walk die Public Suffix List bei der Ermittlung der Organisationsdomain. Der empfangende Server arbeitet sich label-weise nach oben, maximal acht Abfragen. Für Author Domains mit mehr als acht Labels musst du den Policy-Record direkt an der Domain veröffentlichen, sonst findet ihn niemand.

Drittens gibt es neue Tags: np für nicht existierende Subdomains, psd zur Kennzeichnung von Public-Suffix-Domains und das erwähnte t. Gerade np=reject ist praktisch, weil Angreifer bevorzugt erfundene Subdomains wie rechnung.deine-domain.de verwenden.

Microsoft Learn verweist in der DMARC-Dokumentation weiterhin auf RFC 7489 und beschreibt pct als reguläres Tag. Das ist derzeit die Realität in den Docs, ändert aber nichts an der Normlage.

Für die initiale Domain *.onmicrosoft.com verwaltet Microsoft den SPF-Record selbst, dort musst du nichts tun. Für jede eigene Domain legst du den TXT-Record beim Registrar an, weil Microsoft 365 keine Portalfunktion und kein Cmdlet dafür anbietet.

Microsoft empfiehlt für M365-Domains den Hard Fail -all und begründet das mit DMARC: Bei ~all wird die DMARC-Richtlinie faktisch wirkungslos, wenn die Nachricht zusätzlich keine DKIM-Signatur trägt. Wer also Softfail stehen lässt, verschenkt einen Teil der Wirkung von p=reject.

Zwei Grenzen bestimmen den Alltag. Pro Domain oder Subdomain ist genau ein SPF-Record erlaubt, mehrere führen zu einem permerror. Und die Auswertung darf höchstens zehn DNS-Lookups auslösen. Jedes include:, a, mx, exists und redirect zählt mit, verschachtelte Includes zählen mehrfach. IP-Adressen und CIDR-Bereiche zählen nicht. Wenn dein Record an dieser Grenze kratzt, verlagerst du Newsletter- und Ticketsysteme auf eine eigene Subdomain, denn jede Subdomain bringt ihr eigenes Lookup-Budget mit. Ein TTL von mindestens 3600 Sekunden verhindert, dass Timeouts sporadische Fehlprüfungen erzeugen.

Ohne Konfiguration signiert Microsoft 365 ausgehende Nachrichten deiner Custom Domain nicht. Für Absender in der initialen *.onmicrosoft.com-Domain passiert die Signatur automatisch, was dir bei Alignment aber nichts nützt, weil im From-Header deine echte Domain steht.

Den Weg ins Portal findest du - https://security.microsoft.com/authentication?viewid=DKIM

Microsoft erzeugt beim Aktivieren zwei Schlüsselpaare und erwartet zwei CNAME-Records im DNS deiner Domain. Aktiv ist immer nur ein Selektor, der zweite existiert für die Rotation. Die Zielwerte holst du dir aus dem Portal oder per PowerShell, konstruieren solltest du sie nicht:

Seit Mai 2025 gilt für neu hinzugefügte Custom Domains ein geändertes CNAME-Format mit einem dynamisch vergebenen Partitionszeichen:

Bestehende Domains und initiale Domains laufen weiter im alten Format ohne Partitionszeichen und ohne dkim.mail.microsoft. Beide Formate können für denselben Selektor nicht koexistieren. Das Partitionszeichen vergibt Microsoft, es ist nicht konfigurierbar.

Vier Fehler kosten regelmäßig Zeit. Der Hostname enthält nur selector1._domainkey, weil viele DNS-Anbieter die Zone automatisch anhängen. Der zweite Selektor fehlt, was die spätere Rotation blockiert. Statt CNAME wird ein TXT-Record mit dem Public Key angelegt, was Microsoft 365 nicht unterstützt. Und bei Cloudflare bleibt der Proxy aktiv, sodass die Auflösung auf Cloudflare-IPs statt auf das CNAME-Ziel zeigt und die Verifikation scheitert.

Nach dem Anlegen der Records setzt du den Schalter für die Domain auf aktiviert oder nutzt PowerShell:

Die Schlüsselrotation stößt du im Detailbereich oder per Cmdlet an. Neue Schlüssel signieren erst nach 96 Stunden, bis dahin bleibt der bisherige private Schlüssel im Einsatz. Standardgröße ist 1024 Bit, für 2048 Bit gibst du den Parameter explizit an:

Die Erhöhung greift zunächst nur für den nächsten aktiven Selektor, der zweite zieht bei der Folgerotation nach. Für die initiale *.onmicrosoft.com-Domain gibt es derzeit keine automatische Rotation.

Erst wenn SPF und DKIM für alle Versandquellen stehen, kommt der DMARC-Record. Startpunkt ist immer der Monitoring-Modus, weil du die Reports brauchst, um vergessene Absender zu finden: Ticketsystem, ERP, Monitoring-Server, Marketing-Tool, der Scanner im Flur.

Ohne rua bekommst du keine aggregierten Reports, und ohne Reports ist der Schritt zur Durchsetzung ein Blindflug. Liegt die Empfängeradresse in einer anderen Domain, muss dort ein autorisierender Record existieren, sonst liefern viele Empfänger nicht aus:

Danach erhöhst du auf p=quarantine und beobachtest weiter. Für die Testphase auf dem Weg zur Durchsetzung nutzt du nach RFC 9989 das t-Tag statt einer Prozentangabe:

Wenn die Reports über mehrere Wochen sauber sind, entfernst du t=y und die Richtlinie greift vollständig. Rechne bei Domains mit vielen Quellen mit Monaten statt Wochen, weil quartalsweise oder jährlich laufende Versender sonst erst nach der Scharfschaltung auffallen.

Für die initiale *.onmicrosoft.com-Domain legst du den Record im Admin Center an, weil die Zone Microsoft gehört. Parkdomains bekommen v=spf1 -all und v=DMARC1; p=reject; und ausdrücklich keine DKIM-Records: Ohne Public Key im DNS kann eine gefälschte Signatur gar nicht erst validieren.

Beachte die Rückwirkung auf deinen eigenen Versand. Ausgehende Nachrichten aus Microsoft 365, die beim Ziel an DMARC scheitern, laufen über den High Risk Delivery Pool, sobald deine Richtlinie auf p=quarantine oder p=reject steht. Ein Override dafür existiert nicht.

Exchange Online wertet DMARC-Richtlinien anderer Domains standardmäßig aus. In der Anti-Phishing-Richtlinie steuert das die Einstellung zum Berücksichtigen der DMARC-Richtlinie bei erkanntem Spoofing. Die Defaults der Standardrichtlinie:

Eine abgelehnte Nachricht quittiert Exchange Online mit 550 5.7.1, im Authentication-Results-Header steht dmarc=fail action=oreject und compauth=fail reason=100. Das o steht für origin, die Ablehnung folgt also der Richtlinie des Ursprungs.

Ein Detail für Umgebungen mit vorgelagertem Gateway: Aggregierte Reports versendet Microsoft 365 nur, wenn der MX-Record direkt auf Microsoft 365 zeigt. Sitzt ein Drittanbieter davor, entfällt der Versand, und die Quellerkennung für SPF, DKIM und DMARC funktioniert nur mit aktiviertem Enhanced Filtering for Connectors. Failure-Reports über ruf verschickt Microsoft 365 in keinem Fall, auch wenn eine gültige Adresse im fremden Record steht.

Weiterleitungen brechen SPF, weil die weiterleitende Instanz eine eigene Envelope-Adresse setzt. DKIM überlebt eine reine Weiterleitung, solange der signierte Bereich unverändert bleibt. Mailinglisten ändern Betreff und Body und zerstören damit auch die Signatur. Für solche Zwischenstationen konfigurierst du vertrauenswürdige ARC-Sealer, statt Ausnahmen über Transportregeln oder die Tenant Allow/Block List zu bauen:

Der zweite Klassiker sind externe Versanddienste. SPF passt, DMARC scheitert trotzdem, weil MAIL FROM auf bounce.dienstleister.de zeigt und die DKIM-Signatur mit d=dienstleister.de gesetzt wird. Zwei Wege führen aus dem Problem: Der Dienst signiert mit deiner Domain, oder er nutzt eine Envelope-Adresse in deiner Domain. Praktikabel ist meist eine dedizierte Subdomain wie mailing.contoso.de mit eigenem SPF-Record, eigenem DKIM-Schlüssel und eigenem DMARC-Record. Deine Hauptdomain behält dann ihre Reputation, selbst wenn der Dienstleister Fehler macht.

Der dritte Punkt betrifft Massenversand. Microsoft verlangt seit dem 5. Mai 2025 von Domains, die mehr als 5.000 Nachrichten pro Tag an Outlook.com, Hotmail.com und Live.com senden, bestandene SPF- und DKIM-Prüfungen sowie mindestens p=none mit Alignment. Nicht konforme Nachrichten landeten zunächst im Junk-Ordner, laut Microsofts Ankündigung folgt die Ablehnung mit dem Fehler 550 5.7.515. Für Business-Postfächer in Microsoft 365 gilt diese Schwelle nicht, für den Newsletter an Privatkunden sehr wohl.

Nach jeder Änderung prüfst du drei Dinge. Erstens die DNS-Sicht:

Zweitens den Authentication-Results-Header einer Testmail an ein externes Postfach. Dort muss dmarc=pass stehen, und header.d= beziehungsweise smtp.mailfrom= müssen zu header.from= passen. Wichtig: Zwischen zwei Postfächern derselben Organisation fehlt die DKIM-Signatur, teste also immer nach außen.

Drittens die Reports. Der wertvollste Befund im XML ist die Lücke zwischen auth_results und policy_evaluated. Steht dort SPF-Ergebnis pass, aber im Block policy_evaluated ein fail, dann ist der Absender autorisiert und trotzdem nicht aligned. Genau diese Kombination erkennst du in keiner Klick-Oberfläche, sondern nur im Report.

DMARC mit p=reject ist der stärkste technische Schutz gegen exaktes Domain-Spoofing, und die Formulierung verdient beide Einschränkungen. Technisch, weil die Richtlinie nur am empfangenden Server wirkt, der DMARC auswertet und die Vorgabe respektiert. Dazu ist kein Empfänger verpflichtet, RFC 9989 formuliert das ausdrücklich als Kann-Bestimmung. Exakt, weil DMARC nur die Verwendung deiner Domain im From-Header absichert. Lookalike-Domains, ähnlich aussehende Zeichen und Angriffe über den Anzeigenamen bleiben außerhalb des Schutzbereichs, und genau diese Vektoren dominieren bei BEC-Angriffen. Gegen sie brauchst du Impersonation Protection aus Defender for Office 365 und Nutzer, die eine ungewöhnliche Zahlungsanweisung hinterfragen.

Der Aufwand liegt nicht im DNS-Record, sondern in der Inventur davor. Jede Quelle, die im Namen deiner Domain versendet, muss gefunden, autorisiert und aligned werden. Wer diesen Schritt überspringt und direkt auf p=reject geht, blockiert zuverlässig die eigene Rechnungsstellung. Wer dagegen bei p=none stehen bleibt, hat einen Monitoring-Record ohne Schutzwirkung, denn ohne Durchsetzung ändert die Richtlinie an der Zustellung gefälschter Nachrichten nichts.

Der praktikable Weg bleibt der gestaffelte: Reports einsammeln, Quellen bereinigen, auf Quarantäne gehen, mit t=y testen, dann scharf schalten. Setz dabei np=reject von Anfang an, weil erfundene Subdomains kein legitimes Mailaufkommen haben und du dort ohne Risiko sofort durchsetzen kannst. Nach der Umstellung bleibt DMARC eine Daueraufgabe: Jeder neue SaaS-Dienst, jede Marketing-Kampagne und jede Migration kann eine Versandquelle einführen, die niemand im DNS hinterlegt hat. Ein Report-Auswerter und ein Blick pro Monat kosten weniger Zeit als der erste Anruf eines Kunden, der eine gefälschte Zahlungsaufforderung mit deinem Absender erhalten hat.