DMARC - Domain-based Message Authentication, Reporting and Conformance nach RFC 7489
Richtlinie, die festlegt, wie mit nicht authentifizierten E-Mails einer Domain verfahren wird
Lesezeit: 2 Min.
Was bedeutet DMARC?
DMARC ist ein DNS-Eintrag unter _dmarc.<domain>, der bestimmt, wie Mailserver mit E-Mails umgehen sollen, die SPF oder DKIM nicht bestehen oder bei denen der sichtbare Absender nicht zur authentifizierten Domain passt - und der per Report zurückmeldet, welche Server im Namen der Domain E-Mails versenden.
DMARC (RFC 7489) setzt auf SPF und DKIM auf und schließt deren zentrale Lücke: Beide Verfahren prüfen jeweils nur einen technischen Absenderwert (Envelope-From bei SPF, die signierende Domain bei DKIM), nicht das im Mailprogramm sichtbare From-Feld. DMARC führt dafür die Alignment-Prüfung ein - stimmt die Domain im sichtbaren From mit der SPF- oder DKIM-authentifizierten Domain überein, gilt die Mail als DMARC-konform. Der DMARC-Record unter _dmarc.<domain> legt per p= fest, was mit nicht konformen Mails geschehen soll: none (nur beobachten), quarantine (in Spam einsortieren) oder reject (ablehnen). Über rua erhält der Domaininhaber tägliche Aggregate-Reports, welche Server in seinem Namen Mails versenden - inklusive legitimer Quellen, die beim Einrichten von SPF vergessen wurden.
Alignment: die eigentliche Neuerung von DMARC
SPF prüft die Domain im Umschlag-Absender, DKIM die Domain, die die kryptografische Signatur trägt - beide können von der Domain im sichtbaren From-Header abweichen, ohne dass SPF oder DKIM allein das bemerken.
DMARC vergleicht genau das: Nur wenn die From-Domain mit der SPF- oder DKIM-Domain übereinstimmt (bei strikter Ausrichtung adkim=s/aspf=s exakt, bei entspannter adkim=r/aspf=r reicht dieselbe Organisationsdomain), gilt die Mail als DMARC-konform. Erst dadurch wird der sichtbare Absender tatsächlich geschützt.
Warum der Rollout mit p=none beginnt
Ein Sprung direkt zu p=reject kann legitime, aber im SPF-Record vergessene Versandquellen (Newsletter-Tool, CRM, Ticketsystem) blockieren. Mit p=none werden zunächst nur rua-Reports gesammelt, ohne dass eine Mail beeinträchtigt wird. Erst wenn diese Reports zeigen, dass alle legitimen Quellen erfasst sind, folgt der Wechsel zu quarantine und schließlich reject - üblicherweise über Wochen, oft zusätzlich gestaffelt über das pct-Feld, das anfangs nur einen Teil der Mails der Policy unterwirft.
Aggregate- und Forensic-Reports: rua und ruf
rua-Adressen erhalten periodische, aggregierte XML-Reports mit einer Zusammenfassung nach sendendem Server, IP und Pass/Fail-Status - die Grundlage, um SPF und DKIM vor der Verschärfung der Policy zu vervollständigen. ruf-Adressen sollten Reports zu einzelnen fehlgeschlagenen Mails liefern, werden aus Datenschutzgründen inzwischen aber von den meisten großen Mailanbietern nicht mehr versendet; in der Praxis reicht rua für den Rollout meist aus.
Praxis-Tool
Erstelle deinen DMARC-Record mit Policy, rua-Reports und Alignment - direkt im Browser
Zum SPF- und DMARC-Generator →Auch bekannt als
DMARC-Record · Domain-based Message Authentication
Verwandte Begriffe
Quellen
- RFC 7489 - Domain-based Message Authentication, Reporting and Conformance (DMARC)
- BSI - Absenderauthentifizierung mit SPF, DKIM und DMARC
Zuletzt aktualisiert: 2026-08-21
Häufige Fragen zu DMARC
Funktioniert DMARC auch ohne SPF oder DKIM?
DMARC selbst versendet keine Mails und prüft nichts direkt - es wertet nur die Ergebnisse von SPF und/oder DKIM aus. Ohne mindestens eines von beiden hat ein DMARC-Record keine Wirkung, weil es keine Authentifizierung gibt, gegen die er das sichtbare From abgleichen könnte.
Warum blockiert p=reject teilweise auch eigene Mails?
Meist, weil eine legitime Versandquelle nicht im SPF-Record steht oder nicht DKIM-signiert und darüber hinaus nicht zur eigenen Domain ausgerichtet ist. Deshalb sollte reject erst gesetzt werden, nachdem die rua-Reports einer p=none-Phase über mehrere Wochen keine unerwarteten Fehlschläge legitimer Quellen mehr zeigen.