In vielen Microsoft-365-Tenants, die ich betreue, ist die DMARC-Durchsetzung erst richtig auf die Tagesordnung gekommen, als Google, Yahoo und schließlich auch Microsoft (seit Mai 2025 für Outlook.com & Co.) ihre Anforderungen verschärft haben. Einen p=none-Record für die eigene Domäne hatten viele Organisationen zwar schon gesetzt, häufig allerdings eher aus Compliance-Gründen. Seit Bulk-Sender mit mehr als 5.000 Mails pro Tag eine funktionierende Authentifizierung brauchen, lässt sich DMARC aber nicht länger halbherzig betreiben. Wer die eigenen Mail-Flows und vor allem Drittanbieter wie Newsletterdienste, Ticketing-Systeme oder Marketing-Automation nicht sauber erfasst und vorbereitet, muss damit rechnen, dass legitime Nachrichten im Quarantäne- oder sogar im Reject-Modus verloren gehen.

Microsoft verlangt seit Mai 2025 korrekt ausgerichtete SPF- und DKIM-Einträge

Seit dem 5. Mai 2025 müssen Absender, die mehr als 5.000 Nachrichten pro Tag verschicken, für alle Mails an outlook.com-, hotmail.com- und live.com-Adressen SPF und DKIM korrekt eingerichtet und auf die Absenderadresse ausgerichtet (aligned) haben. Außerdem ist ein DMARC-Record Pflicht, wobei Microsoft p=none als Mindestanforderung akzeptiert. Ernst wird es spätestens beim Wechsel zu p=quarantine oder p=reject, denn ab dann hängt es an der Konfiguration, ob legitime E-Mails ankommen oder geblockt werden. Prinzip und Optionen beschreibt die DMARC-Dokumentation von Microsoft. Wer noch nicht sicher ist, wie man SPF und DKIM sauber setzt, findet im Beitrag SPF, DKIM und DMARC in Exchange Online meistern ein erprobtes Praxisbeispiel.

Jedes Drittsystem muss vor der Umstellung erfasst und ausgerichtet sein

In der Praxis stolpert man bei der DMARC-Durchsetzung vor allem über die schiere Zahl an Systemen, die im Namen der eigenen Domäne E-Mails verschicken. Ich denke dabei an klassische SaaS-Newsletterdienste, Ticketsysteme und CRM-Plattformen, aber ebenso an Multifunktionsdrucker oder Cloud-Tools, die „direkt“ senden. Viele davon beherrschen inzwischen DKIM, vollständig dokumentiert ist das allerdings selten. Aus Erfahrung, und nach einigen hektischen Troubleshooting-Sessions, rate ich deshalb immer dazu, vor der Umstellung auf p=quarantine oder p=reject tatsächlich alle legitimen Quellen zu erfassen und bei jeder zu klären, ob sie SPF und idealerweise DKIM unterstützt. Richtig knifflig wird es bei Systemen, die „Direct Send“ nutzen und sich deshalb nicht über Exchange Online authentifizieren. Mehr dazu steht im Beitrag Direct Send blockieren und interne Domains endlich schützen.

Praktischer Tipp: Das DMARC-Reporting lohnt sich schon im Testbetrieb mit p=none, weil sich verdächtige Quellen so früh erkennen lassen. Viele Tools bereiten Aggregate Reports übersichtlich auf, bei kleinen Domänen genügt oft schon eine schnelle, pragmatische Auswertung in Excel.

DMARC-Aggregate-Reports zeigen auf einen Blick, welche Absender und IP-Adressen auftauchen und wo die Authentifizierung scheitert. Wer die Reports per E-Mail bekommt und etwa Dmarcian oder Postmark einsetzt, hat mit wenig Aufwand einen guten Überblick.

Im Defender-Portal lässt sich DKIM für Exchange Online übersichtlich aktivieren

Microsoft hat die DKIM-Konfiguration im Defender-Portal (endlich) so übersichtlich gestaltet, dass sie sich auch in größeren Tenants mit mehreren Domains und Subdomains gut verwalten lässt. Für Exchange Online liegen die Einstellungen unter Defender-Portal → E-Mail & Zusammenarbeit → Richtlinien & Regeln → Bedrohungsrichtlinien → E-Mail-Authentifizierungseinstellungen → DKIM. Dort zeigt das Portal für jede Domäne den DKIM-Status an, und sobald die nötigen CNAME-Einträge im DNS stehen, lassen sich neue DKIM-Signaturen aktivieren. Häufig ist die Hauptdomäne bereits signiert, während ein externer Dienst im Namen einer Subdomäne verschickt. Auch dafür kann man im Portal in der Regel einen eigenen DKIM-Key aktivieren.

// Im DNS der Domäne hinzufügen, Beispiel für DKIM mit Exchange Online
selector1._domainkey  CNAME  selector1-domain-com._domainkey.tenant.onmicrosoft.com
selector2._domainkey  CNAME  selector2-domain-com._domainkey.tenant.onmicrosoft.com

Voraussetzung: Administrative Rechte im Defender-Portal und Zugriff auf den DNS-Provider der Domäne. Die einzelnen Schritte erklärt die DKIM-Anleitung von Microsoft gut nachvollziehbar.

Subdomains und geparkte Domains brauchen eine eigene strikte DMARC-Policy

Bei der DMARC-Durchsetzung wird oft übersehen, dass die Policy nur für die Domäne gilt, für die sie gesetzt ist; viele DMARC-Parser betrachten Subdomains gesondert. Damit Angreifer eine geparkte oder kaum genutzte Subdomain nicht zum Versand missbrauchen, sollte man für sie einen expliziten DMARC-Eintrag mit strikter Policy (z. B. p=reject) anlegen. Für Domains, die überhaupt keine Mails verschicken („Non-Sender-Domains“), bietet sich ebenfalls diese Konfiguration an:

_dmarc.geparktedomain.de. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

Damit sind Angriffe über geparkte Domains zuverlässig unterbunden. Trotzdem begegnen mir im Alltag noch immer viele Unternehmen, die genau an dieser Stelle eine offene Flanke haben.

Der Weg von p=none zur echten Durchsetzung verläuft in mehreren Stufen

Die eigentliche Schwierigkeit liegt darin, von p=none auf p=quarantine oder p=reject umzustellen, ohne dass legitime Mails verloren gehen. Der Ablauf lässt sich in Stufen gliedern, wie das folgende Diagramm zeigt:

flowchart TD
    Start["DMARC p=none aktiv"] --> Reports["DMARC Aggregate Reports sammeln"]
    Reports --> Inventory["Absenderquellen inventarisieren"]
    Inventory --> DKIMCheck["DKIM für alle Quellen prüfen"]
    DKIMCheck --> Subdomains["Subdomains & Non-Sender prüfen"]
    Subdomains --> Quarantine["Policy auf p=quarantine setzen"]
    Quarantine --> Reject["Policy auf p=reject erhöhen"]

Abbildung: Schrittweise Umstellung auf DMARC-Durchsetzung – vom Test- zum Livebetrieb.

Im laufenden Betrieb bedeutet das, die DMARC-Reports dauerhaft im Blick zu behalten und nicht nur in der Anfangsphase. Gerade bei geschäftskritischen E-Mail-Flows tauchen so auch nach Monaten noch „vergessene“ Systeme oder neue Drittdienste auf, die plötzlich betroffen sind. Parallel zum Wechsel sollte man die wichtigsten Admins und Power-User informieren. Oft melden nämlich zuerst die Anwender fälschlich geblockte Mails, und genau daran erkennt man, dass ein Flow bei der DMARC-Durchsetzung durchs Raster gefallen ist.

Nach vielen umgestellten Tenants bleibt DMARC für mich eine Daueraufgabe

DMARC-Enforcement ist weniger eine Technikübung als ein fortlaufender Governance-Prozess. Wer seine Flows, Drittsysteme und Domains kennt, muss wenig befürchten, auch wenn der Schritt Zeit und Nerven kostet. Wichtig ist, DMARC nicht einmal „abzuhaken“ und dann zu vergessen, sondern Abläufe zu schaffen, die neue SaaS-Tools, Subdomains und Hybrid-Szenarien früh berücksichtigen. Wer SPF, DKIM und DMARC einmal sauber umgesetzt hat, ist danach für neue regulatorische Anforderungen und gegen Phishing-Angriffe deutlich besser gerüstet.