DMARC-Bericht lesen: XML-Aggregat-Reports Zeile für Zeile

Die ersten DMARC-Berichte kommen meist am Tag nach dem Anlegen des Records. Eine Mail von [email protected], Betreff „Report domain: beispiel.de“, im Anhang eine ZIP-Datei mit kryptischem Namen. Wer sie öffnet, sieht XML und schließt sie wieder. Schade, denn in dieser Datei steht, wer alles in deinem Namen Mails verschickt.

Wo die Berichte herkommen

Mit dem Tag rua=mailto:… in deinem DMARC-Record bittest du alle Empfänger, dir Aggregat-Berichte zu schicken. Das tun Gmail, Microsoft, Yahoo und viele andere einmal täglich. Jeder Bericht fasst zusammen, welche IP-Adressen wie viele Mails mit deiner Domain im From-Header eingeliefert haben und wie die Prüfung ausging. Inhalte, Betreffzeilen oder Empfängeradressen stehen nicht drin.

Seit Mai 2026 ist das Format in RFC 9990 beschrieben, vorher in RFC 7489. Der Aufbau ist im Kern gleich geblieben. Wie du den Record selbst anlegst, steht in DMARC einrichten.

Einen DMARC-Bericht lesen: die Struktur

So sieht ein gekürzter Bericht aus, nach dem Entpacken:

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>[email protected]</email>
    <report_id>8822104593315601234</report_id>
    <date_range><begin>1792195200</begin><end>1792281599</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>beispiel.de</domain>
    <adkim>r</adkim><aspf>r</aspf>
    <p>none</p><sp>none</sp>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.10</source_ip>
      <count>412</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers><header_from>beispiel.de</header_from></identifiers>
    <auth_results>
      <dkim><domain>beispiel.de</domain><selector>s2026</selector><result>pass</result></dkim>
      <spf><domain>beispiel.de</domain><result>pass</result></spf>
    </auth_results>
  </record>
</feedback>

Die Zeitangaben sind Unix-Timestamps. date -u -r 1792195200 auf macOS oder date -u -d @1792195200 unter Linux macht ein Datum daraus.

Der wichtigste Unterschied, der oft übersehen wird: auth_results zeigt, ob SPF und DKIM überhaupt bestanden haben, egal für welche Domain. policy_evaluated zeigt, ob sie für deine Domain bestanden haben. Ein pass unten und ein fail oben bedeutet fast immer: Ein Dienst signiert mit seiner eigenen Domain statt mit deiner.

Vier Muster, die du immer wieder siehst

Eigener Server, alles grün

Bekannte IP, hoher count, DKIM und SPF pass. So soll es sein.

Bekannter Dienst, DKIM ohne Alignment

Die IP gehört zu deinem Newsletter-Tool, auth_results zeigt dkim domain=dienst-mailer.com pass, im policy_evaluated steht fail. Lösung: im Tool die eigene Absenderdomain authentifizieren, siehe DKIM einrichten.

Weiterleitung

IP eines anderen Providers, kleine Zahl, SPF fail, DKIM pass. Ein Empfänger leitet deine Mails an ein anderes Postfach weiter. Da DKIM besteht, ist das unkritisch.

Fremde IP, alles fail

IP aus einem Netz, das du nicht kennst, oft aus Hosting-Rechenzentren oder Privatanschlüssen in Ländern, in denen du keine Geschäfte machst. SPF fail oder für eine fremde Domain, kein DKIM. Das ist Spoofing. Bei p=reject steht als Disposition reject, und genau das willst du sehen.

Wem gehört eine IP-Adresse?

Um einen bekannten Dienst von einer Fälschung zu unterscheiden, brauchst du den Besitzer der IP. Zwei Befehle helfen:

$ dig +short -x 209.85.220.41
mail-sor-f41.google.com.
$ whois 209.85.220.41 | grep -iE '^(OrgName|netname)'
NetName:        GOOGLE
OrgName:        Google LLC

Der Reverse-DNS-Name verrät häufig schon den Dienst. Mailchimp, Brevo, Amazon SES, SendGrid und Microsoft haben gut erkennbare Namen. Bleibt der Reverse-Eintrag leer und gehört die IP einem Billig-Hoster, ist es selten etwas Legitimes.

Eine Tabelle statt hundert XML-Dateien

Ab einer Handvoll Berichten pro Tag lohnt es sich, sie maschinell zusammenzufassen. Ein schneller Weg mit Bordmitteln, wenn die entpackten Dateien in einem Ordner liegen und xmllint installiert ist:

for f in *.xml; do
  xmllint --xpath 'concat(//org_name, ";", //record[1]/row/source_ip, ";", //record[1]/row/count, ";", //record[1]/row/policy_evaluated/dkim, ";", //record[1]/row/policy_evaluated/spf)' "$f"
  echo
done

Das liest nur den ersten record pro Datei, reicht aber für einen ersten Überblick. Für mehr gibt es Open-Source-Parser (etwa parsedmarc), die Berichte direkt aus einem IMAP-Postfach holen, oder kommerzielle Dienste. Wer rua an eine fremde Domain schickt, braucht dort einen Freigabe-Record, sonst verwerfen Empfänger die Berichte.

Forensik-Berichte (ruf)

Mit ruf= kannst du zusätzlich Fehlerberichte zu einzelnen Mails anfordern. Sie enthalten Header und teils Inhalte. In der Praxis kommen sie selten: Gmail schickt keine, viele andere aus Datenschutzgründen auch nicht. Wenn welche kommen, behandle das Postfach wie eins mit personenbezogenen Daten.

Wann du auf reject umstellen kannst

Lies die Berichte von mindestens zwei Wochen und stelle eine Liste aller IPs mit nennenswertem count auf. Kannst du für jede sagen, welcher Dienst das ist, und besteht jeder legitime Dienst DKIM oder SPF mit Alignment, ist die Domain bereit für quarantine und danach reject. Was das gegen Fälschungen bringt, zeigt E-Mail-Spoofing verhindern. Wenn danach noch Zeit ist: Auf reject baut auch das Markenlogo im Posteingang auf, siehe BIMI.

Für die Berichte lohnt sich übrigens eine eigene Adresse, die nicht im normalen Postfach landet. Wer mehrere Projekte betreibt, legt sich dafür gern eine separate Domain zu. Was die bei betadomain kostet, zeigt die Übersicht aller Endungspreise, eine .email-Domain liegt etwa bei 29,99 € im Jahr. Den passenden Namen kannst du direkt in der Domain-Suche nachschlagen.