DMARC-Reports auswerten — was in den Aggregate-Reports steht

Was ankommt

Jeder große Empfänger schickt einmal täglich eine Mail mit einem komprimierten XML-Anhang. Ein Bericht deckt einen Empfänger und einen Tag ab — bei einer aktiven Domain sind das schnell zehn bis dreißig Mails pro Tag. Sie gehören deshalb in ein eigenes Postfach, nicht in das, in dem gearbeitet wird.

Berichte kommen mit Verzögerung: Was heute ankommt, beschreibt gestern. Nach einer DNS-Änderung wartest du also mindestens zwei Tage, bevor du die Wirkung beurteilst.

Der Aufbau des XML

Der interessante Teil ist <policy_published> als Kontrollwert — steht dort etwas anderes als in deinem DNS, hast du einen Tippfehler oder eine veraltete Zone. Alles danach sind die Datensätze.

Einen Record lesen

• count ist die wichtigste Zahl. Eine Zeile mit count 3 ist Rauschen, eine mit 4.000 ist ein Versandsystem. Wer Zeilen zählt statt Nachrichten, gewichtet falsch.
• policy_evaluated zeigt das ausgerichtete Ergebnis, nicht das rohe. Ein spf=pass weiter unten in auth_results kann hier trotzdem als fail erscheinen — dann hat SPF bestanden, aber für eine andere Domain als die im From-Header. Genau dieser Unterschied ist DMARC.
• disposition sagt, was der Empfänger tatsächlich getan hat. Unter p=none steht dort immer none, auch bei Fehlschlägen.

Die drei Muster, die du wiedererkennen wirst

1. DKIM pass, SPF fail, bekannte IP. Fast immer eine Weiterleitung. Der weiterleitende Server sendet mit eigener IP, die Signatur überlebt aber. Das ist unkritisch — DMARC besteht, sobald einer von beiden ausgerichtet besteht.
2. SPF pass, DKIM none, fremde IP. Ein Dienstleister, den du autorisiert hast, der aber nicht mit deiner Domain signiert. Hier lohnt es, beim Anbieter die DKIM-Signatur mit eigener Domain einzurichten — sonst bleibt die Zustellung von einer einzigen Prüfung abhängig.
3. Beides fail, unbekannte IP, kleine Zahlen aus wechselnden Ländern. Das ist der Missbrauch, gegen den DMARC gebaut wurde. Er verschwindet nicht durch Reports, sondern erst durch eine durchgesetzte Policy.

Zwei Stolpersteine bei der Einrichtung

Externe Report-Adressen brauchen eine Freigabe. Liegt die rua-Adresse auf einer anderen Domain als der berichteten, verlangt RFC 7489 einen Bestätigungs-Record in der Zieldomain:

Fehlt er, senden regelkonforme Empfänger überhaupt keine Berichte — und das Ausbleiben sieht aus wie „niemand sendet in meinem Namen“.

Mehr als zwei Ziele bringen nichts. Viele Empfänger beliefern nur die ersten ein bis zwei URIs in der Liste. Wer vier Adressen einträgt, bekommt an den hinteren zuverlässig nichts.

Und die ruf-Berichte?

Forensische Berichte enthalten einzelne fehlgeschlagene Nachrichten samt Kopfzeilen. Praktisch schickt sie kaum noch ein großer Empfänger, weil sie personenbezogene Daten Dritter enthalten. Man kann ruf setzen, sollte aber nicht damit planen.