So lesen Sie einen DMARC-Aggregatbericht: eine Schritt-für-Schritt-Anleitung

Ihr DMARC-Eintrag enthält ein rua=-Tag, und jeden Tag senden Mailbox-Anbieter Ihnen eine XML-Datei. Hier erfahren Sie, was tatsächlich darin steht und wie Sie sie ohne Kopfschmerzen lesen können.

Behalten Sie diese Tabelle griffbereit. Im Folgenden wird erläutert, warum jede Zeile wichtig ist und wie Sie sie in einer echten Datei lesen können.

DMARC-Aggregatberichte sind der einzige Teil des DMARC-Systems, der speziell für den Menschen lesbar sein soll, und dennoch sind sie in XML geschrieben. Das ist der Widerspruch. Red Sift OnDMARC verwandelt das in Dashboards, sodass Sie nie rohes XML von Hand ansehen müssen. Aber das Verständnis dafür, was diese Dashboards zusammenfassen, macht jede Entscheidung zur DMARC-Richtlinie schneller und fundierter. Diese Anleitung geht Feld für Feld einen echten Bericht durch und zeigt Ihnen, wie Sie zwischen Rotationen Ihres E-Mail-Providers und echten Spoofing-Versuchen unterscheiden können.

Dies ist keine Wiederholung darüber, was ein Aggregatbericht ist oder warum Ihr rua=-Postfach leer sein könnte. Falls Sie dieses Vorwissen benötigen, behandelt unser Leitfaden zu den Grundlagen des DMARC-Aggregatreportings diese Punkte. Diese Anleitung setzt an dem Moment an, in dem die Datei in Ihrem Postfach ankommt, und zeigt, was Sie dann tun können.

Am Ende werden Sie in der Lage sein:

• Einen Bericht zu öffnen und jeden Bereich ohne Spickzettel zu identifizieren
• Den Unterschied zwischen DMARCs Pass/Fail-Ergebnis und dem Rohresultat von SPF/DKIM darunter zu erkennen
• Die Dispositions-Spalte zu lesen und genau nachzuvollziehen, was mit dieser Mail geschehen ist
• Die vier geläufigsten Muster in realen Berichten zu erkennen – inklusive Weiterleitung, ESP-Rotation und tatsächlichem Spoofing
• Zu verstehen, was sich im Berichtsformat mit dem DMARC-Update 2026 geändert hat

Jeder DMARC-Aggregatbericht ist ein einzelnes XML-Dokument mit dem Root-Element feedback. Darin befinden sich drei Blöcke mit allen benötigten Informationen [1].

• report_meta identifiziert Absender und Zeitraum des Berichts. Enthalten sind der Name der berichtenden Organisation, eine Kontakt-E-Mail, eine eindeutige Berichts-ID sowie ein date_range, das das Zeitfenster in Sekunden seit der Unix-Epoche angibt. Die meisten Empfänger berichten über ein rollierendes 24-Stunden-Fenster.
• policy_published zeigt, wie der Empfänger Ihren DMARC-Eintrag zum Zeitpunkt der Auswertung Ihrer Mail gelesen hat. Das ist wichtiger, als es klingt. Wenn Sie Ihre Richtlinie von p=none auf p=quarantine im Laufe eines Tages geändert haben, könnten verschiedene Berichte für denselben Tag unterschiedliche Werte enthalten, weil DNS-Propagation und Caching verhindern, dass alle Empfänger die Änderung gleichzeitig sehen [1].
• record ist der eigentliche Datenträger. Es gibt je einen record-Block pro Kombination aus sendender IP, Auswertungsergebnis und Authentifizierungskennzeichen, sodass die gleiche IP legitim in mehreren records erscheinen kann, selbst bei identischer Disposition. Ein Bericht kann je nach E-Mail-Volumen von einem bis mehreren tausend records enthalten. Jeder record gliedert sich in drei Teile: row (IP, Anzahl, Ergebnis), identifiers (die Domains, die DMARC geprüft hat) und auth_results (die Roh-Ergebnisse von SPF und DKIM vor der DMARC-Alignment-Logik).

Wenn Sie diese drei Blöcke beim Lesen erkennen, müssen Sie nie mehr eine gesamte Datei von Grund auf entschlüsseln – Sie finden gezielt die gewünschte Stelle.

So sieht ein einzelner record, basierend auf dem Format von RFC 9990 [1], nach dem Entpacken aus. Die meisten Empfänger komprimieren die Datei (Gmail sendet .zip, andere .xml.gz), deshalb ist der erste Schritt immer das Entpacken.

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>16215678901234567890</report_id>
    <date_range>
      <begin>1754784000</begin>
      <end>1754870399</end>
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>redsift.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>quarantine</p>
    <sp>none</sp>
  </policy_published>

  <record>
    <row>
      <source_ip>203.0.113.42</source_ip>
      <count>842</count>
      <policy_evaluated>
        <disposition>pass</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>redsift.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>redsift.com</domain>
        <result>pass</result>
        <selector>google</selector>
      </dkim>
      <spf>
        <domain>redsift.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Das bedeuten die jeweiligen Zeilen:

• org_name und date_range: Google hat diesen Bericht erstellt – für ein 24-Stunden-Fenster. Alles darunter betrifft also nicht den heutigen Tag, sondern diesen Zeitraum.
• policy_published: Google hat redsift.coms DMARC-Datensatz mit relaxed alignment (r) für DKIM und SPF gelesen; Richtlinie war quarantine. Es handelt sich hierbei um die tatsächlich angewandte Richtlinie, nicht unbedingt um den aktuellen DNS-Wert.
• source_ip: Von dieser einen IP kamen 842 Nachrichten in diesem Fenster. Das ist eine aggregierte Zahl, keine 842 einzelnen Logeinträge.
• disposition: pass bedeutet, dass die Nachricht nach Auswertung die DMARC-Prüfung unter dieser aktiven Richtlinie bestanden hat. Disposition gibt hier das gemeldete DMARC-Ergebnis an, nicht unbedingt, wie der Provider die Nachricht schlussendlich behandelt hat.
• dkim und spf innerhalb policy_evaluated: Beide zeigen pass, also wurde die Nachricht auch nach DMARC-Regeln abgeglichen, nicht nur nach dem Rohprotokollergebnis.
• auth_results: Das ist das rohe, ursprüngliche Ergebnis. DKIM war mit dem google-Selector gültig, auch SPF wurde bestanden. Hier stimmen Roh- und DMARC-Resultat überein – das ist nicht immer so.

Gerade dieser Punkt wird bei der ersten Lektüre oft übersehen und verdient einen eigenen Abschnitt. Vorher aber noch ein Wort zum identifiers-Block – er entscheidet, welcher Domain alles zugeschrieben oder angelastet wird.

Das Element identifiers enthält bis zu drei Felder und wird leicht übersehen, weil keines davon ein pass/fail-Ergebnis trägt. Gerade deshalb ist es so wichtig. Hier steht, gegen welche Domains DMARC tatsächlich geprüft hat – alle weiteren Ergebnisse des records werden an diesen Feldern gespiegelt.

• header_form ist die Domain aus der sichtbaren From-Adresse, die der Empfänger im Posteingang sieht. Sie ist immer erforderlich und Anker der DMARC-Logik: Jeder Alignment-Check in policy_evaluated prüft, ob die Domain, die SPF oder DKIM bestanden hat, zu dieser passt.
• envelope_form ist die Domain aus dem SMTP-Befehl MAIL FROM, auch Bounce- oder Return-Path-Domain genannt. Sie ist für Empfänger unsichtbar, aber SPF gleicht daran ab. Wenn ein Marketingtool in Ihrem Namen sendet, steht hier oft die Infrastruktur-Domain des Anbieters – darum schlägt SPF-Alignment fehl, sofern Sie keinen eigenen Return-Path konfiguriert haben.
• envelope_to ist optional und zeigt die Empfängerdomain – vor allem nützlich, wenn Sie analysieren, ob fehlgeschlagene Nachrichten zu einem bestimmten Provider gehen oder breit gestreut sind.

Das Entscheidende: Wenn header_from redsift.com zeigt, envelope_from aber bounce.some-esp.com, wird SPF gegen die Domain des ESP geprüft, nicht Ihre eigene. Der rohe SPF-Check kann für die ESP-Domain problemlos bestehen – und DMARC scheitert trotzdem, da das Alignment envelope_from gegen header_from vergleicht. Sie stimmen nur überein, wenn das ESP über eine delegierte Subdomain versendet. Diese Beziehung ist für die meisten „Warum ist das fehlgeschlagen?“-Tickets entscheidend.

Jeder record enthält getrennte Bewertungen für DKIM und SPF – sie beantworten unterschiedliche Fragen.

• auth_results antwortet: „Hat der rohe SPF- oder DKIM-Check bestanden?“ Dies ist das Protokoll-Resultat, geprüft gegen die in der Signatur oder im SPF-Eintrag benannte Domain.
• policy_evaluated antwortet: „Hat dieses Ergebnis für DMARC gezählt?“ Das ist das Alignment-Ergebnis – es entscheidet über die Disposition.

Der Unterschied ist das Alignment. DMARC fragt nicht nur, ob SPF oder DKIM bestanden hat, sondern ob die Domain, die bestanden hat, zur sichtbaren From-Domain passt, entweder exakt (striktes Alignment, adkim=s oder aspf=s) oder auf Organisationsebene (relaxed Alignment – Standard für die meisten Sender) [2]. Eine Nachricht kann SPF für bounce.thirdpartyesp.com bestehen und trotzdem bei DMARC scheitern, weil bounce.thirdpartyesp.com nicht zu redsift.com im From-Header passt.

Deshalb zeigt auth_results manchmal pass, während policy_evaluated für denselben record fail anzeigt. Diese Lücke ist fast immer die Antwort, wenn Mails eines legitimen Absenders trotz „bestanden“ im Anbieter-Dashboard in Quarantäne landen. Der Anbieter zeigt das rohe SPF- oder DKIM-Ergebnis. DMARC achtet auf Alignment.

Das Feld disposition zeigt, was tatsächlich mit der Mail passiert ist – es gibt vier Werte [1]:

Eines fällt fast jedem irgendwann auf: Ist Ihre Richtlinie p=none, zeigen fast alle records disposition: none – selbst dann, wenn sowohl DKIM als auch SPF fehlgeschlagen sind. Das ist meist so gewollt, allerdings kann ein Empfänger trotzdem lokale Richtlinien oder Overrides anwenden – darauf verweist das reason-Element (siehe unten). Mit p=none bitten Sie die Empfänger nur um einen Bericht, nicht um tatsächliche Durchsetzung. Der Bericht macht, was er soll: Es wurde nichts blockiert, weil Sie es auch nicht verlangt haben.

Wenn Sie eine Disposition sehen, die nicht Ihrer veröffentlichten Richtlinie entspricht, suchen Sie nach einem reason-Element in policy_evaluated. RFC 9990 nennt fünf Override-Typen, die ein Empfänger berichten kann: local_policy, mailing_list, trusted_forwarder, policy_test_mode und other [1]. Ein Wert mailing_list bei einem fehlgeschlagenen record bedeutet meist: Der Empfänger sieht das als Spezialfall einer Mailingliste. Typischerweise passiert das, wenn ein Server die Nachricht weiterleitet und dabei SPF bricht und die DKIM-Signatur entfernt oder verändert. Der Wert allein garantiert keine bestimmte Fehlerabfolge, aber in jedem Fall ist das für weitergeleitete Mails normal und kein Grund für Alarm.

Einzelne records nützen wenig. Der Wert von Aggregatberichten liegt darin, viele records desselben Absenders über mehrere Tage zu vergleichen. Vier Muster tauchen immer wieder auf – sie auseinanderzuhalten erspart Ihnen, ein echtes Problem zu ignorieren oder ein Scheinproblem zu verfolgen.

1. Ein legitimer Absender, den Sie noch nicht autorisiert haben. Eine neue source_ip taucht auf, auth_results meldet SPF und DKIM fail, die Anzahl ist Tag für Tag konstant. Meist handelt es sich um eine Marketingplattform, ein CRM- oder Helpdesksystem, das jemand im Unternehmen ohne IT-Rücksprache eingebunden hat. Die Lösung: in SPF eintragen und DKIM-Signatur einrichten, nicht blockieren.

2. Rotation von IPs bei ESP oder Cloud-Anbietern. Ein Absender ist seit Monaten autorisiert, plötzlich erscheinen neue IPs, die SPF failen, während DKIM weiter besteht. Große Versender rotieren regelmäßig ihre Infrastruktur. DKIM reist aber unabhängig von der IP mit der Nachricht – daher bleibt DKIM-Alignment intakt, SPF bricht. In solchen Fällen ist Rotation wahrscheinlicher als Spoofing. Rückfrage beim ESP klärt meist alles.

3. Mailinglisten und Weiterleiter. SPF und DKIM scheitern, das reason-Element gibt mailing_list an oder einzelne records sind verstreut über viele IPs. header_from zeigt weiterhin Ihre Domain. Hier handelt es sich meist um weitergeleitete oder über Listen verteilte Nachrichten. Dieses Verhalten ist bei DMARC einkalkuliert (RFC 9989, indirekter Mailflow [2]).

4. Tatsächliches Spoofing. SPF und DKIM scheitern beide, die Quell-IP gehört zu keiner bekannten Infrastruktur, kein reason-Override, es tritt einmalig oder wiederholt ohne interne Ursache auf. Jetzt muss gehandelt werden: Sicherstellen, dass Ihre Richtlinie stark genug für Quarantäne/Ablehnung ist – bei hohem Volumen als Phishing-Kampagne einstufen.

Solche Prüfungen von Hand über tausende records und Quellen hinweg lassen sich kaum skalieren – genau deshalb gibt es DMARC-Reporting-Plattformen wie Red Sift OnDMARC: Sie erkennen diese vier Muster automatisch, damit Sie nicht jeden Morgen XML „zu Fuß“ prüfen müssen.

Im Mai 2026 hat die IETF die ursprüngliche DMARC-Spezifikation RFC 7489 durch drei neue Standards-Track-Dokumente ersetzt: RFC 9989 regelt das Kernprotokoll, RFC 9990 das Aggregat-Reporting und RFC 9991 das Failure-Reporting [1, 2]. Für bestehende Aggregate-Report-Auswerter bleibt das Format grundsätzlich kompatibel. RFC 9990 fordert explizit, dass nicht unterstützte Erweiterungsdaten toleriert werden müssen [1]. Aber: Namespace und Schema haben sich geändert, semantisch gibt es wichtige Unterschiede wie disposition pass – ein reiner RFC-7489-Parser akzeptiert nicht zwingend einen RFC-9990-Report.

Einige Neuerungen, die Sie kennen sollten:

• discover_method kann jetzt im policy_published-Block stehen – mit psl (Public Suffix List, Legacy) oder treewalk (neue DNS-basierte Methode zur Erkennung Ihrer Organizational Domain) [1].
• Selector sind jetzt Pflicht, wann immer eine DKIM-Signatur im auth_results-Block vorkommt. Früher haben manche Empfänger das selector-Feld ausgelassen.
• Ein generator-Feld kann im report_metadata stehen: Es nennt die konkret erzeugende Software, praktisch zum Debugging bei falsch formatierten Reports.

Im Alltag ändert sich beim Lesen wenig. Die meisten Parser und Dashboards funktionieren weiter, da RFC 9990 fordert, unbekannte Felder zu ignorieren statt Berichte abzulehnen [1]. Das ist keine Standardregel für XML, sondern eine bewusste Entscheidung des RFC für die Handhabung seiner Erweiterungen. Dieses Wissen hilft beim Prüfen des eigenen Parsers oder beim Vendor-Vergleich – und zeigt: DMARC-Reporting entwickelt sich aktiv weiter. Die größte strukturelle Änderung: Aggregat-Reporting hat jetzt eine eigene, vom Kernprotokoll abgekoppelte Spezifikation und kann unabhängig weiterentwickelt werden. Die vollständigen Änderungen inkl. Auswirkungen auf Ihren DNS-Eintrag finden Sie in unserem Überblick zum RFC-9989-Update.

Eine einzelne mittlere Domain kann täglich Berichte von 15 bis 30 Postfachanbietern erhalten – jeder mit eigener Datei, eigenem Komprimierungsformat und Eigenheiten bei optionalen Feldern. Das ist nicht dafür gedacht, dass Menschen sie jeden Tag von Hand öffnen und durchsuchen, sondern für automatisierte Auswertung und aggregierte Darstellung.

Googles Massenversand-Anforderungen, gültig seit Februar 2024, verlangen von jedem Domaininhaber, der 5.000 oder mehr Nachrichten pro Tag an Gmail-Adressen sendet, SPF & DKIM zu implementieren und mindestens eine DMARC-Richtlinie p=none zu veröffentlichen [3]. Dadurch haben viele Domains erstmals DMARC aktiviert – und stehen dann vor dem Problem: Die Reports sind korrekt und vollständig, aber bei echtem Volumen unlesbar ohne Tools.

Genau diese Lücke schließt Red Sift OnDMARC: Jede Datei wird automatisch verarbeitet, records werden nach Sendungsquelle statt nach Datei gruppiert, neue/unautorisierte Absender am ersten Tag markiert, und Sie sehen die Erfolgsrate pro Quelle auf einen Blick. So entscheiden Sie, wann Sie Ihre Policy von p=none zu p=quarantine oder p=reject verschärfen können. Wenn Sie noch in der Einführungsphase stehen, führt unser Leitfaden zur DMARC-Implementierung Sie Schritt für Schritt von den ersten Berichten bis zur vollständigen Durchsetzung.

Nur eine Datei statt Muster betrachten. Ein Tagesbericht gibt einen 24-Stunden-Status wieder. Versandinfrastruktur ändert sich, Volumen schwankt, einmalige Fehler passieren. Beurteilen Sie dieselbe Quelle mindestens eine Woche, bevor Sie Schlüsse ziehen.

auth_results mit DMARC-Bewertung verwechseln. Wie oben gezeigt, können sie sich unterscheiden. Wenn Sie sich fragen: „Warum ist im eigenen System alles grün, aber DMARC fehlt trotzdem?“ – Alignment ist fast immer der Grund.

Disposition:none bedeutet nicht, dass alles bestanden hat. Mit p=none heißt das nur: Es wurde nichts blockiert, nicht: alles ist bestanden. Prüfen Sie dkim und spf in policy_evaluated direkt.

Das Count-Feld ignorieren. Ein Eintrags-Fail von einer unbekannten IP ist Rauschen. Aber ein Fehlermuster mit hunderten Nachrichten pro Tag über Wochen ist ein Absender, den Sie autorisieren oder blockieren sollten.

Jede Fehlermeldung als Angriff einstufen. Die meisten Fehler in einer typischen Inbox sind Weiterleitungen, Mailinglisten oder benötigen einen SPF-Update beim Anbieter, nicht Spoofing. Handeln Sie erst bei Mustern ohne interne Erklärung und ohne reason-Override.

Den identifiers-Block überspringen. Weil er keinen pass/fail-Wert enthält, wird policy_evaluated oft direkt gelesen. Aber ohne Überprüfung von header_from gegen envelope_from bleibt die Ursache für Alignment-Fehlschläge ungeklärt.

Ein DMARC-Aggregatbericht besteht aus drei XML-Blöcken und einigen wiederholten Feldern für jede sendende Quelle. Wenn Sie report_metadata, policy_published und record auf einen Blick erkennen und wissen, dass das eigentliche DMARC-Ergebnis in policy_evaluated und nicht in auth_results steht, verliert die Datei ihren Schrecken. Die eigentliche Herausforderung ist, das bei Dutzenden Providern und tausenden records am Tag im Griff zu behalten.

Das lohnt sich zu automatisieren. Red Sift OnDMARC verarbeitet jeden Bericht direkt nach Empfang, kennzeichnet neue und nicht autorisierte Absender automatisch und zeigt Ihnen die Erfolgsrate je Quelle an – so ist die Entscheidung zur Policy-Verschärfung eine Bildschirmansicht, kein Excel-Projekt.

[1] RFC 9990 - Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting

[2] RFC 9989 - Domain-Based Message Authentication, Reporting, and Conformance (DMARC)

[3] FAQ zu Absender-Richtlinien – Gmail-Hilfe