DMARC-Berichte lesen: wer E-Mails in Ihrem Namen sendet

Sobald Ihre Domain einen DMARC-Eintrag mit einer rua=-Adresse veröffentlicht, schicken Ihnen die großen Postfachanbieter jeden Tag einen Bericht: eine komprimierte XML-Datei pro Anbieter mit jedem Server, der E-Mails im Namen Ihrer Domain verschickt hat, und ob diese die Prüfungen bestanden haben. Die meisten öffnen einen, sehen eine Wand aus XML und öffnen nie wieder einen. Schade, denn diese Dateien beantworten die einzige Frage, die vor dem Durchsetzen von DMARC zählt: Wer sendet in unserem Namen, und sind alle legitim?

Woher die Berichte kommen

Der Eintrag, der sie anfordert, sieht so aus:

_dmarc.ihre-domain.de.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@ihre-domain.de"

Google, Microsoft (Outlook.com und Microsoft 365), Yahoo, GMX, WEB.DE, Mail.ru und viele andere halten sich daran. Jeder schickt einen Sammelbericht pro Tag, meist als .zip- oder .gz-Anhang. Ein kleines Unternehmen erhält fünf bis fünfzehn am Tag. Liegt die Adresse auf einer anderen Domain (etwa bei einem Berichtsdienst), muss diese Domain einen Autorisierungseintrag veröffentlichen, sonst senden die Anbieter nichts; der DMARC-Check zeigt, ob sie das tut.

Was in einem Bericht steht

Unter einem kurzen Kopf (wer berichtet, für welchen Zeitraum, welche Richtlinie er gesehen hat) besteht der Bericht aus Zeilen. Jede Zeile nennt:

source IP: den Server, der die E-Mails beim Anbieter eingeliefert hat;
count: wie viele Nachrichten dieser Server im Zeitraum geschickt hat;
disposition: was der Anbieter damit getan hat (none, quarantine, reject);
die Ergebnisse von DKIM und SPF, roh und ausgerichtet (aligned), und die Domains, für die geprüft wurde;
header from: die Domain der sichtbaren Absenderadresse.

Entscheidend ist das ausgerichtete Ergebnis. DMARC besteht, wenn SPF oder DKIM für eine Domain besteht, die zur From-Adresse passt. Ein über Mailchimp verschickter Newsletter kann SPF für mcsv.net bestehen und DMARC trotzdem nicht, weil mcsv.net nicht Ihre Domain ist.

Die Zeilen in drei Stapel sortieren

Öffnen Sie Ihre Berichte mit der kostenlosen Anwendung DMARC-Berichte lesen (alles bleibt in Ihrem Browser) und sortieren Sie die Absender.

1. Eigene Dienste, die bestehen. Ihr Postfachanbieter (Google Workspace, Microsoft 365), Ihr CRM, Ihre Rechnungssoftware, alle mit ausgerichtetem DKIM. Nichts zu tun.

2. Eigene Dienste, die scheitern. Diesen Stapel müssen Sie vor dem Durchsetzen abarbeiten. Typische Fälle:

ein Newsletter-Tool oder CRM, das mit seiner eigenen Domain signiert statt mit Ihrer: richten Sie die Authentifizierung der eigenen Domain ein (zwei oder drei CNAME-Einträge, die der Dienst vorgibt), dann ist DKIM ausgerichtet;
ein Kontaktformular der Website, das über den Server des Hosters sendet: lassen Sie es über Ihren echten Mailanbieter senden, oder nehmen Sie den Hoster in SPF auf und aktivieren Sie DKIM;
ein vergessener alter Dienst, der noch Rechnungen verschickt: konfigurieren oder abschalten.

3. Fremde. Server in Ländern, in denen Sie nicht tätig sind, private Anschlüsse, unbekannte Hosts, alle gescheitert. Das ist Fälschung, oder irgendwo ein falsch konfigurierter Server, der sich für Sie hält. Das beheben Sie nicht, Sie blockieren es: mit p=quarantine und dann p=reject, sobald Stapel 2 leer ist.

Weiterleitungen: der Fehlalarm

Eine Nachricht an einen Kunden, der alles in ein anderes Postfach weiterleitet, kommt beim zweiten Anbieter vom Server des Kunden an. SPF scheitert (der Server des Kunden steht nicht in Ihrem SPF), DKIM übersteht die Weiterleitung aber meist, und DMARC besteht weiter. Zeilen mit gescheitertem SPF, bestandenem DKIM und einem bekannten Weiterleitungsanbieter sind normal. Zeilen, bei denen nach einer Weiterleitung beides scheitert, stammen meist von Mailinglisten, die Nachrichten umschreiben; sie sind selten, und DMARC durchzusetzen bleibt richtig.

Wie es gesund aussieht

Nach einigen Wochen Arbeit zeigt eine gesunde Domain:

mehr als 99 Prozent des Volumens bestehen DMARC mit ausgerichtetem DKIM;
jede scheiternde Quelle ist entweder unbekannt (Fälschung) oder eine Weiterleitung;
kein eigener Dienst mehr in Stapel 2.

Dann ist es Zeit für die nächsten Schritte, wie in Von p=none zu p=reject beschrieben.

Warum niemand sie weiter liest

Die Berichte landen als Anhänge in einem gemeinsamen Postfach, jeden Tag, für immer. Sie von Hand zu lesen, hält niemand durch. Perimetry Cloud gibt jeder Domain eine eigene Berichtsadresse, liest jeden Bericht bei Eingang, gruppiert die Absender nach Dienst (Google, Microsoft, Mailchimp …) und meldet sich, wenn eine neue Quelle auftaucht oder sich der Anteil scheiternder E-Mails ändert. Es sagt Ihnen auch, wann Sie die Richtlinie gefahrlos verschärfen können, und um wie viel.