DMARC-Enforcement ohne Vorbereitung: Warum der Sprung von p=none zu p=reject scheitert

Das Szenario: Zwei Admins, eine Domain, kein Plan

Ein IT-Dienstleister bekommt einen Auftrag: Zwei M365-Admins sollen die DMARC-Policy ihrer Unternehmens-Domain von p=none auf p=reject anheben. Klingt nach einer Stunde Arbeit. Das Problem: Die beiden haben noch nie mit DMARC gearbeitet, es gibt keine Dokumentation der autorisierten Sender, und niemand hat die vorhandenen Aggregate-Reports je ausgewertet. Kein Sender-Inventar, keine Testphase, kein Rollback-Plan.

Dieses Szenario ist kein Einzelfall. Es taucht regelmäßig in IT-Foren auf – zuletzt in einem viel diskutierten Thread auf r/DMARC, in dem ein erfahrener Admin genau diese Situation schildert und fragt, wie er seine Kollegen bremsen soll, bevor der Schaden entsteht.

Was bei einem unvorbereiteten p=reject passiert

DMARC mit p=reject weist empfangende Mailserver an, E-Mails abzulehnen, die SPF und DKIM nicht bestehen. Das klingt gut – bis man merkt, dass viele legitime Sender in Unternehmen gar nicht korrekt konfiguriert sind.

Typische Opfer eines überstürzten Enforcement:

• Marketing-Tools wie Mailchimp, HubSpot oder Brevo, die über eigene IP-Ranges versenden, aber nicht im SPF-Record stehen
• Buchhaltungssoftware, die E-Mails direkt über SMTP versendet, ohne DKIM-Signatur
• Externe Dienstleister, die im Namen der Domain mailen – Recruiting-Plattformen, Ticketsysteme, Monitoring-Tools
• Interne Relay-Server, die bei einer M365-Migration vergessen wurden

Wenn p=reject aktiv ist und einer dieser Sender nicht korrekt konfiguriert ist, landen die E-Mails nicht im Spam – sie werden hart abgewiesen. Der Absender bekommt einen Bounce, der Empfänger sieht nichts. Im schlimmsten Fall merkt das Unternehmen es erst, wenn Kunden fragen, warum sie keine Angebote oder Rechnungen erhalten haben.

Warum DMARC-Reports der einzige verlässliche Ausgangspunkt sind

Bevor man auch nur über p=quarantine nachdenkt, muss man wissen, wer im Namen der Domain sendet. Die einzige zuverlässige Quelle dafür sind DMARC Aggregate-Reports (RUA). Diese XML-Berichte werden von empfangenden Mailservern – Google, Microsoft, Yahoo und anderen – täglich an die im DNS eingetragene Reporting-Adresse geschickt.

Das Problem: Rohe XML-Reports sind für Menschen kaum lesbar. Ein einzelner Bericht kann Hunderte von Zeilen enthalten, aufgeteilt nach Quell-IP, Sending-Domain, SPF-Ergebnis und DKIM-Ergebnis. Wer diese Reports nicht systematisch auswertet, hat keinen Überblick – und genau das war die Situation der beiden M365-Admins im geschilderten Fall.

Ein strukturierter Prozess sieht so aus:

1. RUA-Adresse eintragen und mindestens vier Wochen Reports sammeln
2. Reports auswerten: Welche IPs senden für die Domain? Welche bestehen SPF, welche DKIM, welche beides?
3. Sender-Inventar erstellen: Jede legitime Quelle dokumentieren, SPF und DKIM für alle konfigurieren
4. Auf p=quarantine wechseln und weitere zwei bis vier Wochen beobachten
5. Erst dann p=reject – und auch danach weiter monitoren

Dieser Prozess dauert in der Praxis sechs bis zwölf Wochen. Wer ihn auf zwei Tage komprimiert, riskiert Mailausfall.

Die M365-Falle: Mehr Sender als gedacht

Microsoft 365 ist als Mailplattform gut dokumentiert, aber viele Unternehmen unterschätzen, wie viele zusätzliche Dienste E-Mails über ihre Domain versenden. Power Automate-Flows, SharePoint-Benachrichtigungen, externe Konnektoren – all das kann legitimer Mail-Traffic sein, der in keinem Sender-Inventar auftaucht.

Dazu kommt: M365 unterstützt DKIM-Signaturen für Custom Domains, aber die müssen explizit aktiviert werden. Wer das vergisst und p=reject setzt, blockiert unter Umständen seinen eigenen ausgehenden Traffic, wenn SPF durch Weiterleitungen bricht und kein DKIM als Fallback vorhanden ist.

Was der erfahrene Admin im Forum empfiehlt

Der Autor des Reddit-Threads bringt es auf den Punkt: Man kann zwei Admins nicht einfach mit einem DMARC-Enforcement-Auftrag losschicken, wenn sie noch nie einen Aggregate-Report gesehen haben. Das ist kein Vorwurf an die Admins – DMARC ist komplex, und ohne Tooling ist die Lernkurve steil.

Seine Empfehlung: Enforcement erst dann, wenn das Sender-Inventar vollständig ist und die Reports über mehrere Wochen sauber aussehen. Alles andere ist Glücksspiel.

Tooling macht den Unterschied

Der Unterschied zwischen einem erfolgreichen DMARC-Rollout und einem Mailausfall liegt meistens nicht am Wissen der Admins, sondern am Tooling. Wer DMARC-Reports manuell auswertet, übersieht Sender. Wer kein Monitoring hat, merkt Probleme zu spät.

Ein gutes DMARC-Monitoring-Tool sollte:

• Aggregate-Reports automatisch einlesen und auswerten
• Sender nach Compliance-Status gruppieren (SPF pass, DKIM pass, beides, keins)
• Neue oder unbekannte Sender-IPs sofort melden
• Den Weg von p=none zu p=reject mit konkreten Empfehlungen begleiten

Genau das ist der Ansatz von DMARCPulse: Reports automatisch analysieren, Sender-Inventar aufbauen und schrittweise Enforcement-Empfehlungen geben – damit IT-Admins wissen, wann sie sicher weiterschalten können.

Prüf jetzt kostenlos, wie deine Domain aufgestellt ist: DMARCPulse Free Domain Check