DMARC-Berichte lesen

Modul 4: Zustellbarkeit: SPF, DKIM und DMARC in der Praxis · Lesezeit: 12 Minuten

Lernziel: Nach dieser Lektion können Sie einen DMARC-Sammelbericht öffnen und lesen, pro Zeile bestimmen, um welche Quelle es sich handelt und warum sie erfolgreich ist oder fehlschlägt, und entscheiden, was Sie reparieren, was Sie ignorieren dürfen und wann Sie Ihr Regelwerk (Policy) verschärfen können.

Kernbegriffe: Sammelbericht (aggregate report, RFC 9990), rua, XML, gzip oder zip, report_metadata, policy_published, record, row, source_ip, count, policy_evaluated (disposition, dkim, spf), identifiers (header_from, envelope_from), auth_results, Selector, Fehlerbericht (ruf, RFC 9991), Berichtsdienst, Datenschutz

Was Sie erhalten

Haben Sie in Ihrem DMARC-Eintrag eine rua-Adresse eingetragen (Lektion 4.4), senden Ihnen große Empfänger wie Google, Microsoft und Yahoo ungefähr jeden Tag einen Sammelbericht. Es handelt sich um eine E-Mail mit einem Anhang, meist eine gezippte XML-Datei mit einem Namen wie:

receiver.example!example.com!1793923200!1794009599.xml.gz

Das bedeutet: vom Empfänger receiver.example, über Ihre Domain example.com, für den Zeitraum zwischen den beiden Zeitstempeln (Sekunden seit 1970; hier 6. November 2026, der ganze Tag in UTC).

Ein Bericht enthält keinen Inhalt von E-Mails, keine Betreffzeilen und meist keine Adressen von Empfängern. Er enthält pro versendendem Server die Anzahl der Nachrichten und das Ergebnis von SPF, DKIM und DMARC. Dadurch ist er ein zuverlässiger Überblick darüber, wer in Ihrem Namen E-Mails versendet, auch von Quellen, die Sie selbst vergessen hatten, und von Betrügern.

Der Aufbau eines Berichts

Ein Bericht besteht aus drei Teilen. Im Folgenden die wichtigsten Abschnitte aus der Beispieldatei zu dieser Lektion (dmarc-rapport-1.xml).

1. Wer berichtet, über welchen Zeitraum

<report_metadata>
  <org_name>receiver.example</org_name>
  <email>noreply-dmarc@receiver.example</email>
  <report_id>receiver.example-20261106-7f3c2a91</report_id>
  <date_range>
    <begin>1793923200</begin>
    <end>1794009599</end>
  </date_range>
</report_metadata>

2. Welches Regelwerk der Empfänger bei Ihnen vorgefunden hat

<policy_published>
  <domain>example.com</domain>
  <p>none</p>
  <sp>none</sp>
  <np>none</np>
  <adkim>r</adkim>
  <aspf>r</aspf>
  <testing>n</testing>
</policy_published>

Prüfen Sie dies immer: steht hier nicht, was Sie glauben, dass in Ihrem DNS steht, hat der Empfänger einen anderen (oder alten) Eintrag gelesen.

3. Pro Quelle: ein Datensatz

Jeder record betrifft eine versendende IP-Adresse mit einer Kombination von Ergebnissen:

<record>
  <row>
    <source_ip>198.51.100.40</source_ip>
    <count>1250</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounce.mailer.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mailer.example</domain>
      <selector>k1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounce.mailer.example</domain>
      <scope>mfrom</scope>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Der wichtigste Unterschied: auth_results gegenüber policy_evaluated

Hier liegt der Kern des Lesens. Im obigen Beispiel steht in auth_results zweimal pass: DKIM war erfolgreich für mailer.example und SPF war erfolgreich für bounce.mailer.example. Trotzdem steht in policy_evaluated zweimal fail. Das ist kein Widerspruch: policy_evaluated zählt nur eine erfolgreiche Prüfung, die mit header_from ausgerichtet ist. Keine der beiden Domains gehört zu example.com, daher schlägt DMARC fehl.

So lesen Sie jede Zeile:

1. Schauen Sie sich policy_evaluated an. Steht bei dkim oder spf ein pass? Dann ist DMARC erfolgreich und diese Quelle ist in Ordnung.
2. Schlägt alles fehl? Schauen Sie in auth_results auf die Domains. Ist es ein Dienst von Ihnen, der erfolgreich ist, aber für seine eigene Domain? Dann müssen Sie bei diesem Dienst DKIM mit Ihrer eigenen Domain aktivieren (Lektion 4.3).
3. Schlägt es auch in auth_results fehl, oder fehlt DKIM ganz? Finden Sie heraus, wem die IP-Adresse gehört (Reverse DNS, Lektion 5.1, oder eine Whois-Abfrage). Ist es eines Ihrer eigenen Systeme: reparieren. Ist es unbekannt und handelt es sich um verdächtige Mengen: wahrscheinlich Fälschung.

Muster, die Sie immer wieder sehen

Achten Sie auch auf IPv6: ein eigener Server, der manchmal über IPv6 versendet, während Ihr SPF nur die IPv4-Adresse nennt, liefert bei diesen Zeilen einen softfail. Mit einer DKIM-Signatur ist DMARC dann trotzdem erfolgreich, aber es ist ein Zeichen, dass Ihr SPF unvollständig ist.

Vom Bericht zur Entscheidung

Sie sind bereit, Ihr Regelwerk zu verschärfen (von none zu quarantine, danach zu reject), wenn:

• jede Quelle, die zu Ihnen gehört, in policy_evaluated mindestens einen pass hat;
• das schon einige Wochen so ist, bei allen großen Empfängern;
• was noch fehlschlägt, nur weitergeleitete E-Mail mit gültiger DKIM-Signatur ist (die dann trotzdem erfolgreich ist) oder eindeutig Fälschung ist.

Schlägt eine große eigene Quelle fehl, wie im Beispiel der Newsletter-Dienst mit 1250 Nachrichten, dann ist es noch zu früh. Mit p=reject würde der Empfänger diese 1250 Newsletter ablehnen.

Berichte lesbar machen

Ein Bericht in einem Texteditor ist machbar. Zwanzig pro Tag nicht. Es gibt drei Möglichkeiten:

• Ein Berichtsdienst (es gibt viele, auch mit einer kostenlosen Variante). Sie tragen deren Adresse bei rua ein und sie erstellen daraus Grafiken und Listen. Beachten Sie: Damit gewähren Sie diesem Dienst Einblick, welche Server in Ihrem Namen versenden, und die Berichtsadresse liegt auf deren Domain (siehe die Zustimmung über _report._dmarc in Lektion 4.4). Wählen Sie einen Dienst, dem Sie vertrauen und der die DSGVO einhält.
• Ein eigenes Werkzeug: es gibt Open-Source-Programme, die Berichte aus einem Postfach holen und in einer Übersicht darstellen.
• Selbst lesen mit einem XML-Viewer oder einem Browser, für gelegentliche Fälle.

Fehlerberichte (ruf, RFC 9991) sind anders: pro fehlgeschlagener E-Mail, manchmal mit Teilen der E-Mail darin. Fast kein großer Empfänger sendet sie, gerade wegen des Datenschutzes. Sie brauchen sie nicht, um DMARC erfolgreich einzuführen.

In der Praxis: so sieht es aus

Bei WebOké können Sie die Berichtsadresse in der DMARC-Hilfe in DirectAdmin oder Mein WebOké eintragen (siehe Lektion 4.4), und Sie wählen selbst ein Postfach, in dem die Berichte eingehen; eine separate Adresse wie dmarc@ mit einem eigenen Ordner verhindert, dass Ihre normale Post darunter untergeht. Zum Lesen nutzen Sie einen Berichtsdienst oder ein Programm Ihrer Wahl. Das funktioniert bei jedem Anbieter gleich: der Bericht ist ein Standardformat.

Zusammenfassung

• Ein Sammelbericht ist eine tägliche XML-Datei (oft gezippt) pro Empfänger, mit der Anzahl der Nachrichten und den Ergebnissen pro versendender IP.
• auth_results gibt das rohe SPF- und DKIM-Ergebnis an; policy_evaluated nur das, was ausgerichtet erfolgreich war. Ein pass in auth_results kann ein fail in DMARC sein.
• Weitergeleitete E-Mail erkennen Sie an DKIM pass mit SPF fail; Fälschung an allem fail von einer unbekannten IP.
• Verschärfen Sie Ihr Regelwerk erst, wenn alle Ihre eigenen Quellen schon einige Wochen erfolgreich sind.
• Fehlerberichte (ruf) sind selten und nicht nötig.

Quiz

Aufgabe

Aufgabe Z4.5: Einen DMARC-Bericht lesen. Öffnen Sie die Beispieldatei dmarc-rapport-1.xml (ein Sammelbericht über example.com, mit erfundenen Daten). Beantworten Sie die Fragen: welches Regelwerk hat der Empfänger vorgefunden, wie viele Nachrichten stehen insgesamt im Bericht, wie viele davon scheiterten an DMARC, welche Zeile ist der Newsletter-Dienst und was muss dort geschehen, welche Zeile ist weitergeleitete E-Mail, welche Zeile ist wahrscheinlich Fälschung, was muss laut Zeile 6 am SPF-Eintrag geändert werden, welche Zeile ist nur dank DKIM bei einem Dienst mit eigenem Return-Path erfolgreich, und darf die Domain jetzt auf p=quarantine wechseln? Das Programm prüft Ihre Antworten anhand eines festen Schlüssels und erklärt zu jeder Frage, welche Zeile des Berichts die Antwort liefert.

Weiterführende Informationen

Die Schritte in diesen Artikeln gelten für die Bedienoberflächen von WebOké; bei anderen Anbietern funktioniert es vergleichbar.

• Was ist DMARC? Erklärung in einfacher Sprache
• DirectAdmin Anleitung 5.9: DMARC einrichten
• Kostenloser DNS-Kurs 4.5: DMARC: was Empfänger mit gefälschter Mail tun sollen
• RFC 9990 (DMARC Aggregate Reporting), mit dem Beispielbericht in Anhang B; RFC 9991 (Failure Reporting)