DMARC-Berichte lesen: XML-Report erklärt

Q: Kann ich den Empfang von Berichten beenden?

Entfernen Sie das `rua=`-Tag, und die Empfänger stellen den Versand innerhalb eines Tages ein. Sie verlieren damit jede Sicht auf Spoofing und Fehlkonfigurationen, `rua=` auf einen Analyzer zu richten ist daher die bessere Wahl.

Aggregierte DMARC-Berichte wirken abschreckend, haben aber nur drei Abschnitte. Dieser Leitfaden geht einen echten RFC-9990-Bericht Feld für Feld durch, zeigt die sieben Zeilenmuster aus der Praxis und sagt, was bei jedem zu tun ist.

Um einen DMARC-Bericht zu lesen, öffnen Sie den komprimierten XML-Anhang, prüfen unter policy_published, welche Richtlinie die Empfänger angewendet haben, und gehen dann jeden record-Block durch: source_ip und count zeigen, wer wie viel gesendet hat, policy_evaluated liefert das DMARC-Urteil, und auth_results zeigt die rohen SPF- und DKIM-Ergebnisse darunter. Eine Zeile, die SPF oder DKIM besteht, aber bei DMARC durchfällt, hat ein Alignment-Problem. Eine Zeile, die überall durchfällt, ist entweder ein vergessener Absender oder jemand, der Ihre Domain fälscht. Dieser Leitfaden geht einen echten Bericht Feld für Feld durch, zeigt die sieben häufigsten Muster und erklärt, was bei jedem zu tun ist.

Was ein DMARC-Bericht eigentlich ist

Jeder Mailempfänger mit DMARC-Unterstützung (Google, Microsoft 365, Yahoo, Mail.ru, Fastmail, Zoho und viele weitere) zählt die Nachrichten, die im From-Header Ihre Domain beanspruchen. Einmal pro UTC-Tag packt er diese Zählungen in eine XML-Datei, komprimiert sie und mailt sie an die Adresse im rua=-Tag Ihres DMARC-Eintrags. Das sind aggregierte Berichte, auch RUA-Berichte genannt. Sie enthalten keinen Nachrichteninhalt, nur Zählungen pro sendender IP mit den jeweiligen Authentifizierungsergebnissen.

Laut RFC 9990, im Mai 2026 von der IETF als Standards-Track-Spezifikation für aggregierte Berichte veröffentlicht, umfasst der Berichtszeitraum üblicherweise einen einzelnen UTC-Tag ab 0000 UTC, das XML muss im Normalfall gzip-komprimiert sein, und jeder Bericht deckt genau eine Richtliniendomain ab. Berichte kommen unabhängig davon, ob Ihre Richtlinie p=none, p=quarantine oder p=reject lautet. Sie sind die einzige Rückmeldung, die DMARC Ihnen gibt, und sie zu lesen ist der Unterschied zwischen sicherer Durchsetzung und dem Blockieren der eigenen Rechnungen.

Balkendiagramm des DMARC-Reifegrads der 1,8 Millionen wichtigsten Domains im März 2026: 937.931 mit DMARC-Eintrag, rund 553.000 mit aggregierten Berichten, 411.935 mit Durchsetzung

Von den 1,8 Millionen Top-Domains veröffentlichen 937.931 (52,1 %) DMARC, über 553.000 sammeln aggregierte Berichte und 411.935 setzen die Richtlinie durch. Nur rund 9 % tun beides. Quelle: EasyDMARC, 2026 DMARC Adoption Report, 30. März 2026.

Die Lücke in diesem Diagramm ist das Problem, das dieser Artikel löst. Die EasyDMARC-Studie vom März 2026 über die 1,8 Millionen wichtigsten Domains ergab, dass nur etwa 9 % eine Durchsetzungsrichtlinie mit Berichten kombinieren. Ein separater DMARCguard-Scan von 5.499.028 Tranco-Domains am 27. Februar 2026 ergab, dass 776.918 der 1.670.975 DMARC-Domains (46,5 %) gar kein rua=-Tag haben. Die meisten Domaininhaber, die Berichte bekommen, öffnen sie nie, weil rohes XML abschreckend wirkt. Ist es nicht. Es gibt nur drei Abschnitte.

Schritt 1: den Anhang öffnen

Eine echte Berichtsmail hat einen Betreff wie Report Domain: example.com Submitter: google.com Report-ID: 1234567890 und genau einen Anhang. RFC 9990 Abschnitt 3.5.2 legt das Dateinamensformat als empfaenger!richtliniendomain!startzeit!endzeit.xml.gz fest, zum Beispiel google.com!example.com!1757462400!1757548799.xml.gz. Die beiden Zahlen sind Unix-Zeitstempel für Anfang und Ende des Berichtsfensters, Sie erkennen den abgedeckten Tag also, bevor Sie irgendetwas öffnen.

Entpacken Sie die Datei auf der Kommandozeile:

gunzip google.com!example.com!1757462400!1757548799.xml.gz

Manche Absender, darunter Microsoft, verwenden zip statt gzip. Nutzen Sie dann unzip für die Datei. Um das Ergebnis lesbar zu formatieren:

xmllint --format google.com!example.com!1757462400!1757548799.xml

Jeder Texteditor funktioniert ebenfalls. Sie sehen ein einzelnes feedback-Element, das report_metadata, policy_published und einen oder mehrere record-Blöcke enthält.

Schritt 2: die drei Abschnitte lesen

Hier ein auf einen Datensatz gekürzter Bericht mit der Struktur aus RFC 9990 Anhang B:

<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
  <version>1.0</version>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>1757548799.example.com</report_id>
    <date_range>
      <begin>1757462400</begin>
      <end>1757548799</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>quarantine</p>
    <sp>none</sp>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.123</source_ip>
      <count>123</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <envelope_from>example.com</envelope_from>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
        <selector>abc123</selector>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>fail</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Ältere Berichte verwenden den Namensraum http://dmarc.org/dmarc-xml/0.1 aus RFC 7489. Die Felder sind dieselben, Sie lesen sie also genauso.

Element	Was es Ihnen sagt	Wie Sie es nutzen
`report_metadata` / `org_name`	Welcher Empfänger den Bericht erzeugt hat	Befunde pro Empfänger gruppieren; Google und Microsoft decken zusammen meist den Großteil Ihres Volumens ab
`date_range`	Unix-Zeitstempel des abgedeckten Fensters	Spitzen mit Kampagnen oder Vorfällen an diesem Tag abgleichen
`policy_published`	Ihr DMARC-Eintrag, so wie der Empfänger ihn gelesen hat	Weicht `p` von Ihrer Veröffentlichung ab, war DNS noch nicht propagiert oder Sie haben zwei Einträge
`source_ip`	Die IP, die die Nachricht beim Empfänger abgeliefert hat	Reverse-Lookup durchführen; das ist Ihr Absenderinventar
`count`	Nachrichten von dieser IP mit identischen Ergebnissen	Große Zahlen sind Ihre echten Mailströme; winzige Zahlen sind Rauschen oder Sondierungen
`policy_evaluated` / `dkim` und `spf`	Ausgerichtete DKIM- und SPF-Ergebnisse	Das ist das DMARC-Urteil nach dem Alignment, nicht die Rohprüfung
`disposition`	Was der Empfänger getan hat: `none`, `quarantine`, `reject` oder `pass` in RFC-9990-Berichten	Sagt Ihnen, was mit der Mail tatsächlich passiert ist
`reason`	Warum ein Empfänger Ihre Richtlinie übersteuert hat	`mailing_list`, `trusted_forwarder`, `local_policy`, `policy_test_mode` oder `other`
`header_from`	Die Domain im sichtbaren From-Header	Die Domain, die DMARC in dieser Zeile schützt
`envelope_from`	Die RFC5321.MailFrom-Domain, die SPF geprüft hat	Weicht sie von `header_from` ab, kann SPF nicht ausgerichtet sein
`auth_results` / `dkim`	Rohes DKIM-Ergebnis, Signaturdomain und Selektor	Pass hier und Fail in `policy_evaluated` heißt, die `d=`-Domain ist nicht Ihre
`auth_results` / `spf`	Rohes SPF-Ergebnis und geprüfte Domain	Pass hier und Fail oben heißt, die Envelope-Domain ist nicht ausgerichtet

Die Unterscheidung, an der fast alle scheitern: auth_results ist die Rohprüfung, policy_evaluated ist die Prüfung nach dem Alignment. DMARC wertet SPF oder DKIM nur dann als bestanden, wenn die authentifizierte Domain mit Ihrer header_from-Domain übereinstimmt. Eine Marketingplattform, die mit ihrer eigenen Domain signiert, zeigt DKIM pass in auth_results und DKIM fail in policy_evaluated. Das ist keine kaputte Signatur. Es ist eine nicht ausgerichtete.

Schritt 3: jede Zeile einordnen

Zwei Personen prüfen DMARC-Berichtsdaten an Laptops an einem gemeinsamen Schreibtisch

Sobald die Felder klar sind, wird das Lesen eines Berichts zur Mustererkennung. Diese sieben Muster decken nahezu jede Zeile ab, die Ihnen begegnen wird.

#	Was die Zeile zeigt	Wahrscheinlichste Ursache	Was zu tun ist
1	SPF ausgerichtet pass, DKIM ausgerichtet pass, hohe Anzahl	Ihr eigener Mailserver oder ein korrekt konfigurierter Dienst	Nichts. Das ist der Zielzustand
2	SPF ausgerichtet pass, DKIM fail oder fehlt	Ein in SPF autorisierter Dienst, der nicht mit Ihrer Domain signiert	DKIM bei diesem Dienst aktivieren und dessen CNAME- oder TXT-Selektor veröffentlichen
3	SPF fail, DKIM ausgerichtet pass, `envelope_from` ist eine andere Domain	Weiterleitung, Mailingliste oder Plattform mit eigener Bounce-Domain	Normal. DMARC besteht trotzdem. Den Weiterleiter nicht in SPF aufnehmen
4	Rohes DKIM pass mit fremder Signaturdomain, ausgerichtetes DKIM fail	Drittanbieter signiert mit seinem eigenen Standardschlüssel	Beim Anbieter eine eigene Signaturdomain anfordern (ein CNAME unter Ihrer Domain)
5	Rohes SPF pass für `envelope_from`, ausgerichtetes SPF fail	Anbieter nutzt seine eigene Return-Path-Domain	Eigenen Return-Path bzw. eigene Bounce-Domain beim Anbieter einrichten oder auf DKIM setzen
6	Alles fail, `source_ip` gehört zu einem Cloud- oder Hosting-Bereich, den Sie nicht kennen, Anzahl in Hunderten oder Tausenden	Spoofing oder eine Phishing-Kampagne mit Ihrer Domain	Durchfallen lassen. Richtung `p=reject` gehen, damit Empfänger es verwerfen
7	Alles fail, niedrige Anzahl, `reason` nennt `mailing_list` oder `trusted_forwarder`	Der Empfänger hat die Nachricht von Ihrer Richtlinie ausgenommen	Informativ. Auf Ihrer Seite nichts zu beheben

Für eine Zeile, die Sie nicht zuordnen können, machen Sie einen Reverse-Lookup der IP mit dig -x 192.0.2.123 +short oder host 192.0.2.123 und prüfen dann das SPF-Include des vermuteten Anbieters. Ein PTR-Eintrag, der auf outbound.protection.outlook.com, google.com, amazonses.com, sendgrid.net oder mailgun.org endet, zeigt meist direkt auf den verantwortlichen Dienst.

Berichte in großer Zahl lesen

Eine Domain mit wenigen Absendern erzeugt eine Handvoll Dateien pro Tag, da funktioniert das Lesen von Hand. Darüber hinaus brauchen Sie einen Analyzer. Ein typischer Analyzer liest das rua=-Postfach ein, entpackt jede Datei und fasst die Zeilen nach Quelle zusammen, sodass Sie "Microsoft 365: 12.400 Nachrichten, 100 % ausgerichtet" sehen statt vierzig XML-Dateien. Kostenlose Optionen gibt es, und der Scan von FortifyNet sagt Ihnen, ob überhaupt ein rua=-Tag vorhanden und syntaktisch korrekt ist.

Zwei Gewohnheiten zählen mehr als das Werkzeug. Erstens: Beobachten Sie policy_published nach jeder DNS-Änderung. Empfänger cachen DMARC-Einträge, ein Bericht für den Tag Ihrer p=-Änderung kann also noch die alte Richtlinie zeigen, und RFC 9990 Abschnitt 3.3 erlaubt ausdrücklich eine Mischung. Zweitens: Lesen Sie weiter, nachdem Sie p=reject erreicht haben. Neue SaaS-Tools, rotierte DKIM-Schlüssel und bearbeitete SPF-Einträge tauchen schon am nächsten Tag als neue Zeile vom Muster 2, 4 oder 5 auf, lange bevor Ihre Kunden Bounces bemerken.

Was RFC 9990 für Leser geändert hat

Der Standard vom Mai 2026, der die Berichtsteile von RFC 7489 aus dem Jahr 2015 ablöst, ist relevant, wenn Sie Berichte selbst parsen oder einen Anbieter bewerten.

Feld oder Regel	RFC 7489 (2015)	RFC 9990 (2026)
XML-Namensraum	`http://dmarc.org/dmarc-xml/0.1`	`urn:ietf:params:xml:ns:dmarc-2.0`
DKIM-`selector`	Optional	Pflicht, sobald ein DKIM-Ergebnis gemeldet wird
`disposition`-Werte	none, quarantine, reject	Ergänzt `pass`
Übersteuerungsgründe	forwarded, sampled_out, trusted_forwarder, mailing_list, local_policy, other	local_policy, mailing_list, other, policy_test_mode, trusted_forwarder
`discovery_method`	Nicht vorhanden	Optional: `psl` oder `treewalk`
`generator`	Nicht vorhanden	Optionaler Name und Version der Berichtssoftware
`envelope_from`	Optional	Optional, kann bei Bounces mit leerem Absender leer sein
Unbekannte Elemente	Undefiniert	Müssen ignoriert werden, nicht als Fehler gelten

Alle großen Empfänger senden im September 2026 weiterhin Berichte im alten Format, und das wird noch lange so bleiben. Lesen Sie beide Formate gleich und verwerfen Sie nie einen Bericht, nur weil er ein Feld enthält, das Sie nicht kennen.

FAQ

Warum bekomme ich DMARC-Berichte für Mails, die ich nie gesendet habe? Weil jemand anderes sie sendet. Aggregierte Berichte erfassen jede Nachricht, die im From-Header Ihre Domain beansprucht hat, auch gefälschte. Eine Zeile mit hoher Anzahl, unbekannter IP und Fehlschlägen bei SPF und DKIM ist genau das Spoofing, für dessen Erkennung Sie DMARC eingerichtet haben.

Wie viele Berichte sollte ich pro Tag erwarten? Einen pro berichtendem Empfänger pro Tag und Domain, für ein kleines Unternehmen also typischerweise 3 bis 15 Dateien. RFC 9990 legt den Zeitraum auf einen einzelnen UTC-Tag fest. Sehr große Empfänger können einen Tag auf mehrere Dateien aufteilen.

Was bedeutet disposition none, wenn ich p=quarantine habe? Entweder hat die Nachricht DMARC bestanden, sodass keine Richtlinie griff, oder der Empfänger hat Ihre Richtlinie übersteuert und das reason-Element sagt warum. Prüfen Sie policy_evaluated: Sind beide ausgerichteten Ergebnisse pass, ist none die korrekte Disposition.

Enthalten DMARC-Berichte Mailinhalte oder personenbezogene Daten? Aggregierte Berichte enthalten sendende IPs, Zählungen und Authentifizierungsergebnisse, nichts aus dem Nachrichtentext oder den Headern jenseits der From-Domain. Fehlerberichte (RUF, definiert in RFC 9991) können Header enthalten und werden von großen Anbietern selten versendet.

Kann ich den Empfang von Berichten beenden? Entfernen Sie das rua=-Tag, und die Empfänger stellen den Versand innerhalb eines Tages ein. Sie verlieren damit jede Sicht auf Spoofing und Fehlkonfigurationen, rua= auf einen Analyzer zu richten ist daher die bessere Wahl.

Prüfen Sie, ob Ihre Berichte überhaupt ankommen

Bevor Sie einen Abend mit XML verbringen, lohnt es sich zu wissen, ob Ihr DMARC-Eintrag überhaupt Berichte anfordert, ob die rua=-Adresse autorisiert ist und ob SPF und DKIM bei den Ihnen bekannten Absendern eingerichtet sind. Der kostenlose Scan von FortifyNet liest Ihre DMARC-, SPF- und DKIM-Einträge und markiert in etwa 60 Sekunden, was fehlt, ohne Anmeldung. Kostenlosen Scan bei FortifyNet starten.