DMARC (Domain-based Message Authentication, Reporting and Conformance)

Definition: DMARC – vollständig „Domain-based Message Authentication, Reporting and Conformance" – ist ein E-Mail-Authentifizierungsprotokoll, das auf den bestehenden Standards SPF (Sender Policy Framework) und DKIM (DomainKeys Identified Mail) aufbaut und diese zu einem kohärenten Sicherheitsrahmen zusammenführt. DMARC ermöglicht es Domain-Inhabern, per DNS-TXT-Record eine verbindliche Richtlinie (Policy) zu veröffentlichen, die empfangenden Mailservern mitteilt, wie mit E-Mails umzugehen ist, die weder SPF- noch DKIM-Prüfungen im Abgleich mit der sichtbaren Absender-Domain (From-Header) bestehen. Gleichzeitig stellt DMARC einen Reporting-Mechanismus bereit: Empfänger-Mailserver senden automatisch aggregierte Berichte an den Domain-Inhaber, die zeigen, welche E-Mails im Namen der Domain verschickt werden – legitime wie missbräuchliche. DMARC wurde 2015 in RFC 7489 als Standard verabschiedet. Seit Februar 2024 verlangen Google und Yahoo von allen Massenversendern (ab 5.000 E-Mails pro Tag an Gmail bzw. Yahoo) eine gültige DMARC-Policy, was den Standard endgültig zum unverzichtbaren Bestandteil professionellen E-Mail-Marketings gemacht hat. Der Hauptzweck von DMARC ist es, Domain-Spoofing und Phishing-Angriffe zu unterbinden, bei denen Kriminelle die Absender-Domain eines Unternehmens fälschen, um betrügerische Nachrichten zu versenden, die auf den ersten Blick von einem vertrauenswürdigen Absender stammen.

Erläuterung

Das Herzstück von DMARC ist das Konzept des „Alignments": DMARC prüft nicht nur, ob SPF oder DKIM technisch bestanden wurden, sondern ob die in diesen Mechanismen verwendeten Domains mit der im From-Header sichtbaren Absender-Domain übereinstimmen. Im Fall von DKIM bedeutet Alignment, dass die in der DKIM-Signatur enthaltene Domain (d=-Parameter) mit der From-Domain identisch sein oder eine autorisierte Subdomain davon darstellen muss. Im Fall von SPF bedeutet es, dass die beim SMTP-Verbindungsaufbau verwendete Envelope-From-Adresse ebenfalls zur From-Header-Domain passen muss. Erst wenn mindestens einer dieser Abgleiche erfolgreich ist, gilt DMARC als bestanden. Dieses Alignment-Konzept schließt eine wichtige Lücke: Ohne DMARC konnte ein Angreifer SPF und DKIM für eine eigene Domain konfigurieren, aber trotzdem eine fremde Domain im sichtbaren From-Header verwenden.

Die DMARC-Policy wird als DNS-TXT-Record unter _dmarc.DOMAIN veröffentlicht und kennt drei Handlungsanweisungen: „none" bedeutet, dass Empfänger nichts Besonderes unternehmen sollen, aber Berichte senden. „quarantine" weist Empfänger an, nicht-konforme E-Mails in den Spam-Ordner zu verschieben. „reject" fordert Empfänger auf, nicht-konforme E-Mails vollständig abzulehnen. Für professionelles E-Mail-Marketing empfiehlt sich ein schrittweiser Weg von „none" über „quarantine" hin zu „reject", um zunächst alle legitimen E-Mail-Quellen zu identifizieren und korrekt zu konfigurieren, bevor strengere Maßnahmen greifen.

Der Reporting-Mechanismus ist ein oft unterschätzter Mehrwert von DMARC. Über den rua-Parameter erhält der Domain-Inhaber täglich aggregierte XML-Berichte von allen DMARC-implementierenden Empfängerservern. Diese Berichte zeigen, von welchen IP-Adressen E-Mails mit der eigenen Domain versendet werden, welche Authentifizierungsergebnisse erzielt wurden und wie viele Nachrichten betroffen waren. Da die XML-Rohdaten schwer lesbar sind, bieten Tools wie Postmark DMARC, Dmarcian, Valimail oder MXToolbox komfortable Visualisierungen und Alerting-Funktionen. Die regelmäßige Auswertung dieser Berichte ist entscheidend, um einerseits Missbrauchsversuche frühzeitig zu erkennen und andererseits sicherzustellen, dass keine legitimen E-Mail-Kanäle durch eine zu strenge Policy blockiert werden.

DMARC-Policy-Optionen und wichtige Parameter

• p=none: Überwachungs-Modus ohne Auswirkungen auf die Zustellung. Berichte werden gesendet. Empfohlen als erster Schritt zur Bestandsaufnahme aller E-Mail-Quellen der Domain.
• p=quarantine: Nicht-konforme E-Mails werden in Spam-/Junk-Ordner verschoben. Zweite Stufe auf dem Weg zur vollständigen Durchsetzung.
• p=reject: Nicht-konforme E-Mails werden abgelehnt und nicht zugestellt. Höchster Schutz – nur aktivieren, wenn alle legitimen Versandquellen korrekt authentifiziert sind.
• pct=N: Prozentualer Anteil der E-Mails, auf den die Policy angewendet wird (0–100). Ermöglicht schrittweises Rollout, zum Beispiel pct=25 für eine erste Testphase.
• rua=mailto: E-Mail-Adresse für aggregierte Berichte. Empfehlenswert ist eine dedizierte Adresse oder ein spezialisierter Report-Analyse-Dienst.
• sp=: Separate Policy für Subdomains. Ermöglicht unterschiedliche Behandlung von Haupt- und Subdomains, was bei transaktionalen Systemen auf eigenen Subdomains sinnvoll ist.
• adkim/aspf=r oder s: Legt fest, ob Alignment „relaxed" (Subdomains erlaubt) oder „strict" (exakte Domain-Übereinstimmung) geprüft wird. Standard: relaxed.

Typische Fehler und Fallstricke bei der DMARC-Implementierung

• Zu frühe Aktivierung von p=reject: Ohne vorherige Analyse der DMARC-Berichte werden häufig legitime E-Mail-Quellen wie CRM-Systeme, Helpdesk-Tools oder automatische Bestellbenachrichtigungen blockiert.
• Vergessene E-Mail-Quellen: Transaktionale E-Mails, automatisierte Systemnachrichten oder Drittanbieter-Tools versenden oft E-Mails im Namen der Hauptdomain ohne korrekte Authentifizierung.
• Alignment-Fehler beim ESP: Der E-Mail-Service-Provider verwendet eine eigene Versanddomain, die nicht mit der From-Domain übereinstimmt. Lösung: Custom Domain Setup oder CNAME-Konfiguration beim ESP.
• Fehlende Subdomain-Policy: Ohne expliziten sp-Parameter erben Subdomains die Hauptdomain-Policy, was bei transaktionalen Subdomains unbeabsichtigte Blockierungen verursachen kann.
• Keine Auswertung der DMARC-Berichte: Der größte Fehler ist, DMARC einzurichten und dann die Berichte zu ignorieren. Die Berichte sind der eigentliche Erkenntnisgewinn des Systems.