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

Sie haben SPF, DKIM und einen DMARC-Record mit p=none eingerichtet. Damit sammeln Sie Daten, schützen die Domain aber noch nicht vor Missbrauch. Die täglichen RUA-Aggregat-Reports zeigen, wer in Ihrem Namen E-Mails versendet und ob die Prüfungen bestehen. Wer sie auswertet und alle legitimen Sender korrigiert, verschärft den Record auf p=reject, ohne Rechnungen oder Newsletter zu blockieren. Seit November 2025 setzt Google die Absenderanforderungen für Bulk-Sender mit vorübergehenden und dauerhaften Ablehnungen durch.

Voraussetzungen

1. Veröffentlichter DMARC-Record mit p=none und gültiger rua=-Adresse (SPF und DKIM mindestens 48 Stunden vor DMARC aktiv)
2. Eigenes Postfach für RUA-Reports, z. B. dmarc@example.com, oder die Empfangsadresse eines SaaS-Dienstes
3. Zugang zur DNS-Verwaltung der Domain (TXT- und CNAME-Records)
4. Für parsedmarc: Linux-Server (Debian/Ubuntu) mit mindestens 3 GB RAM, Python 3.10 oder neuer, Elasticsearch und Kibana sowie IMAP-Zugang zum RUA-Postfach
5. Tabelle oder Dashboard für das Sender-Inventar (Quell-IP, Dienst, SPF/DKIM-Status, Maßnahme)
6. Optional: MaxMind-GeoLite2-Konto für Geo-IP-Daten in parsedmarc

Schritt 1: RUA-Reports empfangen und manuell lesen

Sobald der DMARC-Record mit gültiger rua=-Adresse veröffentlicht ist, treffen innerhalb von 24 bis 48 Stunden die ersten Reports ein, sofern Ihre Domain E-Mails an große Anbieter versendet.

Zeigt rua= auf eine fremde Domain, muss dort der TXT-Record example.com._report._dmarc.reporting-tool.com mit v=DMARC1 existieren (siehe Troubleshooting).

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

1. report_metadata: Absender, Report-ID, Zeitraum (Unix-Zeitstempel)
2. policy_published: der gültige DMARC-Record Ihrer Domain
3. record: Einträge je Quell-IP mit source_ip, count, Alignment-Ergebnissen und disposition

Zum manuellen Lesen entpacken und formatieren Sie die Datei:

# 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

Entscheidend sind je record 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 das DMARC-Alignment, also ob die geprüfte Domain zum From:-Header passt. DMARC ist bestanden, wenn SPF-Alignment oder DKIM-Alignment besteht.

Verifizieren: Öffnen Sie einen entpackten Report und suchen Sie den Block <policy_published>. Die Policy muss Ihrem aktuellen DNS-Record entsprechen. Prüfen Sie außerdem, ob Reports von Google, Microsoft und Yahoo eingehen.

# 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

Für den Dauerbetrieb nutzen Sie einen SaaS-Dienst oder parsedmarc.

Option A: Kostenlose SaaS-Dienste

Die Empfangsadresse des Dienstes tragen Sie als zusätzliche rua=-Adresse ein.

Option B: parsedmarc Self-Hosted

parsedmarc liest das RUA-Postfach per IMAP und schreibt die Daten nach Elasticsearch; Kibana zeigt sie als Dashboard. Seit Version 11 liegen die Ausgabe-Integrationen in optionalen Paketen (Extras): Für Elasticsearch installieren Sie parsedmarc[elastic] oder alles mit parsedmarc[all].

# 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 mit allen Ausgaben 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[all]"

Konfigurationsdatei /etc/parsedmarc.ini (Rechte 600, Eigentümer parsedmarc, da sie das IMAP-Passwort enthält):

[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-Unit unter /etc/systemd/system/parsedmarc.service anlegen:

[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

Dann aktivieren:

sudo systemctl daemon-reload
sudo systemctl enable --now parsedmarc

Verifizieren: Testen Sie parsedmarc einmal mit einer einzelnen Report-Datei und prüfen Sie den Dienst:

/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

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

Schritt 3: Legitime Sender inventarisieren

Tragen Sie je Quell-IP Dienst, Alignment-Ergebnis und Maßnahme ins Inventar ein.

Oft übersehene „Schatten-Sender“:

1. Newsletter-Plattformen (Mailchimp, Brevo, CleverReach)
2. ERP-Systeme (SAP, Microsoft Dynamics)
3. Multifunktionsdrucker über SMTP-Relay
4. Helpdesk- und CRM-Software
5. Externe Monitoring-Dienste

Welche Maßnahme zu welchem Report-Muster passt:

Alignment relaxed oder strict: Standard ist relaxed (aspf=r, adkim=r): bounce.newsletter.example.com passt zu From: example.com. Bei strict müssen die Domains exakt übereinstimmen. Meist ist relaxed richtig.

Verifizieren: Ihr Inventar enthält alle Quell-IPs der letzten 30 Tage, jede mit einer Kategorie: „legitim, DMARC pass“, „legitim, Korrektur nötig“ oder „unbekannt/nicht legitim“. Prüfen Sie außerdem, ob der SPF-Record das Limit von 10 DNS-Lookups einhält:

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

Schritt 4: Fehlkonfigurationen beheben

Bevor Sie die Policy verschärfen, bringen Sie alle legitimen Sender auf DMARC pass:

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 Ihrer 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: Bei mehr als 10 Lookups Dienste konsolidieren oder include:-Ketten in direkte IP-Bereiche auflösen (die Liste müssen Sie dann bei Änderungen des Anbieters nachpflegen)

Prüfen Sie nach jeder DNS-Änderung die Reports der folgenden 48 Stunden. Ziel: Pass-Rate über 95 % an 30 Tagen in Folge.

Weiterleitungen und Mailinglisten erscheinen als DMARC fail, sind aber legitim; die Lösung (ARC-Seal) liegt beim weiterleitenden Server.

Verifizieren: Prüfen Sie SPF, DKIM und die CNAME-Delegation:

# 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

Ist das Inventar vollständig und liegt die Pass-Rate über 95 %, beginnen Sie die Eskalation. Bleiben Sie mindestens 90 Tage bei p=none, damit auch monatliche und quartalsweise Sender (Abrechnungen, Mahnläufe) erfasst sind.

pct oder t: Früher wurde mit pct=10, pct=25 usw. nur ein Anteil der fehlschlagenden Nachrichten strenger behandelt. RFC 9989 (Mai 2026) ersetzt RFC 7489 und stuft pct als historisch ein, weil Empfänger Zwischenwerte uneinheitlich umsetzten. Stattdessen gibt es das Testkennzeichen t=y: Der Empfänger wendet dann eine Stufe milder an (p=quarantine; t=y wirkt wie none, p=reject; t=y wie quarantine). Empfänger ohne RFC-9989-Unterstützung ignorieren t und wenden die Policy voll an. Starten Sie die Testphase deshalb erst, wenn die Pass-Rate stimmt.

Die DNS-Records je Phase:

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

# Phase 2a - Quarantine im Testmodus:
v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com

# Phase 2b - Quarantine:
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

# Phase 3a - Reject im Testmodus:
v=DMARC1; p=reject; t=y; rua=mailto:dmarc@example.com

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

Subdomains: Ohne sp=-Tag erben Subdomains die Policy der Hauptdomain. Abweichend setzen Sie sp=quarantine oder sp=none.

Nach p=reject geht das Monitoring weiter; neue Dienste kommen vor dem Start ins Inventar. Grundkonfiguration: SPF, DKIM und DMARC für Exchange Online einrichten.

Verifizieren: Prüfen Sie nach jeder Policy-Änderung, ob der neue Record im DNS sichtbar ist, und beobachten Sie die Reports der nächsten zwei bis drei Tage auf unerwartete Fehlschläge:

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

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

Troubleshooting / Typische Fehler

1. pct-Stufen wirken nicht wie erwartet: Viele Empfänger setzen Zwischenwerte von pct ungenau um; RFC 9989 führt den Tag nur noch als historisch. Nutzen Sie t=y für die Testphase und entfernen Sie pct aus bestehenden Records.
2. SPF PermError im Report (<result>permerror</result>): Das Limit von 10 DNS-Lookups ist überschritten, meist durch viele include:-Einträge (Google Workspace, Mailchimp, Salesforce). Lösung: konsolidieren oder SPF-Flattening.
3. Weiterleitungen erscheinen als DMARC fail: Normal (geänderter Return-Path, gebrochene DKIM-Signatur), siehe Schritt 4.
4. RUA-Adresse auf externer Domain, Reports bleiben aus: Auf der Ziel-Domain fehlt der Zustimmungs-Record example.com._report._dmarc.reporting-tool.com mit v=DMARC1.
5. DKIM-Signatur nach Schlüsselwechsel ungültig: Lassen Sie den alten Selektor-Record mindestens 48 Stunden nach dem Wechsel im DNS stehen.
6. parsedmarc meldet „ConnectionError: Unable to connect to Elasticsearch“: Elasticsearch läuft nicht, prüfen Sie systemctl status elasticsearch. Meldet parsedmarc ein fehlendes Extra, installieren Sie parsedmarc[all] nach.
7. Drucker erscheinen nicht mit der erwarteten IP: Im Report steht das SMTP-Relay; nehmen Sie es in SPF auf oder signieren Sie dort per DKIM.
8. Nach p=reject kommen weniger Reports: Die Menge hängt vom Versandvolumen ab. Abgelehnte Nachrichten werden weiterhin mit disposition reject gemeldet. Bleiben Reports ganz aus, prüfen Sie rua=-Adresse und Postfach.

Häufige Fragen

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

Nein. Google und Yahoo verlangen seit Februar 2024 von Bulk-Sendern (mehr als 5.000 Nachrichten pro Tag an Gmail-Konten) einen gültigen DMARC-Record, p=none genügt formal. Seit November 2025 lehnt Gmail nicht konforme Nachrichten vorübergehend oder dauerhaft ab. p=reject ist der empfohlene Endzustand, weil nur er gegen Spoofing schützt.

Was ist der Unterschied zwischen RUA und RUF?

RUA (Aggregate Reports) sind tägliche Zusammenfassungen ohne Nachrichteninhalte. RUF (Failure Reports) beschreiben einzelne fehlgeschlagene Nachrichten mit Headern und teils Inhalten; beachten Sie den Datenschutz. Gmail und viele andere senden keine RUF-Reports. Für die Eskalation reichen RUA-Reports.

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

Mit t=y (oder einem alten pct unter 100) wendet der Empfänger bei p=quarantine nur none an. Außerdem dürfen Empfänger nach eigener Richtlinie abweichen (local policy override), etwa bei erkannten Weiterleitungen.

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

Zwei Wege: (1) SMTP-Server des Anbieters in SPF aufnehmen und eine Custom Bounce-Domain unter example.com setzen. (2) DKIM-Signatur mit einem example.com-Schlüssel per CNAME-Delegation des Selektors. Weg 2 ist robuster und belastet das SPF-Lookup-Limit nicht.

Kann ich parsedmarc ohne Elasticsearch betreiben?

Ja. parsedmarc exportiert JSON oder CSV und schreibt alternativ nach Splunk (HEC), S3, Syslog, GELF oder an Webhooks. Elasticsearch lohnt sich erst bei mehreren Domains oder hohem Mailvolumen.

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

In der Regel 24 bis 48 Stunden nach Veröffentlichung des Records, sofern Ihre Domain in dieser Zeit E-Mails an große Anbieter versendet.

Fazit

Der Weg von p=none zu p=reject ist ein strukturierter Prozess: Reports lesen, Sender inventarisieren, Fehlkonfigurationen beheben, dann mit t=y als Zwischenstufe verschärfen. Allein die Monitoring-Phase dauert mindestens 90 Tage. Stellen Sie bestehende Records mit pct bei der nächsten Änderung auf t um.

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: RFC 9989: DMARC (IETF, Mai 2026) · parsedmarc offizielle Dokumentation · Google Workspace: Recommended DMARC rollout · Google: FAQ zu den Richtlinien für E-Mail-Absender · Postmark Free DMARC Monitoring