Zwei Arten von Reports
RFC 7489 definiert Aggregate-Reports (rua) und Forensik-Reports (ruf). Aggregate-Reports sind Statistiken: Ein Empfänger fasst alle Mails zusammen, die er in einem Zeitraum mit deiner Domain im From-Header gesehen hat, gruppiert nach Quell-IP und Ergebnis. Sie enthalten keine Mailinhalte und keine Adressen einzelner Empfänger.
Forensik-Reports wären Kopien einzelner fehlgeschlagener Mails. Aus Datenschutzgründen versenden fast alle großen Empfänger keine ruf-Reports, weil darin personenbezogene Daten und Mailinhalte stehen könnten. Du kannst ruf= eintragen, solltest aber nicht damit planen. Die Arbeit passiert mit rua.
_dmarc.beispiel.de. TXT "v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de"Wie oft und in welcher Form Reports kommen
Jeder Empfänger, der DMARC auswertet, sendet in der Regel einen Report pro Tag und Domain, das Intervall steht im Report selbst. Der Report kommt als gzip- oder zip-Anhang, der Dateiname folgt dem Muster empfaenger!deinedomain!start!ende.xml. Bei einer Domain mit wenig Mailverkehr sind das ein bis fünf Reports täglich, bei größeren Kunden deutlich mehr.
Reports kommen nur von Empfängern, die DMARC-Reporting implementiert haben. Google, Microsoft, Yahoo und die großen deutschen Provider gehören dazu, viele kleine Mailserver nicht. Die Reports decken also nie hundert Prozent des Verkehrs ab, aber genug, um alle relevanten Absender zu finden.
Die XML-Struktur
Ein Aggregate-Report besteht aus drei Teilen. report_metadata enthält den Namen des Empfängers, eine Report-ID und den Zeitraum. policy_published zeigt, welchen DMARC-Record der Empfänger zum Zeitpunkt der Auswertung gesehen hat, nützlich, wenn du prüfen willst, ob eine Änderung schon angekommen ist. Der eigentliche Inhalt steckt in den record-Elementen, eines pro Kombination aus Quell-IP und Ergebnis.
<record>
<row>
<source_ip>203.0.113.10</source_ip>
<count>42</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>beispiel.de</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>beispiel.de</domain>
<selector>s1</selector>
<result>pass</result>
</dkim>
<spf>
<domain>bounce.newsletter-dienst.de</domain>
<result>pass</result>
</spf>
</auth_results>
</record>Dieser Datensatz sagt: 42 Mails kamen von 203.0.113.10. SPF war technisch pass, aber für die Domain bounce.newsletter-dienst.de, nicht für beispiel.de, deshalb steht unter policy_evaluated spf=fail (kein Alignment). DKIM war mit d=beispiel.de signiert und aligned. DMARC ist damit bestanden, die disposition none wurde angewendet, weil die Policy p=none war.
Pass und Fail richtig lesen
Der wichtigste Block ist policy_evaluated. Dort stehen die DMARC-Ergebnisse, also SPF und DKIM inklusive Alignment. Die Werte unter auth_results sind die rohen Prüfergebnisse ohne Alignment. Ein spf=pass in auth_results mit spf=fail in policy_evaluated ist kein Widerspruch, sondern das typische Muster eines Dienstleisters, der mit eigenem Return-Path sendet.
DMARC ist bestanden, wenn mindestens eines der beiden Ergebnisse unter policy_evaluated pass ist. Stehen beide auf fail, ist die Mail entweder gefälscht, oder ein eigener Absender ist noch nicht richtig konfiguriert. Die disposition zeigt, was der Empfänger tatsächlich getan hat: none, quarantine oder reject. Sie kann von deiner Policy abweichen, etwa wegen pct= oder weil der Empfänger ARC ausgewertet und die Mail trotzdem angenommen hat.
- dkim=pass, spf=pass: alles in Ordnung
- dkim=pass, spf=fail: Dienstleister mit eigenem Return-Path oder Weiterleitung, DMARC bestanden
- dkim=fail, spf=pass: Absender ohne DKIM oder kaputte Signatur, bei Weiterleitung wird es fail
- dkim=fail, spf=fail: Spoofing oder ein eigener Absender ohne jedes Alignment
Eigene Absender von Spoofing unterscheiden
Schau dir bei jeder Quell-IP mit fail drei Dinge an: die Reverse-DNS-Auflösung der IP, die Domain im SPF-Ergebnis unter auth_results und die Anzahl. Eine IP, die auf mail-relay.newsletter-dienst.de auflöst und tausend Mails am Tag sendet, ist ein Dienst des Kunden. Hunderte einzelne IPs aus Hosting-Netzen weltweit mit je ein bis drei Mails sind Spoofing oder Spam.
Weiterleitungen erzeugen ein eigenes Muster: SPF fail mit einer fremden Domain im auth_results, DKIM pass, geringe Zahlen, oft von Universitäten, Vereinen oder privaten Mailservern. Das ist der ursprüngliche Empfänger, der die Mail weitergeleitet hat. Solche Einträge sind harmlos und lassen sich nicht abstellen. Wenn Empfänger ARC unterstützen, siehst du das manchmal an einer disposition none trotz Policy quarantine.
Reports für viele Kundendomains empfangen
Als Agentur willst du die Reports aller Kundendomains an einer Stelle sammeln, etwa unter dmarc@agentur.de. Damit ein Empfänger Reports an eine Adresse in einer anderen Domain sendet, muss die Zieldomain dem zustimmen. Dazu veröffentlicht die Zieldomain einen TXT-Record unter kundendomain._report._dmarc.agentur.de mit dem Inhalt v=DMARC1. Fehlt dieser Record, verwerfen die Empfänger den Report.
Bei vielen Kunden legst du einfach einen Wildcard-Record an, der für alle Domains gilt. Danach kann jeder Kunde in seinem DMARC-Record rua=mailto:dmarc@agentur.de eintragen, ohne dass du pro Domain etwas ändern musst.
*._report._dmarc.agentur.de. TXT "v=DMARC1"
Im DMARC-Record des Kunden:
_dmarc.kunde.de. TXT "v=DMARC1; p=none; rua=mailto:dmarc@agentur.de"Werkzeuge zur Auswertung
Reports von Hand zu lesen funktioniert für eine Domain und eine Woche. Für zehn Kunden über Monate brauchst du eine Auswertung, die XML entpackt, IPs zu Diensten zuordnet und Trends zeigt. Die Optionen reichen von Open-Source-Parsern, die du selbst betreibst, über kostenlose Basisangebote von DNS- und Security-Anbietern bis zu spezialisierten SaaS-Diensten mit Preis pro Domain oder Mailvolumen.
Entscheidend ist, dass die Auswertung dir zwei Fragen beantwortet: Welche Quellen senden mit fail, und hat sich seit letzter Woche etwas verändert. Der DMARC Checker hilft beim ersten Schritt, indem er zeigt, ob der Record überhaupt korrekt ist und an welche Adressen Reports gehen.
Häufige Fragen
- Warum bekomme ich keine Reports, obwohl rua gesetzt ist?
- Häufigste Gründe: Der Record ist fehlerhaft und wird ignoriert, die rua-Adresse liegt in einer fremden Domain ohne _report._dmarc-Freigabe, oder die Domain sendet so wenig, dass die Empfänger nichts zu berichten haben. Prüfe zuerst den Record, dann die Freigabe.
- Sind die Quell-IPs in Reports die Absender oder die Empfänger?
- Die Absender. source_ip ist die IP, von der der berichtende Empfänger die Mail entgegengenommen hat. Bei Weiterleitungen ist das der weiterleitende Server, nicht der ursprüngliche Absender.
- Kann ich Reports an mehrere Adressen schicken lassen?
- Ja, rua akzeptiert mehrere mailto-URIs durch Komma getrennt. So kann der Kunde eine Kopie behalten, während die Agentur die Auswertung übernimmt. Für jede fremde Zieldomain gilt die Freigabepflicht.