DMARC: von p=none zu p=reject wechseln, ohne legitime E-Mails zu blockieren

Eine Domain kann SPF, DKIM und DMARC einwandfrei konfiguriert haben und in der Praxis dennoch so leicht zu fälschen sein wie eine Domain ganz ohne Authentifizierung. Der Grund passt in drei Zeichen: p=none. Solange die Richtlinie auf diesem Wert bleibt, melden die empfangenden Server den Missbrauch, ohne ihn je zu blockieren. Die Verschärfung auf quarantine und dann reject ist der einzige Schritt, der wirklich schützt, und Aggregatberichte sind das Mittel, um ihn zu gehen, ohne die eigenen Nachrichten versehentlich in den Spam-Ordner zu schicken.

#Was p=none schützt und was nicht

DMARC (RFC 7489) fügt zu SPF und DKIM zwei Garantien hinzu. Die erste ist die Ausrichtung: Die im From:-Header sichtbare Domain muss mit der von SPF oder DKIM geprüften Domain übereinstimmen. Die zweite ist eine veröffentlichte Richtlinie, die dem empfangenden Server sagt, was mit einer nicht ausgerichteten Nachricht zu tun ist. Diese Richtlinie trägt das p-Tag.

Mit p=none lautet die Anweisung an die Empfänger eindeutig: beobachten, aber nicht blockieren. Eine Nachricht, die die Domain fälscht, passiert damit genau wie vor der Einführung von DMARC. Der einzige Gewinn in dieser Phase ist Sichtbarkeit: Die Domain beginnt, Berichte darüber zu erhalten, wer in ihrem Namen sendet. Dieser Erfassungsschritt ist unverzichtbar, doch ihn mit Schutz zu verwechseln, ist der häufigste Fehler bei der Zustellbarkeit.

#Anatomie eines Aggregatberichts

Ein Aggregatbericht (das rua-Tag) ist eine XML-Datei, die ein empfangender Server standardmäßig einmal täglich für eine bestimmte Domain erzeugt. Er enthält keinerlei Nachrichteninhalt: nur Quell-IP-Adressen, Mengen und das Ergebnis der Auswertung von SPF, DKIM und DMARC. Hier ein auf das Wesentliche gekürzter Auszug.

<record>
  <row>
    <source_ip>203.0.113.24</source_ip>
    <count>148</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>exemple.fr</header_from>
  </identifiers>
  <auth_results>
    <spf><domain>mailer.prestataire.com</domain><result>pass</result></spf>
  </auth_results>
</record>

Dieser Block beschreibt 148 Nachrichten von einer einzigen IP, die sich als exemple.fr ausgeben. SPF besteht, aber auf der Domain mailer.prestataire.com: Es gibt Authentifizierung, keine Ausrichtung. DKIM scheitert. DMARC-Ergebnis: nicht ausgerichtet. Unter p=none bleibt die Disposition none und die Nachricht geht trotzdem durch. Unter p=reject würden diese 148 Nachrichten abgewiesen. Die ganze Frage ist, ob sie legitim sind.

Ein Aggregatbericht sagt nicht, ob eine E-Mail ankam: Er sagt, wer im Namen der Domain schreiben darf und wer davon abweicht.

#Berichte lesen, um scheiternde legitime Absender zu finden

Von Hand werden die Berichte schon bei wenigen Anbietern unlesbar. Der nützliche Reflex ist nicht, alles zu prüfen, sondern eine einzige Kategorie zu isolieren: die nicht ausgerichteten Quellen mit hohem Volumen. Sie sind es, die bei der Verschärfung brechen, wenn sie legitim sind, oder die den Betrug belegen, wenn sie es nicht sind. Ein Skript von wenigen Zeilen genügt, um diese Liste aus einem entpackten Bericht zu ziehen.

import xml.etree.ElementTree as ET

tree = ET.parse("rapport_agrege.xml")
for rec in tree.findall(".//record"):
    dkim = rec.findtext("row/policy_evaluated/dkim")
    spf = rec.findtext("row/policy_evaluated/spf")
    if dkim != "pass" and spf != "pass":          # non aligné sur les deux
        ip = rec.findtext("row/source_ip")
        count = rec.findtext("row/count")
        frm = rec.findtext("identifiers/header_from")
        print(f"{count:>6}  {ip:

Jede Ausgabezeile ist eine zu treffende Entscheidung: Gehört diese IP zu einem legitim genutzten Dienst (Marketing-Router, Rechnungsstellung, CRM, Formular der Website) oder zu einem Dritten, der die Domain fälscht? Für Erstere lautet die Antwort, deren SPF zu korrigieren oder deren DKIM-Signatur zu aktivieren, bevor verschärft wird. Für Letztere ist die Verschärfung genau das Ziel: Sie werden blockiert.

#Der Hochlauf: von none zu reject

Der Wechsel geschieht nie in einem Sprung. Er folgt einer Rampe, bei der jede Stufe lange genug gehalten wird, damit ein Aggregatbericht das Fehlen scheiternder legitimer Absender bestätigt. Das pct-Tag wendet die Richtlinie historisch nur auf einen Bruchteil der Nachrichten an, um die Wirkung vor der Verallgemeinerung zu beobachten.

; palier intermédiaire : quarantine sur un quart du trafic
_dmarc.exemple.fr.  IN  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; adkim=s; aspf=s"

Ein realistisches Tempo hält jede Stufe ein bis zwei Wochen: p=none, dann p=quarantine; pct=25, dann pct=100, dann p=reject. Die laufende Überarbeitung der Spezifikation neigt dazu, von pct abzuraten, zugunsten eines schrittweisen Ausrollens über Subdomains und einer eigenen Richtlinie über das sp-Tag; das Prinzip bleibt gleich, nur die Mechanik der Stufe ändert sich.

#Fehlberichte (ruf) und Feedback-Schleifen

Neben den Aggregatberichten fordert das ruf-Tag Fehlberichte an, Nachricht für Nachricht, im ARF-Format (RFC 5965). Sie sind genauer, werden aber selten gesendet: Die meisten großen Empfänger unterdrücken sie, um keine personenbezogenen Daten weiterzugeben. Sich auf sie zu verlassen bedeutet, auf Sichtbarkeit zu verzichten.

#Was zu behalten ist

DMARC schützt erst ab quarantine. Der Weg zu reject ist eine Frage des Lesens, nicht der Konfiguration: Jede Stufe wartet, bis ein Aggregatbericht bestätigt, dass keine legitime Quelle ausfällt. Die Abfolge ist stets dieselbe: bei none erfassen, die in den Berichten erkannten echten Absender ausrichten, in Stufen verschärfen, prüfen, abweisen. Eine Domain, die monatelang auf p=none bleibt, wird nicht abgesichert: Sie wartet.

#Zum Weiterlesen

DMARC-Spezifikation und das Schema der Aggregatberichte: RFC 7489 (IETF).