DMARC-Reports verstehen und auswerten: von p=none sicher zu p=reject

Du hast SPF, DKIM und einen DMARC-Record mit p=none eingerichtet – Glückwunsch, das ist der wichtigste erste Schritt. Aber was kommt danach? Die täglich eintreffenden RUA-Aggregat-Reports enthalten wertvolle Informationen darüber, wer in deinem Namen E-Mails versendet, welche davon die Authentifizierungsprüfungen bestehen und welche nicht. Erst wenn du diese Reports konsequent auswertest, alle legitimen Sender identifiziert und Fehlkonfigurationen behoben hast, kannst du deinen DMARC-Record schrittweise auf p=reject verschärfen – ohne dabei Rechnungen, Newsletter oder interne Benachrichtigungen ins Spam-Nirwana zu schicken. Seit November 2025 ist das kein optionales Nice-to-have mehr: Google lehnt bei Bulk-Sendern nicht-konforme Nachrichten dauerhaft ab.

Voraussetzungen

1. Fertig veröffentlichter DMARC-Record mit p=none und gültiger rua=-E-Mail-Adresse (SPF und DKIM mindestens 48 Stunden vor DMARC-Veröffentlichung aktiv)
2. Dediziertes E-Mail-Postfach für RUA-Reports, z. B. dmarc@example.com, oder Weiterleitungsadresse eines SaaS-Tools
3. DNS-Zugang zur Domain, um TXT-Records zu verwalten
4. Für parsedmarc Self-Hosted: Linux-Server (Debian/Ubuntu) mit mindestens 3 GB RAM, Python 3.10+, Elasticsearch 8.x, Kibana 8.x und IMAP-Zugang zum RUA-Postfach
5. Spreadsheet oder Dashboard zum Inventarisieren aller legitimen Sender (Quell-IP, Dienst, SPF/DKIM-Status, geplante Maßnahme)
6. Optional: MaxMind-GeoLite2-Account (kostenlos) für Geo-IP-Daten in parsedmarc

Schritt 1: RUA-Reports empfangen und manuell lesen

Sobald dein DMARC-Record mit einer gültigen rua=-Adresse veröffentlicht ist, treffen innerhalb von 24–48 Stunden die ersten Reports ein – vorausgesetzt, deine Domain versendet tatsächlich E-Mails und diese landen bei großen Empfangsservern wie Gmail, Microsoft oder Yahoo. Reports kommen als .zip- oder .gz-Anhänge per E-Mail an.

Wichtig: Wenn die rua=-Adresse auf eine andere Domain zeigt (z. B. ein externes Reporting-Tool), muss diese Ziel-Domain per DNS zustimmen. Prüfe, ob der TXT-Record example.com._report._dmarc.reporting-tool.com mit dem Wert v=DMARC1 existiert – fehlt er, liefern manche Absender ihre Reports gar nicht erst.

Ein RUA-Report-XML enthält drei Hauptblöcke:

1. report_metadata: Absendende Organisation, Report-ID, Zeitraum (Unix-Epoch-Timestamps, immer 24 Stunden UTC)
2. policy_published: Der zum Zeitpunkt des Reports gültige DMARC-Record deiner Domain (p, sp, adkim, aspf, pct)
3. record: Ein oder mehrere Einträge je Quell-IP – mit source_ip, count, Alignment-Ergebnissen und disposition

Zum manuellen Lesen entpackst und formatierst du die Datei so:

# Reports kommen als .zip oder .gz per Mail an
unzip report.xml.zip
# oder:
gzip -d report.xml.gz

# Lesbar formatieren:
xmllint --format report.xml | less

Das wichtigste Feld pro record-Eintrag ist die Kombination aus auth_results.spf.result, auth_results.dkim.result, policy_evaluated.spf und policy_evaluated.dkim. Die ersten beiden zeigen das reine Authentifizierungsergebnis; die letzten beiden zeigen das DMARC-Alignment-Ergebnis (passt die Domain auch zum From:-Header?). DMARC gilt als bestanden, wenn entweder SPF-Alignment oder DKIM-Alignment besteht – beide müssen nicht gleichzeitig passen.

Verifizieren: Öffne einen entpackten Report und suche nach dem Tag <policy_published>. Die darin enthaltene Policy muss deinem aktuellen DNS-Record entsprechen. Prüfe zusätzlich, ob Reports von Gmail (google.com), Microsoft (microsoft.com) und Yahoo (yahoo.com) eingehen – diese drei senden am zuverlässigsten.

# DMARC-Record im DNS prüfen:
dig TXT _dmarc.example.com
# Erwartete Ausgabe (Beispiel):
# _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Schritt 2: RUA-Reports automatisiert auswerten

Manuelle XML-Analyse skaliert nicht. Spätestens nach einer Woche solltest du auf ein Tool setzen. Du hast zwei Hauptoptionen: kostenlose SaaS-Dienste für den schnellen Einstieg, oder parsedmarc Self-Hosted für vollständige Kontrolle und langfristige Datenhoheit.

Option A: Kostenlose SaaS-Dienste

Für Postmark änderst du die rua=-Adresse im DMARC-Record auf die von Postmark bereitgestellte Adresse (oder richtest eine E-Mail-Weiterleitung ein) und erhältst wöchentlich einen aufbereiteten Digest – kein Konto nötig.

Option B: parsedmarc Self-Hosted

parsedmarc liest das RUA-Postfach automatisch via IMAP aus, parst alle XML-Reports und schreibt die Daten in Elasticsearch. Kibana visualisiert die Ergebnisse dann in einem fertigen Dashboard. Der Stack benötigt mindestens 3 GB RAM; für kleinere Umgebungen ist der SaaS-Weg einfacher.

# Abhängigkeiten installieren (Debian/Ubuntu):
sudo apt-get install -y python3-pip python3-venv python3-dev libxml2-dev libxslt-dev

# Systembenutzer anlegen:
sudo useradd --system --create-home --home-dir /opt/parsedmarc \
  --shell /usr/sbin/nologin --skel /dev/null parsedmarc

# Virtualenv + parsedmarc installieren:
sudo -u parsedmarc python3 -m venv /opt/parsedmarc/venv
sudo -u parsedmarc /opt/parsedmarc/venv/bin/pip install --upgrade pip
sudo -u parsedmarc /opt/parsedmarc/venv/bin/pip install --upgrade parsedmarc

Konfigurationsdatei unter /etc/parsedmarc.ini:

[general]
save_aggregate = True
save_failure = True

[imap]
host = imap.example.com
user = dmarc-reports@example.com
password = SicheresPasswort

[mailbox]
watch = True
delete = False

[elasticsearch]
hosts = 127.0.0.1:9200
ssl = False

systemd-Service anlegen und aktivieren:

# /etc/systemd/system/parsedmarc.service
[Unit]
Description=parsedmarc mailbox watcher
Documentation=https://domainaware.github.io/parsedmarc/
Wants=network-online.target
After=network.target network-online.target elasticsearch.service

[Service]
ExecStart=/opt/parsedmarc/venv/bin/parsedmarc -c /etc/parsedmarc.ini
ExecReload=/bin/kill -HUP $MAINPID
User=parsedmarc
Group=parsedmarc
Restart=always
RestartSec=5m

[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl enable --now parsedmarc

Für kleinere Umgebungen ohne Elasticsearch-Overhead: parsedmarc kann Reports auch als JSON oder CSV exportieren und unterstützt Splunk, S3, Syslog/GELF sowie Webhooks als alternative Ausgaben.

Verifizieren: Teste parsedmarc einmalig auf eine einzelne XML-Datei und prüfe, ob die Ausgabe korrekt ist:

/opt/parsedmarc/venv/bin/parsedmarc report.xml
# Erwartete Ausgabe: JSON-Block mit aggregate_reports-Array,
# jeweils mit source_ip, count, spf_aligned, dkim_aligned, disposition

# Service-Status prüfen:
sudo systemctl status parsedmarc
# Zeile "Active: active (running)" wird erwartet

Schritt 3: Legitime Sender inventarisieren

Jetzt kommt die eigentliche Detektivarbeit. Öffne dein Dashboard oder Spreadsheet und trage für jede Quell-IP ein: Welcher Dienst ist das, wie lauten SPF- und DKIM-Alignment-Ergebnis, und was ist zu tun?

Typische „Schatten-Sender", die in RUA-Reports auftauchen und oft übersehen werden:

1. Marketing-/Newsletter-Plattformen (Mailchimp, Brevo, CleverReach)
2. ERP-Systeme (SAP, Microsoft Dynamics/Navision)
3. Multifunktionsdrucker mit SMTP-Relay (tauchen oft als Relay-IP auf, nicht als interne 192.168.x.x-Adresse)
4. Helpdesk- und CRM-Software
5. Externe Monitoring-Dienste

Die folgende Tabelle zeigt, welche Aktion für welches Report-Muster angemessen ist:

Alignment relaxed vs. strict: Das Standard-Alignment ist relaxed (aspf=r, adkim=r): Subdomains werden akzeptiert, solange die organisatorische Domain übereinstimmt (z. B. bounce.newsletter.example.com passt zu From: example.com). Bei strict (aspf=s, adkim=s) müssen die Domains exakt übereinstimmen – für die meisten Organisationen ist relaxed die richtige Wahl.

Verifizieren: Erstelle eine Inventar-Tabelle mit allen Quell-IPs aus den letzten 30 Tagen. Jede IP muss einer Kategorie zugeordnet sein: „legitim + DMARC-pass", „legitim + fix nötig" oder „unbekannt/nicht legitim". Prüfe auch, ob dein SPF-Record das 10-Lookup-Limit einhält:

dig TXT example.com
# Zähle alle include:, a:, mx: und ptr:-Einträge
# Mehr als 10 DNS-Lookups führen zu SPF PermError (im Report sichtbar als:
# <result>permerror</result>)

Schritt 4: Fehlkonfigurationen beheben

Bevor du die Policy verschärfst, bringst du alle legitimen Sender auf DMARC-pass. Die häufigsten Aufgaben in dieser Phase:

1. Newsletter-Plattform: DKIM-Selektor per CNAME delegieren (z. B. selector1._domainkey.example.com CNAME selector1._domainkey.mailing-provider.com) und im Dashboard des Anbieters aktivieren
2. ERP/CRM: Custom Bounce-Domain auf eine Subdomain deiner Domain setzen (bounce.example.com) – das erzeugt SPF-Alignment im relaxed-Modus
3. Drucker/SMTP-Relay: IP des Relay-Servers in den SPF-Record aufnehmen (ip4:203.0.113.50)
4. SPF-Flattening: Wenn das 10-Lookup-Limit überschritten wird, Dienste konsolidieren oder ein SPF-Flattening-Tool verwenden, das alle include:-Ketten in direkte IP-Ranges auflöst

Warte nach jeder DNS-Änderung mindestens 48 Stunden und prüfe die nachfolgenden RUA-Reports auf Verbesserungen. Ziel ist eine Alignment-Pass-Rate von über 95 % über mindestens 30 aufeinanderfolgende Tage, bevor du die Policy verschärfst.

Einen Sonderfall stellen Weiterleitungen und Mailing-Listen dar: Sie brechen fast immer SPF-Alignment (neue Return-Path-Domain) und oft auch DKIM (Inhalt wird verändert). Diese erscheinen im Report als DMARC-fail, sind aber legitim. Das ist kein Grund, die Policy-Eskalation zu verzögern. Die Lösung liegt beim weiterleitenden Server (ARC-Seal), nicht bei dir.

Verifizieren: Prüfe nach der Fehlerbehebung SPF, DKIM und die CNAME-Delegation explizit:

# SPF-Record prüfen:
dig TXT example.com

# DKIM-Record prüfen (Selektor z.B. "google" oder "default"):
dig TXT google._domainkey.example.com
# Erwartete Ausgabe: TXT-Record mit "v=DKIM1; k=rsa; p=..."

# CNAME-Delegation prüfen:
dig CNAME selector1._domainkey.example.com
# Muss auf mailing-provider.com zeigen

Schritt 5: Schrittweise Eskalation zu p=reject

Sobald deine Inventar-Tabelle vollständig ist und die Pass-Rate über 95 % liegt, startest du die kontrollierte Eskalation. Beachte: Mindestens 90 Tage bei p=none, um auch monatliche und quartalsweise Sender zu erfassen.

Der pct=-Tag gibt an, welcher prozentuale Anteil der fehlschlagenden Nachrichten die härtere Behandlung erhält. Die restlichen Nachrichten werden weiterhin wie bei p=none behandelt. Alle Nachrichten werden dabei weiterhin geprüft und tauchen in den RUA-Reports auf – das ist ein häufiges Missverständnis.

Die konkreten DNS-Records für jede Phase:

# Phase 1 - Monitoring only:
v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1

# Phase 2a - Quarantine 10 % (Einstieg):
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com

# Phase 2c - Quarantine 50 %:
v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@example.com

# Phase 2e - Quarantine 100 %:
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com

# Phase 3 - Reject (Endziel):
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com

Tipp zur Subdomain-Policy: Ohne expliziten sp=-Tag erben alle Subdomains die Hauptdomain-Policy. Bei p=reject gilt das dann auch für interne Test-Subdomains. Wer Subdomains anders behandeln will, setzt sp=quarantine oder sp=none explizit.

Nach dem Wechsel zu p=reject ist das Monitoring nicht abgeschlossen. Einige Empfangsserver senden bei p=reject weniger RUA-Reports (sie lehnen auf SMTP-Ebene ab). Weniger Daten bei hoher Pass-Rate ist normal und kein Grund zur Beunruhigung. Neue Dienste müssen weiterhin ins Sender-Inventar aufgenommen werden, bevor sie live gehen.

Die Gmail- und Yahoo-Anforderungen seit Februar 2024 verlangen von Bulk-Sendern (mehr als 5.000 Mails pro Tag) unter anderem einen gültigen DMARC-Record. Seit November 2025 verschärft Google die Durchsetzung bis hin zu permanenten Ablehnungen bei Nicht-Konformität. Mehr zur Grundkonfiguration: SPF, DKIM und DMARC für Exchange Online einrichten.

Verifizieren: Prüfe nach jeder Policy-Änderung, ob der neue Record korrekt propagiert wurde, und beobachte die nächsten 2–3 Tage die RUA-Reports auf unerwartete Fehlschläge:

dig TXT _dmarc.example.com
# Erwartete Ausgabe nach Phase 2a:
# "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com"

# Unter Windows:
nslookup -type=TXT _dmarc.example.com

Troubleshooting / Typische Fehler

1. pct= falsch verstanden: Bei p=quarantine pct=10 werden 90 % der fehlschlagenden Nachrichten weiterhin zugestellt (wie bei p=none). Alle Nachrichten werden geprüft – nur 10 % der Fehlschläge erhalten die Quarantine-Behandlung. Kein Grund zur Panik bei vielen „fail"-Einträgen.
2. SPF PermError im Report (<result>permerror</result>): Das 10-DNS-Lookup-Limit wurde überschritten. Ursache: Zu viele include:-Einträge (Google Workspace, Mailchimp, Salesforce summieren sich schnell). Lösung: SPF-Flattening oder Konsolidierung.
3. Weiterleitungen erscheinen als DMARC-fail: Normal – eine Weiterleitung ändert den Return-Path und bricht oft die DKIM-Signatur. Kein Grund, die Policy-Eskalation aufzuschieben. ARC-Sealing durch den weiterleitenden Server löst das Problem.
4. RUA-Adresse auf externer Domain, Reports bleiben aus: Fehlt der Zustimmungs-TXT-Record example.com._report._dmarc.reporting-tool.com v=DMARC1 auf der Ziel-Domain, liefern manche Empfangsserver keine Reports.
5. DKIM-Signatur nach Schlüssel-Rotation gebrochen: Den alten DNS-TXT-Record (selector._domainkey) mindestens 48 Stunden nach der Rotation im DNS belassen – noch in der Zustellung befindliche Mails müssen mit dem alten Schlüssel validierbar bleiben.
6. parsedmarc-Fehler „ConnectionError: Unable to connect to Elasticsearch": Elasticsearch läuft nicht oder noch nicht vollständig gestartet. Prüfen mit systemctl status elasticsearch. Die After=elasticsearch.service-Zeile in der systemd-Unit-Datei sorgt für die korrekte Start-Reihenfolge.
7. Drucker/Multifunktionsgeräte tauchen nicht als erwartete IP auf: Das SMTP-Relay des Druckers taucht im Report auf, nicht die interne 192.168.x.x-Adresse. Den Relay-Server in SPF aufnehmen oder DKIM-Signierung am Relay konfigurieren.
8. Nach p=reject kommen keine Reports mehr: Einige Empfangsserver senden bei p=reject weniger oder keine RUA-Reports mehr (SMTP-Level-Ablehnung). Das Monitoring nicht einstellen – weniger Daten bei korrekter Konfiguration ist normal.

Häufige Fragen

Muss ich p=reject setzen, um bei Gmail und Yahoo zugestellt zu werden?

Formal reicht derzeit p=none als DMARC-Record. Aber seit November 2025 verschärft Google die Ablehnung bei Bulk-Sendern (mehr als 5.000 Mails pro Tag), die SPF, DKIM oder DMARC nicht korrekt implementiert haben. p=reject ist der empfohlene Endzustand und wird von allen großen Providern als Best Practice verlangt. Wer dauerhaft im Posteingang landen will, sollte p=reject anstreben.

Was ist der Unterschied zwischen RUA und RUF?

RUA (Aggregate Reports) sind tagesweise XML-Zusammenfassungen aller Authentifizierungsergebnisse von einem Empfangsserver – maschinell ausgewertet, kein Datenschutzproblem. RUF (Forensic Reports) sind Einzelnachrichten-Berichte bei DMARC-Fehlern und können E-Mail-Inhalte und Header enthalten (Datenschutz beachten!). Viele Anbieter wie Gmail senden gar keine RUF-Reports mehr. Für die Policy-Eskalation sind RUA-Reports vollständig ausreichend.

Was bedeutet „disposition=none" im Report, obwohl meine Policy p=quarantine ist?

Das ist normal bei pct < 100: Der pct-Wert bestimmt, welcher Prozentsatz der fehlschlagenden Nachrichten die härtere Behandlung erhält. Bei pct=10 erhalten 90 % der Fehlschläge weiterhin none als Disposition. Außerdem wenden manche Empfangsserver die Policy nach eigenem Ermessen an (local policy override), was ebenfalls zu disposition=none führen kann.

Mein ERP sendet E-Mails von meiner Domain, der SMTP-Server ist aber ein Drittanbieter. Wie löse ich das Alignment-Problem?

Du hast zwei Wege: (1) Den SMTP-Server des ERP-Dienstleisters in den SPF-Record aufnehmen und den Return-Path auf eine example.com-Subdomain setzen (Custom Bounce-Domain beim Anbieter konfigurieren) – dann passt SPF-Alignment im relaxed-Modus. (2) DKIM-Signierung durch den ERP-Anbieter mit einem example.com-Schlüssel einrichten via CNAME-Delegation des DKIM-Selektors. Methode 2 ist robuster und umgeht das SPF-Lookup-Limit.

Kann ich parsedmarc ohne Elasticsearch betreiben?

Ja. parsedmarc kann Reports als JSON-Dateien oder CSV exportieren und unterstützt alternativ Splunk (via HEC), S3, Syslog (GELF) und Webhooks. Für kleinere Umgebungen genügt oft der CSV-Export kombiniert mit der kostenlosen Postmark- oder Dmarcian-Auswertung. Der Elasticsearch-Stack lohnt sich erst bei mehreren Domains oder sehr hohem E-Mail-Volumen.

Wie lange dauert es, bis der erste RUA-Report ankommt?

Nach dem Veröffentlichen des DMARC-Records mit korrekter rua=-Adresse sollten innerhalb von 24–48 Stunden die ersten Reports eintreffen – vorausgesetzt, E-Mails von deiner Domain landen bei den jeweiligen Empfangsservern. Gmail, Microsoft und Yahoo sind die häufigsten und zuverlässigsten Report-Einsender.

Fazit

Der Weg von p=none zu p=reject ist kein Sprint, sondern ein strukturierter Prozess: Reports lesen, alle Sender inventarisieren, Fehlkonfigurationen beheben, dann schrittweise mit pct= eskalieren. Die Gesamtdauer von typisch 9–18 Monaten schützt dich davor, legitime Mails zu blockieren. Mit einem kostenlosen Tool wie Postmark DMARC oder dem Self-Hosted parsedmarc-Stack hast du die Reports jederzeit im Blick. Wer als Bulk-Sender für Gmail und Yahoo relevant ist, kommt an p=reject ohnehin nicht mehr vorbei – seit November 2025 sind die Konsequenzen dauerhaft statt temporär.

Weiterführende Anleitungen und Quellen

1. SPF, DKIM und DMARC für Exchange Online einrichten – Grundlagen-Setup als Voraussetzung für diese Anleitung
2. OpenDKIM und Postfix: DKIM-Signatur einrichten – DKIM für selbst betriebene Mailserver
3. Mailcow Mailserver mit Docker aufsetzen – vollständiger Mailserver-Stack inkl. DMARC-Unterstützung
4. Reverse-DNS und PTR-Records für Mailserver einrichten – ergänzende Absender-Reputation

Quellen: parsedmarc offizielle Dokumentation · Google Workspace: Recommended DMARC rollout · DMARC Enforcement Timeline (dmarcreport.com) · Gmail Enforcement 2025: Google Begins Rejecting Emails (PowerDMARC) · Postmark Free DMARC Monitoring · DMARC pct-Tag Erklärung (MXToolbox)