DMARC-Berichte auswerten und sicher auf p=reject umstellen

DMARC angelegt, rua= eingetragen, und seitdem kommt jeden Tag ein ZIP-Anhang mit XML darin. Die meisten legen einen Ordner an und schauen nie wieder hinein.

Damit fehlt aber genau der Teil, der die Umstellung erst möglich macht. p=none schützt nichts, und p=reject ohne Vorbereitung kostet echte Mail. Zwischen beidem liegen die Berichte.

Die kurze Antwort

In den Berichten steht, wer in eurem Namen sendet und ob es die Prüfung besteht. Wenn über mehrere Wochen jede eigene Quelle besteht und alles Übrige fremd ist, könnt ihr verschärfen. Vorher nicht.

Ein Bericht deckt einen Tag ab, kommt von jedem größeren Empfänger einzeln und ist maschinenlesbar, nicht menschenfreundlich. Verstehen kann man ihn trotzdem, es sind vier Angaben, die zählen.

Was in so einer Datei wirklich steht

Entpackt sieht ein Bericht ungefähr so aus, hier auf das Wesentliche gekürzt:

<record>
  <row>
    <source_ip>40.107.22.11</source_ip>
    <count>34</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>firma.de</header_from>
  </identifiers>
</record>

Übersetzt: Von dieser IP kamen an diesem Tag 34 Mails mit firma.de als sichtbarem Absender. DKIM hat gepasst, SPF nicht. Zugestellt wurde trotzdem, weil p=none steht.

Vier Felder genügen zum Verstehen:

disposition ist das Ergebnis eurer Richtlinie, nicht der Prüfung. Bei p=none steht dort immer none, auch bei einem klaren Durchfall. Wer nur auf diese Spalte schaut, hält eine offene Domain für sicher.

Die drei Sorten Absender, die ihr finden werdet

Sortiert die IP-Adressen nach Menge, dann bildet sich fast immer dasselbe Muster:

Erstens die bekannten eigenen Systeme. Postfach, Newsletter, Shop. Die sollen bestehen, und meistens tun sie das. Wenn nicht, fehlt eine Angabe im SPF-Eintrag oder das System signiert nicht mit DKIM.

Zweitens die vergessenen eigenen Systeme. Das ist der eigentliche Ertrag der Beobachtungsphase. Ein Ticketsystem von 2019, der Multifunktionsdrucker, der Scans verschickt, ein Monitoring-Dienst, das Buchhaltungsprogramm, die Agentur, die für euch einen Serienbrief rausgeschickt hat. Jede dieser Quellen fällt bei p=reject still aus, und niemand verbindet die ausbleibende Mail mit einem DNS-Eintrag, den jemand vor drei Monaten geändert hat.

Drittens tatsächlich Fremde. Einzelne IPs, kleine Zahlen, oft aus Netzbereichen, die mit eurem Geschäft nichts zu tun haben. Die dürfen durchfallen, dafür ist der Eintrag da.

Die Trennung zwischen der zweiten und der dritten Gruppe ist die ganze Arbeit. Sie lässt sich nicht raten, nur nachschlagen: IP im Whois nachschauen, im Zweifel intern fragen, wer diesen Dienst benutzt.

Der Fall, der am meisten Verwirrung stiftet

Manchmal steht in einer Zeile spf: pass und dkim: pass, und die Mail zählt trotzdem als durchgefallen. Das liegt nicht an einem Fehler im Bericht, sondern an der Ausrichtung: SPF und DKIM können für die Domain des Dienstleisters bestehen, während eure Kunden firma.de im Absender sehen. DMARC verlangt, dass eine der beiden Domains zur sichtbaren Adresse passt.

Woran man es im Bericht erkennt: Im Abschnitt auth_results steht die Domain, für die geprüft wurde. Weicht sie von header_from ab, ist die Ausrichtung das Problem und nicht die Prüfung selbst. Was dann zu tun ist, steht ausführlich in SPF, DKIM und DMARC: was die drei wirklich tun.

Zwei Wege, die Berichte lesbar zu machen

Von Hand geht es bei kleinen Domains. Anhang entpacken, XML im Browser öffnen, nach source_ip und count sortieren. Bei drei Berichten am Tag und zwei sendenden Systemen reicht das völlig.

Ab einigen tausend Mails pro Monat lohnt ein Auswertungsdienst. Es gibt kostenlose und kostenpflichtige. Der Unterschied ist nicht die Analyse, sondern die Darstellung: eine Tabelle statt zwanzig XML-Dateien.

Was ihr dabei bedenken solltet: Ihr gebt einem Dritten Auskunft darüber, wer für euch Mail verschickt. Das ist selten hochsensibel, aber es ist eine Auftragsverarbeitung, und die gehört in eure Datenschutzhinweise wie jeder andere Dienstleister auch.

Eine dritte Möglichkeit, die oft übersehen wird: Die Berichtsadresse muss kein eigenes Postfach sein. Ein Alias, der in einen Ordner sortiert, genügt für die ersten Wochen.

Die Berichtsadresse in einer fremden Domain

Wenn rua= auf eine Adresse zeigt, die nicht zu der geprüften Domain gehört, braucht es eine Freigabe auf der anderen Seite. In der Zone der Empfängerdomain muss ein TXT-Eintrag stehen:

firma.de._report._dmarc   TXT   v=DMARC1

Fehlt er, verwerfen die meisten Versender den Bericht kommentarlos. Das ist die häufigste Ursache dafür, dass jemand DMARC korrekt eingerichtet hat und trotzdem nie einen Bericht bekommt. Nachzulesen in RFC 7489, Abschnitt 7.1.

Wann ihr verschärfen könnt

Drei Bedingungen, alle drei müssen erfüllt sein:

1. Jede eigene sendende Quelle ist identifiziert und besteht entweder SPF oder DKIM, mit passender Ausrichtung.
2. Über mindestens zwei, besser vier Wochen ist keine neue eigene Quelle mehr aufgetaucht. Monatsläufe wie Rechnungen oder Newsletter brauchen einen vollen Zyklus, sonst übersieht man sie.
3. Weiterleitungen sind bedacht. Sie brechen SPF zwangsläufig, nur DKIM überlebt sie. Wer info@ auf mehrere Postfächer verteilt, muss DKIM überall funktionierend haben.

Dann geht es auf p=quarantine, und die Berichte laufen weiter. Wenn nach zwei weiteren Wochen nichts Eigenes im Spam landet, folgt p=reject.

Der Zwischenschritt ist nicht Bürokratie. Bei quarantine landet eine fälschlich abgelehnte Mail im Spam-Ordner und ist auffindbar. Bei reject ist sie weg.

Wo ihr gerade steht

Der kostenlose DMARC-Check zeigt in zehn Sekunden, ob eine Berichtsadresse hinterlegt ist, welche Richtlinie gilt und ob die externe Freigabe fehlt. Ohne Anmeldung.

Wenn jemand die Berichte turnusmäßig mitlesen soll: Genau dafür ist unsere Wartung gedacht, denn nach dem ersten Monat erinnert sich sonst niemand mehr daran. Erstgespräch vereinbaren, 30 Minuten, kostenlos.