DMARC mit der Policy p=reject ist der Goldstandard im E-Mail-Schutz. Doch wer zu schnell umschaltet, riskiert, dass legitime E-Mails seiner Organisation im Spam landen oder komplett abgelehnt werden. Dieser Artikel zeigt Ihnen den sicheren Weg von p=none über p=quarantine bis zu p=reject und erklärt, wie Sie anhand Ihrer Aggregate Reports erkennen, wann der nächste Schritt sicher ist.
Was DMARC ist und warum die Policy entscheidend ist
DMARC (Domain-based Message Authentication, Reporting and Conformance) baut auf SPF und DKIM auf. Es teilt empfangenden Mailservern mit, was mit Nachrichten geschehen soll, die weder SPF noch DKIM bestehen. Die Policy steuert das Verhalten:
- p=none – Nur beobachten. E-Mails werden zugestellt, aber Reports werden generiert. Sie erhalten Einblick, wer im Namen Ihrer Domain sendet.
- p=quarantine – Verdächtige E-Mails werden in den Spam-Ordner verschoben. Legitimate Quellen, die noch nicht korrekt konfiguriert sind, fallen sofort auf.
- p=reject – E-Mails, die die Prüfung nicht bestehen, werden komplett abgelehnt. Maximaler Schutz vor Spoofing und Phishing.
TL;DR: Der sichere Pfad zu p=reject dauert in der Regel 4 bis 8 Wochen.
Starten Sie mit p=none, analysieren Sie 2-3 Wochen lang Ihre Aggregate Reports, wechseln Sie dann zu p=quarantine mit einem niedrigen pct-Wert, und aktivieren Sie p=reject erst, wenn alle legitimen Quellen SPF- und DKIM-aligned sind.
Phase 1: p=none – Die Beobachtungsphase (Woche 1-3)
Der erste DMARC-Record, den Sie setzen, sollte immer p=none mit einer rua-Adresse sein, an die Aggregate Reports gesendet werden. Ein typischer DNS-Eintrag sieht so aus:
v=DMARC1; p=none; rua=mailto:dmarc-reports@ihre-domain.de; fo=1;
In den nächsten zwei bis drei Wochen sammeln Sie Daten. Die XML-basierten Aggregate Reports zeigen Ihnen für jede IP-Adresse, die E-Mails über Ihre Domain sendet, ob SPF und DKIM bestanden haben und ob Alignment vorliegt. Wichtig: Lesen Sie nicht nur die Bestehensrate. Prüfen Sie gezielt, welche IP-Adressen fehlschlagen. Häufige Ursachen sind:
- Newsletter-Tools (Mailchimp, CleverReach, Brevo), die noch nicht im SPF-Record stehen
- Ticketsysteme oder CRM-Plattformen, die im Namen Ihrer Domain senden
- Weiterleitungen über externe Mailserver, die SPF brechen
- Alte Systeme (z.B. Drucker oder ERP mit SMTP-Versand), die kein DKIM unterstützen
Korrigieren Sie jeden fehlgeschlagenen legitimen Absender, indem Sie entweder den SPF-Record erweitern oder DKIM-Signing für die jeweilige Plattform aktivieren. Erst wenn Ihre Reports über mindestens sieben Tage hinweg keine unerwarteten Fehlschläge mehr zeigen, gehen Sie zum nächsten Schritt.
Phase 2: p=quarantine – Der Stresstest (Woche 3-5)
Wechseln Sie nun zu p=quarantine, aber nutzen Sie den pct-Parameter, um das Risiko zu begrenzen:
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@ihre-domain.de; fo=1;
Mit pct=25 wird die Quarantine-Policy nur auf 25 % der fehlschlagenden E-Mails angewendet. Die restlichen 75 % werden weiterhin zugestellt, aber gemeldet. Erhöhen Sie den Wert schrittweise: 25 % für eine Woche, dann 50 %, dann 100 %. Beobachten Sie bei jedem Schritt Ihre Reports und fragen Sie intern nach, ob E-Mails im Spam-Ordner gelandet sind.
Diese Phase deckt Probleme auf, die in der None-Phase unsichtbar waren, insbesondere E-Mail-Weiterleitungen. Wenn ein Geschäftspartner Ihre E-Mails automatisch an eine andere Adresse weiterleitet, bricht SPF, weil der weiterleitende Server nicht in Ihrem SPF-Record steht. Die Lösung ist DKIM: Eine gültige DKIM-Signatur überlebt Weiterleitungen, solange der Body nicht verändert wird.
Phase 3: p=reject – Der volle Schutz (ab Woche 5-8)
Wenn bei pct=100 und p=quarantine keine legitimen E-Mails mehr betroffen sind, ist es Zeit für den letzten Schritt:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@ihre-domain.de; fo=1;
Ab jetzt wird jede E-Mail, die nicht SPF- oder DKIM-aligned ist, vom empfangenden Server abgelehnt. Spoofing-Versuche erreichen Ihre Kunden, Partner und Mitarbeiter nicht mehr. Wichtig: Behalten Sie die Reports auch nach Aktivierung von p=reject im Blick. Neue Dienste, Mitarbeiterwechsel oder Systemupdates können jederzeit neue Absenderquellen einführen.
Die häufigsten Fehler auf dem Weg zu p=reject
Fehler 1: Direkt zu p=reject wechseln
Ohne Beobachtungsphase riskieren Sie, dass Rechnungen, Bestellbestätigungen oder Support-Mails Ihrer Kunden nie ankommen. Der Schaden ist oft größer als der durch Spoofing.
Fehler 2: Aggregate Reports nicht auswerten
Die XML-Dateien manuell zu lesen ist mühsam. Viele Unternehmen ignorieren sie deshalb komplett. Ohne Auswertung fehlt die Datengrundlage für sichere Entscheidungen.
Fehler 3: SPF-Record mit zu vielen Includes
SPF erlaubt maximal 10 DNS-Lookups. Wer unkontrolliert Dienste hinzufügt, überschreitet dieses Limit, und SPF schlägt für alle E-Mails fehl. Prüfen Sie Ihren SPF-Record regelmäßig.
Fehler 4: Subdomains vergessen
DMARC gilt standardmäßig nur für die Hauptdomain. Setzen Sie sp=reject oder separate DMARC-Records für Subdomains, die ebenfalls E-Mails senden.
Warum ein DMARC-Monitoring-Tool den Unterschied macht
Der Weg von p=none zu p=reject ist nicht kompliziert, aber er erfordert systematische Auswertung. Aggregate Reports im XML-Format manuell zu lesen, ist für die meisten IT-Abteilungen nicht praktikabel. Ein spezialisiertes Monitoring-Tool visualisiert die Daten, warnt bei neuen fehlschlagenden Quellen und zeigt klar, wann der nächste Policy-Schritt sicher ist.
Genau hier setzt DMARCFlow an: Übersichtliche Dashboards statt XML-Dateien, automatische Erkennung nicht-alignierter Quellen und klare Handlungsempfehlungen für jeden Schritt der Policy-Migration. So behalten auch Teams ohne dedizierte E-Mail-Sicherheitsexperten die Kontrolle.
DMARC sicher aktivieren mit DMARCFlow
DMARCFlow macht den Weg zu p=reject planbar und sicher. Aggregate Reports werden automatisch ausgewertet, fehlende SPF/DKIM-Konfigurationen aufgedeckt und der richtige Zeitpunkt für den nächsten Policy-Schritt signalisiert. Entwickelt und gehostet in Deutschland.
Mehr über DMARCFlow erfahren oder direkt starten:
DMARCFlow entdecken