DMARC verstehen — Reporting, Policy-Stufen, häufige Fehler

DMARC schliesst die Lücke, die SPF und DKIM einzeln offenlassen: Es verlangt, dass mindestens eines der beiden Verfahren nicht nur bestanden wird, sondern auch zur Domain passt, die der Empfänger im «From»-Feld tatsächlich sieht. Zusätzlich legt ein DMARC-Eintrag fest, was mit Mails passiert, die diese Prüfung nicht bestehen, und schickt Ihnen dafür regelmässig Berichte zu.

Was Alignment bedeutet, und warum es fehlt

SPF prüft den versendenden Server, DKIM die Signatur – beide beziehen sich dabei auf eine technische Absenderdomain, die im Header steckt, aber für den Empfänger unsichtbar bleibt. Die Adresse, die tatsächlich im Postfach als Absender erscheint (das sichtbare «From»-Feld), kann davon abweichen, ohne dass SPF oder DKIM das bemerken. Genau diese Lücke nutzen gefälschte Mails: Technisch sauber authentifiziert, aber mit einer völlig anderen sichtbaren Absenderadresse.

DMARC verlangt «Alignment»: Mindestens eine der beiden Prüfungen muss sich auf dieselbe Domain beziehen, die der Empfänger sieht. Erst dann gilt eine Mail als DMARC-konform.

Die drei Policy-Stufen

Ein DMARC-Eintrag sieht etwa so aus: v=DMARC1; p=none; rua=mailto:reports@ihredomain.ch; pct=100. Das Kernstück ist p=, die Policy:

Stufe	Wirkung	Wann sinnvoll
p=none	Nur beobachten, nichts wird blockiert	Immer als Startpunkt
p=quarantine	Nicht konforme Mails wandern in den Spam-Ordner	Wenn die Reports sauber aussehen
p=reject	Nicht konforme Mails werden hart abgewiesen	Erst nach mehrwöchiger Beobachtung

Der Sprung direkt zu p=reject ist der häufigste Anfängerfehler. Er blockiert zuverlässig gefälschte Mails – aber genauso zuverlässig auch jeden legitimen Versandweg, der im eigenen SPF/DKIM-Setup vergessen wurde.

Was die Reports zeigen

rua= legt eine Adresse fest, an die teilnehmende Mailserver (Google, Microsoft, und weitere) täglich einen aggregierten Bericht schicken: wie viele Mails von welcher IP-Adresse im Namen Ihrer Domain unterwegs waren, und ob SPF, DKIM und Alignment bestanden wurden. Diese Berichte kommen als XML-Dateien und sind roh kaum lesbar – dafür gibt es kostenlose wie kommerzielle Auswertungswerkzeuge, die daraus eine Übersicht machen.

Genau diese Reports sind der Grund, warum p=none kein Leerlauf ist, sondern die eigentliche Arbeitsphase: Sie zeigen zuverlässige Versandwege ebenso wie vergessene – etwa ein Formular-Plugin der Website oder ein CRM, das im eigenen Namen sendet, aber nie im SPF-Record aufgetaucht ist.

Häufige Fehler beim Einführen

Ein Treuhandbüro plant, DMARC einzuführen, und setzt direkt p=reject, weil das «am sichersten» klingt. Zwei Tage später bleiben Rechnungsmails der externen Buchhaltungssoftware beim Kunden aus – der Dienst versendet im Namen der Kanzlei, war aber nie im SPF-Record erfasst und hatte keinen eigenen DKIM-Selector. Die Mails bestehen weder SPF- noch DKIM-Alignment und werden zuverlässig abgewiesen, ohne dass jemand eine Fehlermeldung sieht.

Weitere wiederkehrende Fehler:

• Subdomains vergessen. Ohne sp=-Tag gilt die Hauptpolicy auch für Subdomains – das ist gewollt, wird aber selten bedacht.
• rua= nie eingerichtet. Ohne Reports fliegt man beim Verschärfen der Policy blind.
• Zu schneller Sprung von none zu reject. Der Zwischenschritt quarantine, kombiniert mit pct= zur schrittweisen Ausweitung, macht Fehler sichtbar statt destruktiv.

p=reject ist das Ziel einer DMARC-Einführung, nicht der Startpunkt.