Was ein DMARC-Report enthält
Ein DMARC-Aggregatbericht ist eine XML-Datei, die ein Mailanbieter für Ihre Domain erzeugt, wenn in Ihrem DNS-Eintrag eine rua=-Adresse steht. Sie fasst meist 24 Stunden zusammen. Im Kopf stehen der Berichtsteller (org_name), die Report-ID und der Zeitraum als Unix-Sekunden. Danach folgt die Richtlinie, die der Empfänger bei Ihnen gefunden hat, also p, sp, adkim und aspf.
Den Rest bilden die record-Einträge. Jeder fasst Mails von einer IP-Adresse mit gleichem Prüfergebnis zusammen. Der Bericht enthält keine Inhalte, keine Betreffzeilen und keine einzelnen Empfängeradressen, nur Zahlen und Domains. Dieses Werkzeug liest das Format nach RFC 9990 und die ältere Fassung nach RFC 7489.
So öffnen Sie die ZIP- oder GZ-Datei aus der Mail
Sie müssen nichts entpacken. Ziehen Sie die Anhänge der Berichtsmails direkt in das Feld oben, auch mehrere auf einmal. Das Werkzeug erkennt am Dateianfang, ob es sich um gzip, ZIP oder reines XML handelt, und liest bei ZIP nur die XML-Einträge. Eine Datei mit einem Namen wie google.com!example.de!1760572800!1760659199.xml.gz verrät schon vor dem Öffnen den Empfänger, Ihre Domain und den Zeitraum.
Gegen präparierte Archive gelten Grenzen. Eine Datei darf höchstens 25 MB groß sein, entpackt höchstens 50 MB. Ein großer Bericht belegt beim Lesen ein Mehrfaches seiner Größe im Arbeitsspeicher, auf einem Handy kann der Tab dabei abstürzen. Dateien mit DOCTYPE oder ENTITY lehnt das Werkzeug ab, das schützt vor XML-Bomben. Wollen Sie ein Archiv nur auspacken, nutzen Sie den ZIP-Entpacker.
Die wichtigsten Felder: source_ip, count, disposition
source_ip ist die IP-Adresse des Servers, der Mails mit Ihrer Domain im Absender eingeliefert hat. count gibt an, wie viele Nachrichten das waren. disposition sagt, was der Empfänger daraus gemacht hat: none heißt normal zugestellt, quarantine Spam-Ordner, reject abgelehnt. Neu in RFC 9990 ist der Wert pass: Die Mail hat DMARC bestanden, die Richtlinie musste nicht greifen. Bei p=none steht dort in der Regel none, auch bei durchgefallenen Mails, denn der Empfänger setzt vor allem um, was Ihre Richtlinie vorgibt. Er darf nach eigener Richtlinie davon abweichen und nennt das dann im Feld reason (etwa local_policy).
Eine Reverse-DNS-Abfrage oder eine Ortung der IP-Adressen macht das Werkzeug nicht, dazu wäre ein Server nötig. Den Besitzer einer unbekannten IP finden Sie über eine Whois-Abfrage, etwa in der RIPE-Datenbank.
Die Tabelle sortiert durchgefallene Zeilen nach oben und markiert sie rot. Ein Beispiel: Meldet ein Empfänger für 192.0.2.10 142 Nachrichten mit DKIM und SPF bestanden, ist das Ihr eigener Mailserver. Steht darunter 203.0.113.99 mit 21 Nachrichten und zweimal fail, prüfen Sie zuerst, ob dahinter ein Dienst steckt, den Sie selbst beauftragt haben. Der Beispielbericht auf dieser Seite enthält genau diese Fälle mit erfundenen Daten.
DKIM und SPF im Bericht: Ergebnis und Ausrichtung
Jeder Datensatz enthält zwei Blöcke. In policy_evaluated steht das Ergebnis für DMARC, nämlich ob DKIM oder SPF bestanden hat und zur Absenderdomain im From passt (Ausrichtung, englisch Alignment). In auth_results stehen die rohen Prüfungen: bei DKIM Domain, Selector und Ergebnis, bei SPF Domain, Prüfbereich und Ergebnis. Beide Blöcke können sich widersprechen. Ein Newsletter-Dienst kann ein gültiges DKIM mit seiner eigenen Domain setzen. Die rohe Prüfung ist dann pass, für DMARC zählt sie wegen fehlender Ausrichtung nicht.
Das Werkzeug zeigt beide Blöcke nebeneinander. Mit adkim und aspf legen Sie fest, ob die Domains exakt (s) oder nur in der Organisationsdomain (r, Standard) übereinstimmen müssen. Eine Mail besteht DMARC, wenn SPF oder DKIM ausgerichtet bestanden hat. Das Werkzeug wertet genau so.
Wann Sie auf quarantine oder reject umstellen können
Stehen über mehrere Wochen alle Ihnen bekannten Absender als bestanden im Bericht und fällt nur noch Unbekanntes durch, ist p=quarantine ein sinnvoller nächster Schritt. Später folgt p=reject. Legen Sie dafür möglichst alle Berichte eines Monats gleichzeitig ab. Das Werkzeug führt sie je Domain zusammen und zählt doppelt abgelegte Berichte nur einmal.
Der Hinweis unter der Auswertung ist eine Orientierung, keine Zusage. Ein Bericht deckt nur die Empfänger ab, die ihn senden. Selten genutzte Absender wie die Jahresabrechnung oder ein Rundbrief im Quartal tauchen oft erst spät auf. Das Einrichten der Einträge beschreibt der Artikel E-Mail-Spam, SPF, DKIM und DMARC einrichten, den Stand Ihrer DNS-Einträge zeigt der E-Mail-Check.
Fremde Absender erkennen: Newsletter-Dienst oder Fälschung
Die meisten unbekannten Quellen sind harmlos: ein Newsletter-Tool, ein Ticketsystem, die Buchhaltung, ein Kontaktformular auf Ihrer Website. Sie fallen durch, weil SPF und DKIM für deren Server nicht eingerichtet sind. Tragen Sie diese Dienste bei SPF ein und richten Sie bei ihnen DKIM mit Ihrer Domain ein.
Verdächtig sind Quellen mit vielen Mails, bei denen beides scheitert und die Sie keinem Dienst zuordnen können. Das spricht für gefälschte Absender. Gegen sie hilft nur eine strengere Richtlinie, deshalb ist die Liste durchfallender Quellen oben im Ergebnis das Wichtigste.
Gehen Sie nach jedem Bericht gleich vor: Bestehen die bekannten Absender, notieren Sie sich die Quellen, die durchfallen. Erst wenn jede davon geklärt ist oder bewusst gesperrt bleiben soll, lohnt der nächste Schritt bei der Richtlinie. Berichte unterschiedlicher Empfänger ergänzen sich, weil jeder Anbieter nur seine eigenen Eingänge zählt. Wollen Sie eine einzelne verdächtige Mail nachverfolgen, zeigt die Seite E-Mail-Header analysieren, über welche Server sie gelaufen ist und ob SPF, DKIM und DMARC bestanden haben.
Was sich mit RFC 9990 geändert hat
RFC 9990 ersetzt für die Berichte den RFC 7489 und nennt den Namensraum urn:ietf:params:xml:ns:dmarc-2.0. Der Dateiname folgt dem Muster Empfänger!Domain!Beginn!Ende, optional mit einer Kennung. Bei disposition kommt der Wert pass hinzu (bestanden, die Richtlinie musste nicht greifen); der Beispielbericht im RFC verwendet ihn. Neu in der veröffentlichten Richtlinie sind np für nicht existierende Subdomains, testing und discovery_method. Das Feld pct kennt nur noch der alte Standard. Der Abschnitt zur Sicherheit warnt ausdrücklich vor ZIP- und XML-Bomben, deshalb sind die Grenzen oben gesetzt. Ältere Berichte ohne Namensraum liest das Werkzeug weiterhin.