DMARC
Wenn jemand eine E-Mail im Namen einer Firma verschickt, prüft der empfangende Server, ob diese Nachricht tatsächlich von dort stammt. DMARC ist die Regel, die festlegt, was bei einem negativen Ergebnis passiert. Der Name steht für Domain-based Message Authentication, Reporting and Conformance.
Wie E-Mail-Authentifizierung zusammenwirkt
E-Mail-Verkehr basiert auf dem SMTP-Protokoll, das keine eingebaute Absenderprüfung kennt. Zwei Mechanismen ergänzen diese fehlende Schicht: SPF definiert, welche Server für eine Domain senden dürfen. DKIM versieht jede Nachricht mit einer kryptografischen Signatur. Beide Verfahren arbeiten unabhängig voneinander und liefern jeweils ein Ergebnis: bestanden oder nicht bestanden.
DMARC verbindet diese beiden Prüfungen zu einer einheitlichen Policy. Der Domain-Inhaber veröffentlicht einen DNS-Eintrag, der festlegt, wie der Empfänger-Server reagieren soll, wenn weder SPF noch DKIM für die sichtbare Absenderdomain bestätigt werden.
Beispiel: Ein Unternehmen betreibt die Domain firma.de. Der SPF-Eintrag erlaubt nur den Server mail.firma.de. Der DKIM-Schlüssel ist im DNS hinterlegt. Der DMARC-Record sagt: Wenn eine Nachricht mit dem Absender @firma.de weder den SPF- noch den DKIM-Check besteht, lehne sie ab.
Beispiel: Ein Newsletter-Dienstleister versendet im Auftrag von firma.de. Die DKIM-Signatur wird mit dem Schlüssel von firma.de erzeugt. SPF schlagt fehl, weil der Dienstleister-Server nicht im SPF-Record steht. Trotzdem besteht die Nachricht den DMARC-Check, weil DKIM allein ausreicht.
Identifier Alignment: Die zentrale Prüflogik
DMARC prüft nicht nur, ob SPF oder DKIM bestanden wurden. Es prüft zusätzlich, ob die authentifizierte Domain mit der sichtbaren Absenderdomain übereinstimmt. Diese Prüfung heißt Identifier Alignment.
Die sichtbare Absenderdomain steht im From-Header der E-Mail. SPF authentifiziert die Domain aus dem MAIL FROM-Envelope. DKIM authentifiziert die Domain aus dem d=-Tag der Signatur. DMARC verlangt, dass mindestens eine dieser authentifizierten Domains zur From-Domain passt.
Es gibt zwei Alignment-Modi: strict verlangt eine exakte Übereinstimmung. relaxed erlaubt Subdomains. Bei relaxed gilt eine Nachricht von news.firma.de als aligned mit firma.de.
Beispiel: Eine E-Mail trägt im From-Header die Adresse info@firma.de. Der MAIL FROM-Envelope zeigt bounce@mailservice.com. SPF bestätigt mailservice.com, aber das Alignment schlägt fehl, weil mailservice.com nicht zu firma.de passt. Ohne gültige DKIM-Signatur für firma.de besteht diese Nachricht den DMARC-Check nicht.
Beispiel: Dieselbe Konstellation, aber der Dienstleister signiert mit DKIM unter d=firma.de. Das DKIM-Alignment stimmt, die Nachricht besteht DMARC trotz fehlgeschlagenem SPF-Alignment.
Aufbau des DNS-Eintrags
Der DMARC-Record wird als TXT-Eintrag unter _dmarc.domain.de im DNS veröffentlicht. Er besteht aus Schlüssel-Wert-Paaren, getrennt durch Semikolons.
Die wichtigsten Tags:
v=DMARC1ist das Pflichtfeld für die Versionsnummer.p=none|quarantine|rejectlegt die Policy für die Domain fest.sp=definiert die Policy für Subdomains (optional, erbt von p=).rua=mailto:gibt die Adresse für aggregierte Reports an.ruf=mailto:gibt die Adresse für forensische Reports an.adkim=r|ssteuert den DKIM-Alignment-Modus (relaxed oder strict).aspf=r|ssteuert den SPF-Alignment-Modus.pct=bestimmt den Prozentsatz der Nachrichten, auf die die Policy angewendet wird.fo=legt die Bedingungen für forensische Reports fest.
Beispiel: Der Eintrag v=DMARC1; p=reject; rua=mailto:dmarc@firma.de; adkim=s; aspf=r bedeutet: Alle Nachrichten, die weder SPF (relaxed) noch DKIM (strict) bestehen, werden abgelehnt. Aggregierte Reports gehen an dmarc@firma.de.
Beispiel: Der Eintrag v=DMARC1; p=quarantine; pct=50; rua=mailto:reports@firma.de wendet die Quarantine-Policy nur auf 50 Prozent der fehlschlagenden Nachrichten an. Die andere Hälfte wird wie bei p=none behandelt. Dieser Mechanismus ermöglicht eine schrittweise Verschärfung.
Die drei Policy-Stufen und ihre Wirkung
DMARC kennt drei Eskalationsstufen. Jede Stufe bestimmt, wie der empfangende Server mit Nachrichten umgeht, die den DMARC-Check nicht bestehen.
p=none ist der Beobachtungsmodus. Der Empfänger-Server verändert die Zustellung nicht. Er sendet lediglich Reports an die im rua-Tag angegebene Adresse. Diese Stufe dient der Analyse: Welche Server versenden im Namen der Domain? Welche Nachrichten scheitern an SPF oder DKIM?
p=quarantine weist den Empfänger an, fehlschlagende Nachrichten als verdächtig zu markieren. In der Praxis landen diese Nachrichten im Spam-Ordner. Legitime Nachrichten, die wegen fehlender SPF- oder DKIM-Konfiguration scheitern, werden ebenfalls aussortiert.
p=reject ist die strikteste Stufe. Der Empfänger lehnt fehlschlagende Nachrichten direkt ab. Der sendende Server erhält eine Fehlermeldung. Die Nachricht wird nicht zugestellt und erscheint nicht im Spam-Ordner.
Beispiel: Ein Online-Shop stellt von p=none auf p=quarantine um. In der ersten Woche landen 12 Prozent der Bestellbestätigungen im Spam, weil ein Transaktionsmail-Dienstleister nicht im SPF-Record aufgeführt war. Die DMARC-Reports zeigen die IP-Adressen der betroffenen Server. Nach Korrektur des SPF-Records sinkt die Rate auf null.
Reporting: Aggregierte und forensische Berichte
DMARC definiert zwei Report-Typen. Aggregierte Reports (rua) fassen die Ergebnisse über einen Zeitraum zusammen, typischerweise 24 Stunden. Sie werden als XML-Dateien an die angegebene Adresse gesendet und enthalten: sendende IP-Adresse, Anzahl der Nachrichten, SPF-Ergebnis, DKIM-Ergebnis und angewendete Policy.
Forensische Reports (ruf) werden bei jedem einzelnen Fehlschlag erzeugt. Sie enthalten Header-Informationen der betroffenen Nachricht. Viele Mailprovider senden keine forensischen Reports, weil sie Datenschutzbedenken haben.
Die Report-Verarbeitung erfordert Werkzeuge, die das XML-Format parsen und in lesbare Übersichten umwandeln. Ohne systematische Auswertung bleibt der Beobachtungsmodus wirkungslos.
Beispiel: Ein aggregierter Report zeigt, dass von der IP-Adresse 203.0.113.45 täglich 400 Nachrichten mit der Absenderdomain firma.de versendet werden. SPF und DKIM schlagen fehl. Die IP-Adresse gehört nicht zum Unternehmen. Es handelt sich um unauthorisierten Versand.
Beispiel: Drei verschiedene Mailprovider senden aggregierte Reports für firma.de. Google liefert tägliche Reports mit Tausenden Einträgen. Microsoft sendet Reports alle 24 Stunden. Ein kleinerer Provider sendet keinen Report, obwohl er im rua-Tag steht. Reporting ist eine Empfehlung, keine Garantie.
Schrittweise Implementierung in der Praxis
Die Einführung von DMARC folgt einem definierten Ablauf. Der erste Schritt ist die Bestandsaufnahme: Welche Systeme versenden E-Mails im Namen der Domain? Dazu gehören der eigene Mailserver, Newsletter-Systeme, CRM-Plattformen, Ticketsysteme und Transaktionsmail-Dienste.
Im zweiten Schritt werden SPF und DKIM für alle legitimen Versandsysteme konfiguriert. SPF erhält die IP-Adressen oder include-Einträge aller autorisierten Server. DKIM-Schlüssel werden pro Versandsystem generiert und im DNS hinterlegt.
Danach wird der DMARC-Record mit p=none veröffentlicht. Die eingehenden Reports zeigen, ob alle legitimen Quellen korrekt authentifiziert sind. Erst wenn die Fehlerquote bei bekannten Absendern gegen null geht, wird die Policy auf quarantine und später auf reject angehoben.
Beispiel: Ein mittelständisches Unternehmen identifiziert sechs Versandquellen: den internen Mailserver, einen Newsletter-Dienst, ein Ticketsystem, eine Buchhaltungssoftware, ein CRM und eine Überwachungsplattform. Zwei dieser Systeme hatten keinen DKIM-Schlüssel konfiguriert. Nach der Korrektur und drei Wochen Beobachtung mit p=none zeigen die Reports eine SPF/DKIM-Bestehensrate von 99,4 Prozent.
Grenzen und häufige Fehlerquellen
DMARC schützt ausschließlich die Domain im From-Header. Es verhindert nicht, dass Angreifer ähnlich aussehende Domains registrieren (zum Beispiel firrna.de statt firma.de). Dieser Angriffstyp heißt Lookalike-Domain-Angriff und liegt außerhalb des DMARC-Schutzbereichs.
Mailinglisten und Weiterleitungen brechen regelmäßig die DMARC-Prüfung. Wenn ein Empfänger eine Nachricht über seine eigene Weiterleitung an ein anderes Postfach schickt, ändert sich die sendende IP-Adresse. SPF schlägt fehl, weil der Weiterleitungsserver nicht im SPF-Record steht. DKIM bleibt intakt, sofern die Nachricht nicht verändert wurde. Mailinglisten ändern häufig den Body oder Subject-Header, wodurch auch die DKIM-Signatur bricht.
Das Authenticated Received Chain (ARC) Protokoll adressiert dieses Problem. Jeder Zwischenserver in der Weiterleitungskette fügt eine eigene Signatur hinzu, die die ursprüngliche Authentifizierung dokumentiert. ARC ist kein Bestandteil von DMARC, wird aber von vielen großen Mailprovidern berücksichtigt.
Beispiel: Eine Universität setzt DMARC mit p=reject ein. Studierende, die ihre Uni-Mails an private Gmail-Adressen weiterleiten, erhalten plötzlich keine Nachrichten mehr. Die Weiterleitung bricht SPF, die Mailinglisten-Software verändert den Subject-Header und bricht DKIM. Die Reports zeigen Hunderte fehlgeschlagene Nachrichten von legitimen Absendern. Die Lösung: ARC-Unterstützung auf dem Weiterleitungsserver aktivieren und die Mailinglisten-Software so konfigurieren, dass sie den Original-Header nicht verändert.
Fachliche Einordnung: DMARC adressiert ausschließlich die Authentizität der Absenderdomain auf Protokollebene. Es macht keine Aussage über den Inhalt einer Nachricht, die Reputation des Absenders oder die Zustellbarkeit. Eine Nachricht, die DMARC besteht, kann trotzdem Spam enthalten. Eine Nachricht, die DMARC nicht besteht, kann legitim sein. DMARC ist ein Baustein in einem größeren System aus SPF, DKIM, ARC, Reputationssystemen und Inhaltsfiltern. Die Wirksamkeit hängt davon ab, dass alle Versandquellen einer Domain korrekt konfiguriert sind und die empfangenden Server DMARC tatsächlich auswerten. RFC 7489 definiert den Standard. Die Überarbeitung in RFC 9032 präzisiert die Interaktion mit Mailinglisten.