DMARC-Report verstehen: So lesen Sie die kryptische XML und kommen sicher von p=none zu p=reject
Sie haben einen DMARC-Eintrag mit p=none veröffentlicht, und seitdem trudeln täglich E-Mails mit XML-Anhängen ein, von Google, Microsoft, Yahoo und einer Handvoll Anbieter, von denen Sie noch nie gehört haben. Die Dateien sind oft gepackt, ihr Inhalt sieht aus wie eine endlose Folge spitzer Klammern. Genau hier endet für viele Unternehmen der gute Vorsatz, DMARC sauber einzuführen: Der Report ist da, aber niemand kann ihn lesen.
Dieser Guide zeigt, wie Sie einen DMARC-Aggregate-Report tatsächlich auswerten. Sie lernen den Aufbau der XML kennen, verstehen SPF- und DKIM-Alignment ohne Fachjargon und gehen anhand der Report-Daten den sicheren Weg von p=none über quarantine bis zu p=reject. Wenn Sie zuerst die Grundlagen und Pflichten brauchen, hilft der Beitrag zur DMARC-Pflicht 2025 und 2026.
Worum es geht und warum die XML niemand liest
TL;DR: Ein DMARC-Aggregate-Report ist eine XML-Datei, die empfangende Anbieter täglich an Ihre RUA-Adresse schicken. Im Kopf steht Ihre veröffentlichte Richtlinie, danach folgen Datensätze pro sendender IP-Adresse mit den Ergebnissen von SPF und DKIM, jeweils inklusive Alignment. Werten Sie diese Berichte so lange aus, bis jede legitime Quelle sauber authentifiziert. Erst dann gehen Sie von
p=noneüberp=quarantinezup=reject. Eine Aggregation über alle Anbieter und über die Zeit macht den Übergang erst beherrschbar, denn nur rund 28,5 Prozent der Domänen erreichenp=reject.
Der DMARC-Eintrag ist schnell gesetzt, das Problem beginnt danach. Mit rua=mailto: haben Sie die empfangenden Anbieter um Berichte gebeten, und die kommen nun täglich, jeder Anbieter mit seiner eigenen Datei, oft gepackt als .gz oder .zip. Die Roh-XML ist für Software gedacht. Wer sie öffnet, sieht IP-Adressen statt Diensten und Felder, deren Bedeutung erst die DMARC-Spezifikation erklärt.
Die Folge ist fatal: Die Berichte werden ignoriert, die Richtlinie bleibt für immer auf p=none und schützt niemanden. p=none beobachtet nur. Erst p=quarantine und p=reject weisen empfangende Server an, gefälschte E-Mails in den Spam zu verschieben oder abzulehnen. Wer auf p=none stehen bleibt, hat zwar DMARC, aber keinen Schutz vor CEO-Fraud und Domain-Spoofing.
Der Aufbau eines DMARC-Aggregate-Reports
Ein Aggregate-Report hat immer denselben Grundaufbau. Wer ihn einmal verstanden hat, findet sich in jeder Anbieter-XML zurecht. Vier Bereiche sind entscheidend.
Header: Wer berichtet und über welchen Zeitraum
Im Kopf, dem Element report_metadata, steht der berichtende Anbieter, etwa google.com oder Microsoft, eine eindeutige Report-ID und der Berichtszeitraum. Dieser Zeitraum umfasst praktisch immer genau einen Tag. Das ist der erste Grund, warum ein einzelner Report wenig aussagt: Er zeigt nur einen Tag, nur aus Sicht eines Anbieters.
Policy published: Was der Anbieter von Ihrer Domäne gelesen hat
Das Element policy_published spiegelt Ihre Richtlinie so wider, wie der Anbieter sie im DNS gefunden hat: p für die Hauptrichtlinie, sp für Subdomänen, der Prozentsatz pct sowie die Alignment-Modi adkim und aspf. Steht hier etwas anderes als erwartet, ist Ihr DNS-Eintrag fehlerhaft oder veraltet zwischengespeichert.
Records: Ein Datensatz pro sendender Quelle
Den Kern bilden die record-Einträge. Jeder Datensatz steht für eine sendende IP-Adresse und enthält im Element row die Anzahl der Nachrichten (count) sowie das Feld policy_evaluated mit dem DMARC-Ergebnis, also pass oder fail. Genau hier lesen Sie ab, ob eine Quelle DMARC besteht.
Auth results: Warum SPF oder DKIM bestanden oder gescheitert sind
Innerhalb jedes Datensatzes liegt das Element auth_results. Es nennt für SPF und DKIM die geprüfte Domäne und das Ergebnis und erklärt damit das Warum hinter dem policy_evaluated. Scheitert eine Quelle, sehen Sie hier, ob SPF nicht passte, DKIM nicht passte oder beides.
| XML-Element | Was es enthält | Wofür Sie es brauchen |
|---|---|---|
report_metadata | Berichtender Anbieter, Report-ID, Zeitraum (meist ein Tag) | Einordnung: Wer berichtet, für wann |
policy_published | Ihre Richtlinie wie gelesen: p, sp, pct, adkim, aspf | Kontrolle, ob der DNS-Eintrag korrekt ankommt |
record mit row | Sendende IP, count, policy_evaluated | Erkennen, welche Quelle DMARC besteht oder scheitert |
auth_results | SPF- und DKIM-Domäne und -Ergebnis | Ursachenanalyse pro Quelle |
SPF- und DKIM-Alignment verständlich erklärt
Der häufigste Denkfehler lautet: SPF besteht, also ist alles in Ordnung. So einfach ist es nicht. DMARC verlangt zusätzlich, dass die dabei geprüfte Domäne zur sichtbaren Absenderdomäne im From-Header passt. Diese Übereinstimmung heißt Alignment.
Ein Bild dazu: SPF und DKIM prüfen, ob ein Brief von einem berechtigten Postamt stammt. Das Alignment prüft zusätzlich, ob der Absender auf dem Umschlag mit dem Absender im Briefkopf übereinstimmt. Erst wenn beides zusammenpasst, ist die Identität glaubwürdig.
- SPF-Alignment: SPF prüft die Domäne aus dem Return-Path, also dem technischen Umschlag-Absender. Für DMARC muss diese Domäne zur
From-Domäne ausgerichtet sein. Viele Dienstleister versenden gültig per SPF, nutzen aber ihre eigene Return-Path-Domäne. Dann besteht SPF, das SPF-Alignment scheitert jedoch. - DKIM-Alignment: DKIM prüft die kryptografische Signatur und die im
d-Tag genannte Domäne. Für DMARC muss diesed-Domäne zurFrom-Domäne ausgerichtet sein.
Entscheidend ist die DMARC-Logik: Es genügt, wenn eines der beiden Verfahren besteht und im Alignment passt. Deshalb ist DKIM oft der robustere Weg, denn eine DKIM-Signatur übersteht Weiterleitungen, bei denen SPF regelmäßig bricht. Ein fehlendes Alignment erkennen Sie daran, dass auth_results zwar ein pass für SPF zeigt, das policy_evaluated aber dennoch ein DMARC-fail ausweist. Genau diese Konstellation ist der wichtigste Hinweis darauf, dass ein legitimer Dienst noch nachjustiert werden muss, bevor Sie schärfer schalten.
Der sichere Weg von none über quarantine zu reject
Die Report-Daten sind kein Selbstzweck. Sie sind das Werkzeug, mit dem Sie die Richtlinie kontrolliert verschärfen. Der Weg führt in drei Stufen, und jede Stufe stützt sich auf das, was die Berichte zeigen.
Stufe 1, p=none, beobachten. Hier wird nichts blockiert. Sie sammeln Berichte und erstellen eine Bestandsaufnahme aller Quellen, die in Ihrem Namen senden: Microsoft-365-Postfach, Newsletter-Dienst, Rechnungs- oder Ticketsystem, CRM. Ziel ist eine vollständige Liste legitimer Quellen, bei denen jeweils SPF oder DKIM im Alignment besteht. Korrigieren Sie jede Quelle, die noch scheitert, etwa durch einen ergänzten SPF-Eintrag oder eine korrekt eingerichtete DKIM-Signatur beim Dienstleister.
Stufe 2, p=quarantine, vorsichtig durchsetzen. Erst wenn alle bekannten legitimen Quellen bestehen, schalten Sie auf quarantine. Gefälschte E-Mails landen nun im Spam-Ordner statt im Posteingang. Wer behutsam vorgehen will, beginnt mit einem reduzierten Prozentsatz über pct und steigert ihn schrittweise. Scheitert plötzlich eine legitime Quelle, fangen Sie das hier noch ab, bevor Schaden entsteht.
Stufe 3, p=reject, vollständig durchsetzen. Erst wenn über mehrere Wochen praktisch nur noch echte Fälschungen scheitern und kein legitimer Versand mehr fehlschlägt, stellen Sie auf reject um. Gefälschte Nachrichten werden jetzt direkt abgelehnt, der bestmögliche Schutz Ihrer Domäne gegen Spoofing und Phishing.
Wer diese Stufen überspringt und sofort auf reject geht, riskiert handfesten Schaden: Eigene Newsletter, Rechnungs-Mails oder CRM-Nachrichten können verworfen werden, ohne dass jemand es bemerkt. Die Report-Auswertung ist genau die Versicherung gegen diesen Fall.
Warum nur 28,5 Prozent p=reject erreichen
Trotz wachsender DMARC-Verbreitung erreicht nur etwa 28,5 Prozent der Domänen mit DMARC die durchsetzende Stufe p=reject. Der Großteil bleibt auf p=none hängen, also bei reiner Beobachtung ohne Schutzwirkung. Die Ursache ist selten technischer Unwille, sondern fast immer dieselbe: Die Roh-XML ist nicht beherrschbar.
Ohne Zusammenfassung bleibt unklar, welche Dienste noch nicht sauber authentifizieren. Eine sendende Quelle taucht über viele Tage in vielen Dateien verschiedener Anbieter auf, mal als nackte IP-Adresse, mal aus einem anderen Rechenzentrum desselben Dienstes. Niemand entpackt von Hand dutzende XML-Dateien pro Tag, schlägt IP-Adressen nach, führt identische Quellen zusammen und verfolgt über Wochen den Trend. Genau diese Arbeit verhindert den Schritt in die Durchsetzung.
Hier setzt Aggregation an. Sie entpackt und sammelt alle Berichte aller Anbieter, ordnet IP-Adressen den bekannten Diensten zu, fasst identische Quellen zusammen und zeigt über die Zeit, ob eine Quelle stabil im Alignment besteht. Damit wird die Frage beantwortbar, die über p=reject entscheidet: Welche legitimen Quellen brauchen noch eine SPF- oder DKIM-Korrektur, und welche sind bereits sauber?
Conbool DMARC: der Report als lesbare Aufbereitung
Genau diese Aggregation übernimmt Conbool DMARC. Statt täglich gepackte XML-Dateien zu öffnen, sehen Sie eine konsolidierte Übersicht aller Quellen, die in Ihrem Namen senden. Jede Quelle wird benannt statt als IP angezeigt, ihr SPF- und DKIM-Alignment sichtbar gemacht, und der Verlauf zeigt, ob eine Quelle bereit für die Durchsetzung ist. Den passenden DNS-Eintrag erstellen Sie geführt über den DMARC-Record-Generator.
| Aufgabe | Roh-XML von Hand | Conbool DMARC |
|---|---|---|
| Berichte entpacken und sammeln | Manuell pro Anbieter und Tag | Automatisch konsolidiert |
| IP-Adresse zuordnen | Selbst nachschlagen | Als benannter Dienst dargestellt |
| SPF- und DKIM-Alignment lesen | Felder selbst interpretieren | Pro Quelle aufbereitet |
Übergang none zu reject | Riskant, weil unübersichtlich | Datenbasiert und nachvollziehbar |
So wird aus der kryptischen XML eine Entscheidungsgrundlage. Die Report-Auswertung gehört in eine durchgängige E-Mail-Sicherheit: Während Conbool DMARC den Absender Ihrer eigenen Domäne absichert, prüft Conbool MailGuard eingehende Nachrichten auf Phishing, Spoofing und Malware. Erst zusammen entsteht ein belastbarer Schutz in beide Richtungen.
Häufig gestellte Fragen
Was steht in einem DMARC-Aggregate-Report?
Ein DMARC-Aggregate-Report ist eine XML-Datei, die ein empfangender Anbieter wie Google oder Microsoft einmal täglich an die in Ihrem DMARC-Eintrag hinterlegte RUA-Adresse schickt. Im Kopf stehen der berichtende Anbieter, der Berichtszeitraum und die veröffentlichte Richtlinie Ihrer Domäne, also p, sp, der Prozentsatz und die Alignment-Modi. Danach folgen aggregierte Datensätze, jeweils für eine sendende IP-Adresse, mit der Anzahl der Nachrichten und den Ergebnissen von SPF und DKIM. Der Report enthält keine Inhalte und keine Betreffzeilen, sondern nur Authentifizierungs-Statistiken pro Quelle.
Warum ist die DMARC-XML so schwer lesbar?
Die XML wurde für Maschinen entworfen, nicht für Menschen. Jeder Anbieter liefert eine eigene Datei, oft gepackt als .gz oder .zip, mit verschachtelten Feldern wie source_ip, policy_evaluated und auth_results. Eine einzelne Domäne erhält schnell dutzende Berichte pro Tag von vielen Anbietern, jeweils nur für einen Tag und nur für die jeweilige Quelle. Wer das von Hand liest, muss IP-Adressen nachschlagen, identische Quellen über viele Dateien zusammenfassen und die Felder selbst interpretieren. Erst eine Aggregation über alle Berichte und über die Zeit macht erkennbar, welche legitimen Dienste noch nicht sauber authentifiziert sind.
Wie komme ich sicher von p=none zu p=reject?
Der sichere Weg führt in drei Stufen und ausschließlich anhand der Report-Daten. Starten Sie mit p=none, das nur beobachtet und nichts blockiert. Werten Sie die Aggregate-Reports so lange aus, bis Sie jede legitime sendende Quelle kennen und für jede Quelle SPF oder DKIM im Alignment sauber passt. Schalten Sie dann auf p=quarantine, zunächst gegebenenfalls mit einem reduzierten Prozentsatz, und prüfen Sie weiter die Berichte. Erst wenn über mehrere Wochen praktisch nur noch echte Fälschungen scheitern und kein legitimer Versand mehr fehlschlägt, stellen Sie auf p=reject um. Wer diese Stufen überspringt, riskiert, dass eigene Newsletter, Rechnungstools oder CRM-Mails verworfen werden.
Was bedeuten SPF- und DKIM-Alignment im DMARC-Report?
DMARC verlangt mehr als ein bestandenes SPF oder DKIM. Es verlangt zusätzlich, dass die geprüfte Domäne zur sichtbaren Absenderdomäne im From-Header passt, das nennt man Alignment. Beim SPF-Alignment muss die Domäne aus dem Return-Path zur From-Domäne ausgerichtet sein, beim DKIM-Alignment die im d-Tag der Signatur genannte Domäne. DMARC besteht, sobald mindestens eines der beiden Verfahren bestanden ist und im Alignment passt. Im Report sehen Sie das in den auth_results und im Feld policy_evaluated. Ein häufiger Stolperstein sind Dienstleister, die zwar gültig per SPF zustellen, deren Return-Path-Domäne aber nicht zu Ihrer From-Domäne ausgerichtet ist, sodass DMARC trotz bestandenem SPF scheitert.
Wie hilft eine Aggregation der Reports beim Erreichen von p=reject?
Nur etwa 28,5 Prozent der Domänen mit DMARC erreichen die durchsetzende Stufe p=reject. Die Hauptursache ist die Unübersichtlichkeit der Roh-XML, denn ohne Zusammenfassung bleibt unklar, welche Dienste noch nicht sauber authentifizieren. Eine Aggregation entpackt und sammelt alle Berichte aller Anbieter, ordnet IP-Adressen den bekannten Diensten zu, fasst identische Quellen zusammen und zeigt über die Zeit, ob eine Quelle stabil im Alignment besteht. So wird sichtbar, welche legitimen Quellen vor dem Schritt auf quarantine und reject noch SPF- oder DKIM-Korrekturen brauchen, und der Übergang in die Durchsetzung wird kontrollierbar statt riskant.
Fazit
Ein DMARC-Report ist nur scheinbar kryptisch. Wer den Aufbau aus Header, veröffentlichter Richtlinie, Datensätzen pro Quelle und Auth-Results einmal verstanden hat und SPF- sowie DKIM-Alignment richtig liest, hält den Schlüssel in der Hand, um die eigene Domäne sicher von p=none über quarantine bis zu p=reject zu führen. Der einzige echte Engpass ist die schiere Menge an Roh-XML, und genau diesen Engpass löst eine saubere Aggregation.
Der nächste Schritt liegt bei Ihnen: Prüfen Sie Ihre Domäne mit dem kostenlosen Domain-Check und sehen Sie auf der Seite zu DMARC, wie Conbool DMARC Ihre Berichte in eine lesbare Aufbereitung verwandelt und den Weg zu p=reject datenbasiert begleitet.
Weiterführende Artikel:
