Glossar · Organisation

DMARC - Domain-based Message Authentication, Reporting and Conformance nach RFC 9989

Richtlinie, die festlegt, wie mit nicht authentifizierten E-Mails einer Domain verfahren wird

Lesezeit: 3 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 9989) 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. Seit Mai 2026 ist DMARC über RFC 9989 erstmals ein echter IETF-Standard (Proposed Standard) und löst den elf Jahre alten, rein informativen RFC 7489 ab.

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. Diese Organisationsdomain wird seit RFC 9989 per DNS Tree Walk ermittelt - ein DNS-Aufstieg von der From-Domain aus - statt wie zuvor über die extern gepflegte Public Suffix List.

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. Für die schrittweise Durchsetzung dient inzwischen der Testmodus t=y: Die Ziel-Policy steht bereits im Record, Empfänger sollen sie aber noch nicht durchsetzen. Das mit RFC 9989 gestrichene pct-Feld, das früher nur einen Teil der Mails der Policy unterwarf, entfällt damit.

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. Beide Report-Typen sind inzwischen in eigenen Dokumenten spezifiziert: rua in RFC 9990, ruf in RFC 9991.

Was RFC 9989 gegenüber RFC 7489 geändert hat

DMARC ist damit erstmals Standards Track statt Informational: RFC 7489 war 2015 ohne formalen IETF-Konsens über den Independent Submission Stream erschienen, RFC 9989 durchlief das reguläre IETF-Verfahren. Inhaltlich entfällt das pct-Tag ersatzlos (Ersatz: t=y als Testmodus), neu hinzugekommen ist np= für die Policy bei nicht existierenden Subdomains, und die Organisationsdomain wird per DNS Tree Walk statt Public Suffix List bestimmt. Bestehende DMARC-Records bleiben gültig - Empfänger, die die neue Spezifikation noch nicht kennen, ignorieren unbekannte Tags wie np= und t= einfach.

Praxis-Tool

Erstelle deinen DMARC-Record mit Policy, rua-Reports und Alignment - direkt im Browser

SPF- und DMARC-Generator öffnen →

Auch bekannt als

DMARC-Record · Domain-based Message Authentication

Quellen

Zuletzt aktualisiert: 2026-09-15

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.

Was ändert sich mit RFC 9989 für bestehende DMARC-Records?

Bestehende Records bleiben gültig und funktionieren unverändert weiter. Nur das pct-Tag sollte bei Gelegenheit gegen t=y (Testmodus) getauscht werden, da RFC 9989 pct ersatzlos gestrichen hat. Mailserver, die die neue Spezifikation noch nicht implementieren, ignorieren die neuen Tags np= und t= einfach, statt den Record abzulehnen.