DMARC Flow: So funktioniert der Fluss der E-Mail-Sicherheit

E-Mails sind bis heute das wichtigste Kommunikationsmittel für Unternehmen – und gleichzeitig eines der größten Einfallstore für Cyberangriffe. Phishing, Spoofing und Business Email Compromise (BEC) verursachen jährlich Schäden in Milliardenhöhe. Doch es gibt einen klar definierten technischen Flow, wie sich E-Mails von Grund auf absichern lassen: den DMARC Flow. Dieses Dokument erklärt jeden Schritt dieses Flusses und warum das Zusammenspiel der drei Protokolle SPF, DKIM und DMARC entscheidend ist.

Schritt 1: Der Absender erklärt sich - SPF

Der Flow beginnt mit dem Sender Policy Framework (SPF). SPF ist ein DNS-TXT-Record, der festlegt, welche Mailserver im Namen einer Domain E-Mails versenden dürfen. Wenn ein empfangender Mailserver eine E-Mail erhält, die vorgibt, von absender@beispiel.de zu stammen, macht er einen DNS-Lookup für den SPF-Record von beispiel.de und prüft, ob die IP-Adresse des sendenden Servers in der Liste der autorisierten Server aufgeführt ist.

Ist die IP nicht autorisiert und endet der SPF-Record mit -all (Hardfail), schlägt SPF fehl. Bei ~all (Softfail) wird die Nachricht markiert, aber nicht sofort abgewiesen. SPF allein reicht nicht aus, um Domain-Spoofing zu verhindern, weil es den Envelope-Absender (den technischen Return-Path) prüft – nicht die sichtbare From-Adresse, die der Empfänger in seinem E-Mail-Client sieht.

Typische SPF-Fehler, die den Flow unterbrechen: mehr als 10 DNS-Lookups (RFC-Limit), veraltete Include-Verweise auf eingestellte Provider, und fehlende Einträge für neu integrierte Sendesysteme wie CRM-Tools oder Marketingplattformen.

Schritt 2: Die Nachricht wird signiert - DKIM

DomainKeys Identified Mail (DKIM) fügt jeder ausgehenden Nachricht eine kryptografische Signatur im Header hinzu. Der sendende Mailserver signiert die Nachricht mit einem privaten Schlüssel; der zugehörige öffentliche Schlüssel ist im DNS unter einem Selektor-Record hinterlegt, z.B. selektor1._domainkey.beispiel.de.

Der empfangende Server ruft den öffentlichen Schlüssel aus dem DNS ab und prüft die Signatur. Eine gültige Signatur beweist zwei Dinge: dass die Nachricht von einem Server stammt, der den privaten Schlüssel besitzt (also einem autorisierten Absender), und dass der Nachrichteninhalt und relevante Header-Felder während des Transports nicht verändert wurden.

Im Gegensatz zu SPF überlebt DKIM auch E-Mail-Weiterleitungen, weil die Signatur an der Nachricht selbst hängt und nicht an der sendenden IP-Adresse. Das macht DKIM zu einem robusteren Signal für das Alignment. Allerdings kann auch DKIM allein Domain-Spoofing nicht verhindern – die signierte Domain muss mit der From-Domain übereinstimmen, damit sie für DMARC zählt.

Schritt 3: Die Policy wird durchgesetzt - DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) ist die Schicht, die SPF und DKIM zusammenführt und handlungsfähig macht. Ein DMARC-Record ist ein TXT-Record unter _dmarc.beispiel.de, der empfangenden Servern drei Dinge mitteilt:

1. Was mit Nachrichten geschehen soll, die weder SPF- noch DKIM-Alignment bestehen - die Policy (p=none, p=quarantine oder p=reject).
2. Wohin Aggregatberichte gesendet werden sollen (der rua-Parameter) - tägliche XML-Zusammenfassungen von allen großen Mailbox-Providern mit Authentifizierungsergebnissen für alle Mails, die sie im Namen deiner Domain empfangen haben.
3. Wohin forensische Berichte gesendet werden sollen (der ruf-Parameter) - einzelne Fehlerberichte pro Nachricht, die Authentifizierungsprüfungen nicht bestanden hat.

Das Alignment-Konzept ist der Kern von DMARC: Eine Nachricht besteht DMARC, wenn entweder das SPF-Alignment besteht (die Domain im Return-Path stimmt mit der From-Domain überein) oder das DKIM-Alignment besteht (die Domain in der DKIM-Signatur stimmt mit der From-Domain überein). Ein Angreifer, der deine From-Adresse fälscht, kann kein Alignment bestehen, weil er weder deinen DNS kontrolliert noch mit deinem privaten Schlüssel signieren kann.

Die drei Policy-Stufen im Detail

• p=none: Monitoring-Modus. Nachrichten, die DMARC nicht bestehen, werden trotzdem zugestellt. Aggregatberichte werden an deine rua-Adresse gesendet. Das ist der Startpunkt – er gibt Sichtbarkeit, bevor Enforcement-Maßnahmen ergriffen werden. Unternehmen sollten nicht länger als 30–60 Tage auf p=none bleiben.
• p=quarantine: Nachrichten, die DMARC nicht bestehen, werden in den Spam/Junk-Ordner verschoben. Das ist der Zwischenschritt, der es ermöglicht, zu prüfen, ob legitime Mails abgefangen werden, bevor auf vollständige Ablehnung umgestellt wird. Mit dem pct=-Parameter kannst du Quarantine zunächst nur auf einen Teil der fehlschlagenden Mails anwenden.
• p=reject: Nachrichten, die DMARC nicht bestehen, werden vom empfangenden Server vollständig abgelehnt. Sie erreichen weder Posteingang noch Spam-Ordner. Das ist die einzige Policy-Stufe, die Domain-Spoofing technisch vollständig verhindert. Gmail, Yahoo und die meisten Cyber-Versicherer behandeln p=reject heute als erwarteten Standard für etablierte Domains.

Der Reporting-Kreislauf: Der Flow wird geschlossen

Was den DMARC Flow zu einem echten Kreislauf macht, ist das Reporting-Feedback. Täglich senden die großen Provider - Gmail, Outlook, Yahoo, Apple Mail - Aggregatberichte (XML) an deine rua-Adresse. Diese Berichte enthalten:

• Die sendenden IP-Adressen und Sendevolumina
• SPF- und DKIM-Ergebnis für jede Quelle
• Die angewandte DMARC-Disposition (none, quarantine, reject)

Durch die Analyse dieser Berichte entdeckst du unbekannte Sendesysteme, identifizierst Fehlkonfigurationen und verfolgst deinen Fortschritt Richtung Enforcement. DMARCFlow parst diese XML-Berichte automatisch und stellt sie als lesbare Dashboards dar - inklusive Alerts, wenn neue Quellen auftauchen oder Authentifizierungsquoten sinken.

Warum der DMARC Flow über Sicherheit hinaus wichtig ist

Den DMARC Flow vollständig umzusetzen - von SPF und DKIM bis zu p=reject mit aktivem Monitoring - hat Vorteile, die über das reine Stoppen von Phishing hinausgehen:

• Inbox-Platzierung: Googles und Yahoos Bulk-Sender-Richtlinien (ab 2024 in Kraft) verlangen p=quarantine oder höher für Massenversender. Domains ohne DMARC-Enforcement werden stärker spam-gefiltert.
• Markenschutz: Mit p=reject kann deine Domain nicht mehr für überzeugende Phishing-E-Mails an Kunden oder Partner genutzt werden. Das Reputationsrisiko eines Spoofing-Vorfalls entfällt.
• Versicherung und Compliance: Cyber-Versicherer und Regulatoren (NIS2, ISO 27001, PCI DSS v4) betrachten DMARC-Enforcement als Baseline-Kontrolle. Domains auf p=none erhalten ein höheres Risikorating.
• BIMI-Berechtigung: Brand Indicators for Message Identification - die Funktion, die dein Logo im Gmail-Posteingang anzeigt - setzt DMARC auf p=quarantine oder p=reject voraus.