DMARC Report lesen und richtig auswerten

Was ist ein DMARC Report?

Ein DMARC Report ist eine Rückmeldung, die ein empfangender Mailserver an den Domaininhaber schickt. Sie betrifft E-Mails, die vorgaben, von dieser Domain zu stammen. Die von der IETF veröffentlichte DMARC-Spezifikation beschreibt zwei Arten. Aggregate Reports gehen an die Adresse im rua-Tag Ihres DMARC-Eintrags. Sie fassen alle Nachrichten zusammen, die der Empfänger gesehen hat, gruppiert nach sendender IP und Ergebnis. Failure Reports (oft Forensic Reports genannt) gehen an die Adresse im ruf-Tag und beschreiben einzelne Nachrichten, die durchgefallen sind. Reports erhalten Sie nur, wenn Ihr Eintrag sie anfordert. Ein Eintrag wie v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com veröffentlicht die Policy und fordert Aggregate Reports an. Ohne rua wenden Empfänger Ihre Policy trotzdem an, sagen Ihnen aber nichts darüber. Der Report zeigt, was der jeweilige Empfänger gesehen hat, nicht alles, was Sie verschickt haben. Eine Domain, die nur an Nutzer von Gmail und Microsoft mailt, bekommt Reports von genau diesen beiden Empfängern und von niemandem sonst. Falls Sie noch keinen Eintrag veröffentlicht haben, legen Sie zuerst den TXT-Eintrag unter _dmarc an.

Wie oft kommen DMARC Reports und in welchem Format?

Laut DMARC-Spezifikation kann der Domaininhaber mit dem ri-Tag ein Berichtsintervall anfordern. Der Standardwert ist ein Tag. Empfänger dürfen unabhängig von Ihrer Angabe bei täglichen Reports bleiben, und die meisten tun das auch. Jeder Report kommt als E-Mail mit einem komprimierten Anhang, meist gzip (.xml.gz) oder zip, der eine XML-Datei enthält. Der Dateiname nennt in der Regel die Domain des Empfängers, Ihre Domain sowie Start- und End-Zeitstempel. Die Zeitstempel sind Unix-Epoch-Sekunden in UTC. Ein Report, der „um Mitternacht beginnt“, beginnt also nicht unbedingt um Mitternacht Ihrer Ortszeit. Ein Detail sorgt oft für Verwirrung, wenn Reports an eine andere Domain gehen, etwa an einen Monitoring-Dienst. Die DMARC-Spezifikation verlangt, dass die empfangende Domain einen TXT-Eintrag unter yourdomain.com._report._dmarc.theirdomain.com veröffentlicht. Damit bestätigt sie, dass sie Ihre Reports annimmt. Fehlt dieser Eintrag, verwerfen spezifikationstreue Empfänger die externe rua-Adresse kommentarlos, und Ihr Report-Postfach bleibt einfach leer.

DMARC Aggregate Report auswerten: Feld für Feld

Ein Aggregate Report besteht aus drei Teilen. report_metadata nennt den Absender des Reports und den Zeitraum. policy_published zeigt Ihren DMARC-Eintrag so, wie der Empfänger ihn gelesen hat. Dazu kommen ein oder mehrere record-Elemente, und dort steckt die eigentliche Arbeit.

XML-Element	Was es enthält	Worauf Sie achten
report_metadata / org_name, date_range	Der meldende Empfänger sowie Start- und End-Zeitstempel (Unix)	Welchen Postfachanbieter und welchen Tag der Report abdeckt
policy_published / p, sp, pct, adkim, aspf	Ihre Policy, Subdomain-Policy, der Prozentsatz und der Alignment-Modus (r relaxed, s strict)	Ob das dem entspricht, was Sie veröffentlicht zu haben glauben. Ein Tippfehler im DNS fällt hier auf
row / source_ip	Die IP, die die Nachrichten zugestellt hat	Per Reverse Lookup den Dienst bestimmen: Ihr Workspace, Brevo, ein CRM oder unbekannt
row / count	Wie viele Nachrichten von dieser IP dasselbe Ergebnis hatten	Zeilen nach Volumen gewichten. Eine einzelne Nachricht von einer ungewöhnlichen IP ist meist eine Weiterleitung
policy_evaluated / disposition	Was der Empfänger getan hat: none, quarantine oder reject	Sollte Ihrem p= entsprechen, sofern der Empfänger es nicht übersteuert hat
policy_evaluated / dkim, spf	Das DMARC-aligned Ergebnis: pass nur, wenn die authentifizierte Domain zu Ihrer From-Domain passt	Mindestens eins von beiden muss bestehen, damit DMARC besteht
identifiers / header_from	Die Domain in der sichtbaren From-Adresse	Subdomains erscheinen hier gesondert
auth_results / dkim (domain, selector, result)	Die rohe DKIM-Prüfung, einschließlich Signaturdomain d= und Selector	Ein pass für die Domain eines Anbieters zählt nicht für DMARC
auth_results / spf (domain, result)	Die rohe SPF-Prüfung auf der Domain des Envelope-Absenders (Return-Path)	Ein pass für eine Bounce-Domain, die Ihnen nicht gehört, ist nicht aligned

Der häufigste Lesefehler: auth_results für das Urteil zu halten. Das ist es nicht. Nehmen Sie eine Zeile, in der auth_results spf pass zeigt, policy_evaluated aber spf fail. SPF hat für irgendeine Domain bestanden, meist für die eigene Bounce-Domain eines Versanddienstes, doch diese Domain passt nicht zu Ihrer From-Domain. Unter DMARC zählt SPF dann nichts, und die Nachricht besteht DMARC nur, wenn DKIM aligned ist.

Was tun mit DMARC Reports?

Reports helfen nur, wenn jede Zeile in einer Kategorie landet. Gruppieren Sie nach source_ip, summieren Sie count je Gruppe und gehen Sie dann diese Fälle durch:

1. 1 Eigener Dienst, aligned pass bei DKIM oder SPF: erledigt. Notieren Sie IP-Bereich und DKIM-Selector, damit Sie ihn beim nächsten Mal wiedererkennen.
2. 2 Eigener Dienst, aligned fail: Der Dienst versendet im Namen Ihrer Domain, ohne für sie zu signieren. Die übliche Ursache ist, dass DKIM noch mit der d=-Domain des Anbieters signiert, weil Ihr eigener DKIM-Schlüssel nie veröffentlicht oder aktiviert wurde. Korrigieren Sie das DNS, bevor Sie p= anfassen.
3. 3 Bekannter Weiterleiter oder Mailingliste, SPF fail, DKIM manchmal pass: Weiterleitung ändert die zustellende IP, dadurch bricht SPF, und Listen-Footer oder Betreff-Tags können auch die DKIM-Signatur zerstören. Von Ihrer Seite lässt sich das nicht beheben. Kleine Mengen davon sind normal.
4. 4 Unbekannte IP, beides fail, nennenswerte Menge: Jemand spooft Ihre Domain, oder ein Team hat ein Tool gekauft, von dem niemand wusste. Fragen Sie intern nach, bevor Sie von Missbrauch ausgehen.
5. 5 Zeilen unter header_from-Subdomains, die Sie nicht nutzen: Kandidaten für eine sp=reject-Policy, sobald Ihre Hauptdomain sauber ist.

Der Wechsel von p=none zu quarantine ist erst sicher, wenn jede legitime Quelle eine Weile in der ersten Kategorie stand. Verschärfen Sie, während ein CRM oder Rechnungstool noch in Kategorie zwei steckt, landen dessen E-Mails im Spam oder werden abgewiesen. Die Reports der letzten Wochen zeigen Ihnen, wo Sie stehen. Lesen Sie, wie DKIM, DMARC und SPF zusammenhängen, bevor Sie einen Eintrag ändern. Was gerade live ist, prüfen Sie mit dem SPF-, DKIM- und DMARC-Checker.

DMARC mit Google Workspace: Was die Reports zeigen

Läuft Ihre Domain auf Google Workspace, sollten Sie zwei Rollen trennen. Als Absender liegt Ihr DMARC-Eintrag bei Ihrem DNS-Hoster als TXT-Eintrag unter _dmarc.yourdomain.com. Die Workspace-Admin-Konsole legt ihn nicht für Sie an. E-Mails aus Workspace-Postfächern erscheinen in den Reports anderer Empfänger mit Google-IP-Bereichen als source_ip. Haben Sie Workspace-DKIM aktiviert, tauchen sie mit einer DKIM-Signatur mit dem Selector google und d= Ihrer Domain auf, dem Standard-Selector laut Googles Admin-Dokumentation. Wurde DKIM zwar generiert, aber nie mit „Authentifizierung starten“ eingeschaltet, zeigen diese Zeilen eine Signatur einer Google-Domain und ein aligned DKIM fail. Als Empfänger schickt Gmail Ihnen Aggregate Reports mit org_name google.com. Googles Workspace-Hilfeartikel „Über DMARC-Berichte“ beschreibt Aggregate Reports. Auf Failure Reports (ruf) von Gmail sollten Sie nicht setzen. Ein verbreitetes Setup: E-Mails aus Workspace plus ein separater Versanddienst wie Brevo auf derselben Domain. Dann sehen Sie zwei Gruppen von Zeilen, und jede braucht ihr eigenes aligned DKIM. Den Eintrag selbst und die Reihenfolge der Einführung behandelt unser Leitfaden zu DMARC-Eintrag und Rollout in Google Workspace.

Mit welchem Tool DMARC Reports auswerten?

Rohes XML zu lesen reicht bei einer Domain mit zwei Absendern und wenig Volumen. Sobald mehrere Empfänger täglich melden, brauchen Sie etwas, das die Dateien parst und die Zeilen gruppiert. Die folgenden Optionen werden in den aktuellen Suchergebnissen zu diesem Thema genannt. Der Vergleich beschränkt sich darauf, wie die jeweilige Art von Lösung funktioniert, nicht auf kontoabhängige Limits.

Option	Funktionsweise	Geeignet für	Grenzen
Rohes XML im Texteditor	Anhang entpacken und die record-Elemente von Hand lesen	Eine Domain, ein oder zwei Versanddienste, ein schneller Check	Kein Verlauf über die Zeit, keine Gruppierung über Empfänger hinweg. Ab einer Handvoll Zeilen mühsam
MxToolbox DMARC Report Analyzer	Einen einzelnen Report einfügen oder hochladen und eine geparste Ansicht erhalten (laut Seitentitel ein XML-Parser)	Einen gerade erhaltenen Report verstehen	Arbeitet Report für Report und sammelt Ihren täglichen Eingang nicht selbst
Gehostetes DMARC-Monitoring (z. B. Postmark DMARC, EasyDMARC, PowerDMARC, dmarcreport.com)	Sie richten rua auf die Adresse des Anbieters, der Reports über die Zeit sammelt, parst und zusammenfasst	Laufende Überwachung mehrerer Absender und Empfänger vor dem Wechsel zu quarantine	Der Anbieter erhält Ihre Report-Daten, und eine externe rua braucht den Autorisierungseintrag des Anbieters. Tarife und Funktionen unterscheiden sich, prüfen Sie die Dokumentation des jeweiligen Anbieters
Eigenes Postfach plus Skript	rua zeigt auf ein Postfach unter Ihrer Kontrolle, und Sie parsen das XML mit eigenem Code	Teams, die Report-Daten im Haus behalten wollen	Parsing und Speicherung bauen und pflegen Sie selbst

Egal, wofür Sie sich entscheiden: Keines dieser Tools ändert, was der Empfänger entscheidet. Sie zeigen Ihnen, was passiert ist. Korrigiert wird weiterhin in Ihrem DNS und in den Domaineinstellungen des jeweiligen Versanddienstes.

So erscheint der Versand über EmailFlow OS in Ihren DMARC Reports

EmailFlow OS arbeitet auf Ihrer eigenen Infrastruktur, deshalb taucht der Traffic in Ihren Reports als Ihr eigener Traffic auf. Sie nehmen ein einziges Video auf und laden es in EmailFlow OS hoch. Dann verbinden Sie Ihr Brevo-Konto und Ihre Versanddomain und importieren Ihre Prospect-Liste in EmailFlow OS. EmailFlow OS personalisiert diese eine Aufnahme für jeden einzelnen Empfänger, nicht pro Unternehmen, und verschickt jede Version aus Ihrem eigenen Postfach über Ihr eigenes Brevo-Konto und Ihre eigene Versanddomain. Einen geteilten Plattform-Absender gibt es nicht. In den Aggregate Reports erscheinen diese Sendungen daher unter Ihrer header_from-Domain, mit den Versand-IPs von Brevo als source_ip. Ob sie DMARC bestehen, hängt von dem DKIM-Schlüssel ab, den Sie für Brevo auf Ihrer Domain veröffentlicht haben. Ist er eingerichtet und aligned, landen die Zeilen in Kategorie eins. Wenn nicht, landen sie wie jeder andere falsch konfigurierte Dienst in Kategorie zwei. Mit Ihren Reports prüfen Sie das, bevor Sie in größerem Umfang versenden. Mehr dazu, wie EmailFlow OS personalisierte KI-Video-E-Mails von Ihrer eigenen Domain verschickt, finden Sie auf der Startseite.

Häufige Fragen

? Warum bekomme ich keine DMARC Reports?

Es gibt drei übliche Ursachen. Ihr DMARC-Eintrag hat kein rua-Tag. Die rua-Adresse liegt auf einer anderen Domain, die den Autorisierungs-TXT-Eintrag nicht veröffentlicht hat, den die DMARC-Spezifikation für externe Report-Adressen verlangt. Oder der Eintrag ist fehlerhaft, zum Beispiel zwei v=DMARC1-Einträge unter _dmarc, was Empfänger so behandeln, als gäbe es gar keinen Eintrag. Reports kommen meist täglich, warten Sie nach einer Korrektur also mindestens einen Tag.

? Was ist der Unterschied zwischen rua- und ruf-Reports?

rua-Reports sind Aggregate Reports: tägliche XML-Zusammenfassungen, gruppiert nach sendender IP und Ergebnis, ohne Nachrichteninhalt. ruf-Reports sind Failure Reports über einzelne Nachrichten, die durchgefallen sind, und können Header oder Teile der Nachricht enthalten. Aggregate Reports werden weithin verschickt. Viele große Empfänger senden kaum oder keine Failure Reports, unter anderem wegen der enthaltenen personenbezogenen Daten.

? Heißt ein DMARC Report, dass meine E-Mail im Posteingang gelandet ist?

Nein. Das Feld disposition zeigt nur, ob der Empfänger Ihre DMARC-Policy angewendet hat: none, quarantine oder reject. Eine Nachricht mit disposition none und aligned pass kann trotzdem wegen Reputation, Inhalt oder Beschwerden im Spam landen. DMARC Reports betreffen die Authentifizierung, nicht die Platzierung im Posteingang. Dafür brauchen Sie separate Werkzeuge wie Google Postmaster Tools oder Seed-Tests.

? Ist ein DMARC fail im Report immer Spoofing?

Nein. Fehler entstehen auch durch Weiterleitungen, die SPF und manchmal DKIM brechen. Sie entstehen außerdem durch Mailinglisten, die Nachrichten verändern, und durch eigene Dienste, die ohne einen auf Ihre Domain abgestimmten DKIM-Schlüssel versenden. Prüfen Sie zuerst source_ip und die DKIM-d=-Domain. Gehen Sie nur dann von Spoofing aus, wenn die IP zu keinem Ihrer Dienste und keinem bekannten Weiterleiter gehört.