Einen DMARC-Bericht lesen, ohne im XML zu ertrinken

Was ein DMARC-Bericht tatsächlich ist

Veröffentlichen Sie einen DMARC-Eintrag mit einer rua=-Adresse, und Mailanbieter beginnen, Ihnen Sammelberichte zu schicken: eine XML-Datei pro Anbieter und Tag, mit jeder IP, die Mail im Namen Ihrer Domain versendet hat, wie viele Nachrichten jede davon verschickt hat und ob SPF und DKIM bestanden und ausgerichtet waren.

Zwei Dinge sollte man wissen, bevor man den ersten öffnet:

• Sammelberichte enthalten keinen Nachrichteninhalt. Keine Betreffzeilen, keine Empfänger, keine Texte. Es sind nach Absender-IP gruppierte Zählungen. Deshalb kann man sie unbedenklich sammeln, und deshalb können sie nicht sagen, welche Nachricht gescheitert ist.
• Sie sind nicht dasselbe wie forensische Berichte. Eine ruf=-Adresse bittet um Fehlerproben pro Nachricht, die Header und manchmal mehr enthalten. Die meisten Anbieter schicken sie aus Datenschutzgründen gar nicht mehr; praktisch heißt DMARC-Sichtbarkeit also: Sammelberichte.

Was sie Ihnen geben, bekommen Sie sonst nirgends: eine Liste von allem auf der Welt, das E-Mail als Ihre Domain versendet, einschließlich der Systeme im eigenen Haus, an deren Einrichtung sich niemand erinnert. Diese Inventur ist der ganze Sinn, und sie ist es, die einen gefahrlosen Wechsel zur Durchsetzung möglich macht.

Wie Sie die Berichte überhaupt bekommen

Ein minimaler Eintrag, der nur Daten sammelt und an der Zustellung nichts ändert:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Er gehört als TXT-Eintrag auf _dmarc.example.com. p=none heißt „wende keine Richtlinie an, sag es mir nur“ – das ist der richtige Startpunkt und kann Ihrer Zustellung nicht schaden. Prüfen Sie mit einem DNS-Abfrage-Tool, dass der Eintrag wirklich live und lesbar ist, bevor Sie auf Berichte warten, die nie kommen.

Zwei praktische Hinweise. Berichte kommen täglich und in Menge, schicken Sie sie also an ein eigenes Postfach statt an Ihres. Und wenn die Berichte an eine Adresse einer anderen Domain gehen sollen, muss diese Domain das mit einem eigenen DNS-Eintrag erlauben – eine fehlende Autorisierung ist der häufigste Grund, warum Berichte stillschweigend ausbleiben.

Das XML lesen: drei Blöcke

Jeder Sammelbericht hat dieselbe Form. Hat man sie einmal gesehen, schreckt sie nicht mehr.

Block 1: wer den Bericht geschickt hat

<report_metadata> nennt die berichtende Organisation und gibt eine Berichtskennung und einen Zeitraum. Auf den Zeitraum kommt es an: Berichte umfassen meist 24 Stunden und treffen ein bis zwei Tage später ein – die IP, die Sie ansehen, hat also in der Vergangenheit gesendet.

Block 2: die Richtlinie, die sie gesehen haben

<policy_published> ist Ihr eigener DMARC-Eintrag, so wie dieser Anbieter ihn gelesen hat: p (Ihre Richtlinie), sp (für Subdomains), pct (der Prozentsatz, den Sie durchsetzen wollten) und die Ausrichtungsmodi. Dieser Block ist eine nützliche Kontrolle: stimmt er nicht mit dem überein, was Sie veröffentlicht zu haben glauben, hat Ihr Eintrag einen Syntaxfehler oder ist noch nicht propagiert.

Block 3: die Zeilen, auf die es ankommt

Dann folgen <record>-Elemente. Jedes ist eine Gruppe von Nachrichten einer IP mit einem Ergebnis, nicht eine einzelne Mail. Jedes enthält ein <row> mit Quell-IP und Anzahl, ein <policy_evaluated> mit dem DMARC-Ergebnis und dem, was der Anbieter tatsächlich getan hat, und ein <auth_results> mit den zugrunde liegenden SPF- und DKIM-Ergebnissen.

Eine Zeile in der Praxis lesen

Gehen Sie in dieser Reihenfolge vor, und die Zeile beantwortet sich selbst:

1. Wem gehört die IP? Schlagen Sie sie nach. Ein bekannter Mail-Dienst heißt: das ist ein Dienst von Ihnen; ein unbekanntes Netz ist das, was Sie untersuchen.
2. Wie viele Nachrichten? Zwei sind Rauschen. Zwanzigtausend sind ein System.
3. Was sagt <policy_evaluated><disposition>? none, quarantine oder reject – was der Anbieter damit gemacht hat.
4. Haben SPF und DKIM bestanden, und waren sie ausgerichtet? Dieses Paar ist die ganze Diagnose – und der nächste Abschnitt.

Die vier Kombinationen und was sie bedeuten

DMARC besteht, wenn entweder SPF oder DKIM besteht und zur sichtbaren From:-Domain ausgerichtet ist. Daraus ergeben sich vier Fälle:

• SPF bestanden + DKIM bestanden. Ihr korrekt eingerichteter Absender. Nichts zu tun.
• SPF bestanden, DKIM gescheitert. Meist ein Dienst, der von einer autorisierten IP sendet, ohne zu signieren. Aktivieren Sie DKIM: SPF allein ist fragil, weil es bricht, sobald eine Nachricht weitergeleitet wird.
• SPF gescheitert, DKIM bestanden. Meist legitime weitergeleitete Mail: die IP des Weiterleiters steht nicht in Ihrem SPF-Eintrag, aber die Signatur hat überlebt. DMARC besteht allein über DKIM – genau so ist es gedacht.
• Beides gescheitert. Entweder ein Absender von Ihnen, der nie eingerichtet wurde, oder jemand, der Sie fälscht. Das zu unterscheiden ist der nächste Abschnitt.

Achten Sie auf eine Falle im XML: ein Ergebnis kann in <auth_results> pass zeigen und DMARC trotzdem scheitern lassen, weil die authentifizierte Domain nicht zur From:-Domain ausgerichtet war. Eine Plattform, die mit ihrer eigenen Domain signiert, erzeugt genau das. Falls das verwirrt: warum ein SPF-Pass kein DMARC-Pass ist erklärt die Ausrichtung im Detail.

Eigene Absender von Spoofing unterscheiden

Die ersten Berichte sehen bei fast allen alarmierend aus, und fast nichts davon ist ein Angriff. Sortieren Sie die scheiternden IPs auf drei Stapel:

• Ihre eigenen, falsch eingerichtet. Ein CRM, ein Rechnungs- oder Ticketsystem, eine Marketingplattform, ein Anwendungsserver. Hinweise: die IP löst zu einem erkennbaren Anbieter auf, das Volumen ist Tag für Tag stabil, und die Nachrichten werden zugestellt. Lösung: richtig autorisieren, am besten mit DKIM.
• Weiterleiter. Geringes Volumen, verstreute IPs, Universitäten und kleine Mailhoster, SPF scheitert, während DKIM besteht. Kein Problem und von Ihrer Seite nicht zu beheben.
• Tatsächliches Spoofing. Unbekannte Netze, oft schubweise, häufig ohne Bezug zu Ihrem Geschäft, beide Prüfungen scheitern. Das Beruhigende: mit einer Richtlinie wird diese Mail bereits abgewiesen, und genau darum geht es.

Die Reihenfolge zählt. Identifizieren Sie den ganzen ersten Stapel, bevor Sie die Richtlinie verschärfen, denn die Durchsetzung macht aus einem falsch eingerichteten Absender von Ihnen nicht zugestellte Mail.

Warum Weiterleitungen wie Angreifer aussehen

Das verwirrt jeden einmal. Eine Mailingliste oder ein Alias leitet Ihre Nachricht über den eigenen Server weiter, Ihr SPF-Eintrag wird also gegen eine IP geprüft, die Sie nie autorisiert haben, und scheitert – zu Recht. Der Bericht zeigt eine unbekannte IP, die in Ihrem Namen sendet und SPF nicht besteht, was sich genau wie Missbrauch liest.

Zwei Merkmale trennen beides. Weitergeleitete Mail besteht meist weiterhin DKIM, weil die Signatur mit der Nachricht reist, also besteht DMARC insgesamt. Und das Volumen ist klein und über viele nicht zusammenhängende IPs verteilt statt konzentriert. Mailinglisten sind die Ausnahme, die beides brechen kann: manche schreiben den Betreff um oder hängen eine Fußzeile an, was die DKIM-Signatur ungültig macht und eine echte Nachricht überall scheitern lässt.

Mit den Berichten zur Durchsetzung kommen

Die Berichte existieren, um diesen Schritt sicher zu machen. Eine praktikable Abfolge:

• Bleiben Sie bei p=none, bis die Berichte langweilig sind – typischerweise ein paar Wochen. Sie warten, bis jeder gefundene legitime Absender autorisiert ist und nichts Neues mehr auftaucht.
• Reparieren Sie Absender, sobald Sie sie finden, bevorzugt mit DKIM. Ein Absender mit DKIM überlebt die Weiterleitung, einer mit nur SPF nicht.
• Wechseln Sie zu p=quarantine, bei Bedarf mit pct= zum schrittweisen Hochfahren. Scheiternde Mail landet im Spam statt zu verschwinden, ein Fehler ist also behebbar.
• Dann p=reject, wenn die Quarantäne ruhig geblieben ist. Ab hier wird gefälschte Mail mit Ihrer Domain tatsächlich abgewiesen.
• Lesen Sie die Berichte auch danach. Ein in einem halben Jahr neu hinzugekommener Dienstleister erscheint als scheiternde IP, und Sie wollen das sehen, bevor Ihnen jemand sagt, seine Rechnungen kämen zurück.

Setzen Sie p=reject nicht am ersten Tag. Das Einzige, was die Durchsetzung sicher macht, ist die Inventur aus den Berichten, und die braucht Wochen, um vollständig zu werden. Der Leitfaden zu SPF, DKIM und DMARC behandelt die Einträge selbst.

Häufige Fehler

• Zu p=reject springen, ohne Berichte zu lesen. Das vergessene System ist meist das, das Ihre Kunden abrechnet.
• Jede Zeile als eine Nachricht lesen. Eine Zeile ist eine Gruppe von Nachrichten einer IP mit einem Ergebnis.
• Jede scheiternde IP für einen Angreifer halten. Die meisten frühen Fehler sind eigene Dienste und gewöhnliche Weiterleitungen.
• Annehmen, ein pass in auth_results heiße, DMARC habe bestanden. Ohne Ausrichtung zur From:-Domain heißt es das nicht.
• Berichte an ein menschlich betreutes Postfach schicken. Sie kommen täglich von dutzenden Anbietern. Nehmen Sie eine eigene Adresse.
• Die Subdomain-Richtlinie vergessen. Ohne sp= erben Subdomains p, was während einer Einführung unerwünscht sein kann.
• Nur SPF reparieren. SPF bricht bei Weiterleitungen; DKIM ist das, was DMARC hindurchträgt.
• Die Berichte abschalten, sobald reject erreicht ist. Genau dann werden sie zum Frühwarnsystem.

Kurzfassung

Ein DMARC-Sammelbericht ist eine tägliche XML-Liste jeder IP, die als Ihre Domain sendet, mit Zählungen und SPF-/DKIM-Ergebnissen – ohne Nachrichteninhalt. Lesen Sie jede Zeile in vier Schritten: IP bestimmen, Volumen ansehen, Disposition lesen, dann prüfen, ob SPF oder DKIM bestanden hat und ausgerichtet war. Rechnen Sie damit, dass die meisten frühen Fehler eigene, nicht eingerichtete Dienste und gewöhnliche Weiterleitungen sind und kein Spoofing, reparieren Sie Absender nach Möglichkeit mit DKIM, und wechseln Sie von p=none zu Quarantäne und dann zu reject erst, wenn die Berichte ruhig geworden sind. Prüfen Sie mit dem kostenlosen DNS-Lookup-Tool, ob Ihr _dmarc-Eintrag veröffentlicht und lesbar ist, und wenn ein SPF-Ergebnis im Bericht widersprüchlich aussieht, erklärt der SPF-Leitfaden den Grund.

Verwandte Tools und Leitfäden:

• DNS-Abfrage – Fragen Sie A-, AAAA-, MX-, TXT-, NS- und weitere DNS-Einträge mit Werten und TTL sowie Reverse-DNS ab.
• Warum Ihr SPF-Eintrag immer wieder scheitert – und wie Sie es beheben – Wie Sie Ihren SPF-Eintrag lesen

Häufige Fragen