Was bedeuten die wichtigsten XML-Felder?

report_metadata sagt wer/wann den Report sendet, policy_published was Ihre DMARC-Policy zum Zeitpunkt war, record/row die einzelnen Sender-IPs mit Anzahl und Auth-Ergebnissen, auth_results die rohen SPF/DKIM-Resultate vor Alignment-Prüfung.

Warum sehe ich fremde IPs in meinen Reports?

Drei mögliche Ursachen: legitime Dienstleister mit Misalignment (z. B. Newsletter-Tool ohne Custom-Auth), Mail-Forwarding über Dritt-Server, oder echte Spoofing-Versuche. DMARC-Reports machen alle drei sichtbar.

Brauche ich Forensic-Reports zusätzlich?

In der Regel nicht. Aggregate-Reports zeigen, von welchen IPs SPF/DKIM scheitern. Forensic-Reports enthalten Mail-Header und sind DSGVO-sensitiv; viele Empfänger versenden sie aus Datenschutzgründen gar nicht mehr.

Reicht manuelle Auswertung der Reports?

Nein. DMARC-Reports sind XML, kommen täglich von mehreren Empfängern und ergeben erst durch Aggregation, Provider-Erkennung und Trend-Analyse über Zeit ein verwertbares Bild. opendmarc/parsedmarc zerlegen Einzel-Reports, lassen Sie aber bei Aggregation und Drift-Erkennung allein. Mailantis übernimmt genau diesen Teil automatisch.

DMARC-Aggregate-Reports interpretieren — XML verstehen

Q: Was ist der Unterschied zwischen authentifiziert und aligned?

Ein DKIM- oder SPF-Pass im auth_results bedeutet nur, dass die Signatur/IP für irgendeine Domain gültig war. Erst der Vergleich mit header_from (Alignment) entscheidet über DMARC-Pass.

Was ist ein Aggregate-Report?

Wenn Ihre Domain einen DMARC-Record mit rua=mailto:… hat, senden empfangende Mailserver (Google, Microsoft, Yahoo und ca. 700 weitere) täglich einen XML-Report. Dieser Report fasst zusammen, von welchen IPs in den letzten 24 Stunden Mails mit Ihrer From-Domain ankamen, ob diese SPF und DKIM bestanden haben und wie der Empfänger sie schließlich behandelt hat.

Der Report enthält keine Mail-Inhalte und keine Empfänger-Adressen — nur statistische Aggregat-Daten. RFC 7489 §7 definiert das Format (DMARC Aggregate Reporting, kurz: aggregate report bzw. rua).

Die Grundstruktur

Ein Report-XML besteht aus drei Hauptblöcken:

Aufbau eines Aggregate-Reports<feedback>
  <report_metadata>       <!-- WER hat den Report wann gesendet -->
    <org_name>Google</org_name>
    <email>[email protected]</email>
    <report_id>15748392026050801</report_id>
    <date_range>
      <begin>1715126400</begin>
      <end>1715212799</end>
    </date_range>
  </report_metadata>

  <policy_published>       <!-- WELCHE Policy galt zum Zeitpunkt -->
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>quarantine</p>
    <sp>quarantine</sp>
    <pct>100</pct>
  </policy_published>

  <record>                  <!-- WAS wurde beobachtet, pro IP/Auth-Kombination -->
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>1842</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
        <selector>google</selector>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Die wichtigsten Felder im Detail

report_metadata

org_name — wer den Report sendet (Google, Microsoft, Yahoo …).
date_range — Zeitraum der Beobachtung (Unix-Timestamps).
report_id — eindeutige ID, falls Sie nachfragen müssen.

policy_published

p — die Hauptdomain-Policy: none, quarantine oder reject.
sp — Subdomain-Policy (oft identisch mit p).
adkim, aspf — Alignment-Modus: r für relaxed, s für strict.
pct — Prozentsatz, auf den die Policy angewendet wird (während der Progression oft < 100).

record / row

source_ip — die IP, von der die Mails kamen. Reverse-Lookup zeigt den Sender.
count — wie viele Mails von dieser IP mit dieser Auth-Kombination.
policy_evaluated.disposition — was der Empfänger tatsächlich gemacht hat: none (zugestellt), quarantine (Spam-Ordner), reject (abgelehnt).
policy_evaluated.dkim/spf — Ergebnis nach Alignment-Prüfung.

auth_results

dkim.result — DKIM-Signatur-Prüfung (pass, fail, none).
dkim.domain — Domain im DKIM-d=-Tag (für Alignment-Vergleich mit header_from).
spf.result — SPF-Prüfung (pass, softfail, fail, none).
spf.domain — die im SPF geprüfte Domain (Envelope-Sender).

Alignment ≠ Authentifizierung. Ein DKIM- oder SPF-Pass im auth_results-Block heißt nur, dass die Signatur/IP für irgendeine Domain gültig war. Erst der Vergleich mit header_from (Alignment) entscheidet über DMARC-Pass.

Drei typische Muster, die Sie sofort erkennen sollten

Muster 1: Sauberer eigener Mail-Versand

source_ip gehört zu Ihrem Mail-Provider (Google, Microsoft, eigener Server), spf=pass, dkim=pass, policy_evaluated.dkim=pass und spf=pass. Großer count. → Alles in Ordnung.

Muster 2: Dienstleister mit Misalignment

spf=pass und dkim=pass, aber policy_evaluated zeigt fail. Das heißt: die Authentifizierung selbst hat funktioniert, aber für eine andere Domain als die im From:-Header. Typisch für Newsletter-Tools (Mailchimp, Sendgrid), die ihre eigene Default-Domain für SPF/DKIM nutzen. → Sender muss eigene Domain authentifizieren.

Muster 3: Spoofing-Versuch

source_ip ist eine fremde IP (oft aus Asien oder Osteuropa), spf=fail, dkim=none oder fail, count klein bis mittel (~10–100). → Jemand versucht, in Ihrem Namen Mails zu versenden. Mit p=reject werden diese Mails automatisch abgelehnt.

Warum manuelle Auswertung nicht skaliert

DMARC-Reports sind XML — maschinenlesbar, nicht menschenlesbar. Selbst eine kleine Domain bekommt täglich mehrere Reports von verschiedenen Empfängern (Google, Microsoft, Yahoo, Apple, Comcast, …). Ohne Aggregation sehen Sie nur Einzelbilder: eine IP hier, ein DKIM-Fail dort. Spoofing-Muster, Schatten-IT-Sender und Drift erkennen Sie erst, wenn Sie Tage und Wochen über alle Empfänger korrelieren — inklusive Reverse-DNS-Auflösung jeder Source-IP und Provider-Zuordnung.

Open-Source-Tools wie opendmarc-Parser oder parsedmarc können einzelne XML-Reports zerlegen. Die eigentliche Arbeit — Aggregation über Zeit, Provider-Erkennung, Trend-Visualisierung, Drift-Alerts — muss man sich selbst zusammenbauen und betreiben. Für ein paar Reports im Monat denkbar, für laufende DMARC-Pflege nicht praktikabel.

Genau dafür ist Mailantis da: XMLs werden eingelesen, aggregiert, mit Provider- und Geo-Erkennung angereichert und als lesbare Übersicht ausgegeben. Drift-Alerts schlagen automatisch an, sobald ein neuer Sender auftaucht. So bleibt von der DMARC-Auswertung nur der Teil übrig, der wirklich Entscheidungen verlangt — und nicht das XML-Parsen.

Was Sie nach dem Lesen tun sollten

Identifizieren Sie alle legitimen Sender (eigener Mailserver, M365/Google, Newsletter-Tool, CRM, Ticketing).
Korrigieren Sie Misalignment bei legitimen Sendern, bevor Sie die Policy verschärfen.
Ignorieren Sie nicht die kleinen Spoofing-Versuche — sie zeigen, dass Ihre Domain bereits ein Ziel ist.
Wenn drei bis vier Wochen sauber: Policy von none auf quarantine heben, dann später auf reject.

DMARC-Aggregate-Reports interpretieren