DMARC-Berichte lesen und auswerten: So findest du alle Absender deiner Domain
Mit DMARC-Berichten siehst du, wer alles Mails in deinem Namen verschickt – und ob diese Mails SPF und DKIM bestehen. Ohne diese Berichte ist ein sicherer Wechsel auf p=quarantine oder p=reject kaum möglich. So richtest du sie ein, so liest du sie, und darauf musst du achten.
Was DMARC-Berichte sind
Große Postfach-Anbieter wie Gmail, Yahoo und Outlook.com schicken dem Inhaber einer Domain einmal am Tag einen Sammelbericht (aggregate report). Er enthält keine Mails und keine Empfänger, sondern eine Statistik: Von welcher Server-IP kamen wie viele Mails mit deiner Absenderadresse, und haben sie SPF, DKIM und DMARC bestanden?
Das ist aus zwei Gründen wertvoll:
- Du findest vergessene Absender – Rechnungsprogramm, Shop, Ticketsystem, Kontaktformular – bevor du sie mit einer strengen DMARC-Regel aussperrst.
- Du siehst, ob jemand deine Domain fälscht. Fremde IP-Adressen, die durchfallen, sind meist Spam- oder Phishing-Versuche in deinem Namen.
Daneben gibt es noch Fehlerberichte (ruf=) zu einzelnen Mails. Aus Datenschutzgründen verschicken die großen Anbieter sie aber kaum noch – für die Praxis zählen die Sammelberichte.
Berichte anfordern
Du forderst Berichte mit dem Teil rua= in deinem DMARC-Eintrag an:
_dmarc.beispiel.de. TXT "v=DMARC1; p=none; rua=mailto:dmarc-berichte@beispiel.de"
Lege dafür am besten ein eigenes Postfach an. Je nach Mailvolumen kommen jeden Tag mehrere Berichte, und in deinem normalen Postfach stören sie nur.
Wichtig bei fremden Domains: Sollen die Berichte an eine Adresse einer anderen Domain gehen, etwa an einen Auswertungsdienst, muss diese Domain zustimmen. Sonst verwerfen die Anbieter die Berichte. Die Zustimmung ist ein TXT-Eintrag auf der Empfänger-Domain, z. B. beispiel.de._report._dmarc.auswertung.example mit dem Inhalt v=DMARC1. Seriöse Dienste legen ihn für dich an.
So ist ein Bericht aufgebaut
Ein Bericht ist eine XML-Datei, meist als .zip oder .gz angehängt. Gekürzt sieht er so aus:
<report_metadata>
<org_name>google.com</org_name>
<date_range><begin>1760140800</begin><end>1760227199</end></date_range>
</report_metadata>
<policy_published><domain>beispiel.de</domain><p>none</p></policy_published>
<record>
<row>
<source_ip>203.0.113.10</source_ip>
<count>412</count>
<policy_evaluated><disposition>none</disposition><dkim>pass</dkim><spf>pass</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>beispiel.de</domain><result>pass</result></spf>
</auth_results>
</record>
| Feld | Bedeutung |
|---|---|
org_name | Wer den Bericht schickt, z. B. google.com |
date_range | Zeitraum als Unix-Zeitstempel, meist ein Tag |
source_ip | Server, der die Mails abgeliefert hat |
count | Anzahl der Mails von dieser IP |
policy_evaluated | Ergebnis für DMARC, also mit Alignment, und was mit den Mails passiert ist (disposition) |
auth_results | Rohes SPF- und DKIM-Ergebnis, mit der Domain, die tatsächlich geprüft wurde |
Die Zeilen richtig deuten
Der häufigste Denkfehler: In auth_results steht „pass“, also ist alles gut. Nicht ganz – entscheidend ist policy_evaluated. Dort steht nur dann „pass“, wenn die geprüfte Domain auch zu deiner Absenderadresse passt (Alignment).
| Bild im Bericht | Bedeutung | Was tun? |
|---|---|---|
Eigene Server-IP, DKIM und SPF pass | Alles richtig | Nichts |
IP eines bekannten Dienstes, rohes SPF pass mit Dienst-Domain, DMARC fail | Dienst sendet für dich, aber ohne eigene Domain | Im Dienst die eigene Domain authentifizieren (DKIM-Einträge anlegen) |
| IP eines Dienstes, den du nicht kennst, mit vielen Mails | Vergessener Absender oder Fälschung | Rückwärtsauflösung und Betreiber der IP prüfen, im Team nachfragen |
Viele verschiedene fremde IPs, wenige Mails je IP, alles fail | Fälschungsversuche (Spam, Phishing) | Genau dafür ist p=reject gedacht |
DKIM pass, SPF fail, IP eines Mailanbieters | Weiterleitung: Der Weiterleiter steht nicht in deinem SPF | Normal – DKIM übersteht Weiterleitungen, DMARC besteht trotzdem |
Vom Bericht zu p=reject
- Sammeln: Zwei bis vier Wochen mit
p=noneBerichte empfangen. Monatliche Dienste wie Rechnungsversand tauchen sonst nicht auf. - Absender erfassen: Jede IP mit nennenswertem Volumen einem Dienst zuordnen. Für jeden echten Dienst sorgen, dass DKIM mit deiner Domain signiert.
- Prüfen: Wenn alle echten Absender in
policy_evaluatedbestehen, aufp=quarantinewechseln. - Abschließen: Weitere Wochen beobachten, dann
p=reject. Die Berichte bleiben aktiv – so fällt ein neuer Dienst sofort auf.
Typische Stolperfallen
- Keine Berichte trotz
rua=: Die Adresse liegt auf einer fremden Domain ohne Zustimmungs-Eintrag, oder das Postfach weist große Anhänge ab. - Berichte nur von wenigen Anbietern: Nicht jeder Anbieter verschickt Berichte. Gmail, Yahoo und Outlook.com decken aber den Großteil ab.
- Zahlen weichen voneinander ab: Jeder Anbieter zählt nur die Mails, die bei ihm angekommen sind. Die Summe ist nie dein gesamtes Volumen.
- XML von Hand lesen: Bei mehr als ein paar Absendern unübersichtlich. Ein Auswertungswerkzeug fasst die Berichte nach Absender zusammen.
Ob SPF, DKIM und DMARC für eine einzelne Mail stimmen, zeigt dir der Test auf der Startseite sofort – inklusive Alignment.