DMARC steht für „Domain-based Message Authentication, Reporting and Conformance“ und ergänzt die Prüfverfahren SPF und DKIM um eine Regel, die der Inhaber einer Domain selbst festlegt. Hinterlegt wird diese Regel als TXT-Eintrag im DNS unter dem Namen _dmarc vor der eigentlichen Domain, bei der Domain example.com also unter _dmarc.example.com. Trifft eine Nachricht mit dieser Domain als Absender ein, liest der empfangende Server den Eintrag aus und erfährt, wie er mit einer Nachricht ohne gültigen Herkunftsnachweis umgehen soll. Zugleich nennt der Eintrag eine Adresse, an die Empfänger regelmäßig Berichte über die geprüften Nachrichten senden.
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) fasst SPF, DKIM und DMARC unter dem Begriff der E-Mail-Authentifizierung zusammen, deren Zweck der Schutz der Empfänger vor Identitätsmissbrauch ist. Google setzt für DMARC mindestens eines der beiden anderen Verfahren als aktiv voraus. Der DMARC-Eintrag steht daher am Ende der Einrichtung, deren Reihenfolge der Ratgeber zu SPF, DKIM und DMARC beschreibt. Von Absendern mit mehr als 5.000 Nachrichten am Tag an Gmail-Konten verlangt Google seit dem 1. Februar 2024 einen DMARC-Eintrag, wobei die Richtlinie auf none stehen darf.
Wie DMARC die Absenderadresse prüft
Maßgeblich für DMARC ist die Adresse im Feld „Von“, die das E-Mail-Programm als Absender anzeigt und die der Standard als Author Domain bezeichnet. Eine Nachricht besteht die Prüfung, wenn SPF oder DKIM erfolgreich verlaufen und die dabei bestätigte Domain zur Domain dieser Absenderadresse passt. Diese Übereinstimmung heißt Ausrichtung oder im Englischen Alignment, und nach Angaben von Microsoft genügt bereits eine einzige erfolgreiche Ausrichtung, während eine Nachricht erst bei zwei gescheiterten Prüfungen durchfällt.
Zur Wahl stehen zwei Stufen der Ausrichtung, die sich im Eintrag getrennt für SPF über das Tag aspf und für DKIM über das Tag adkim einstellen lassen. Bei der lockeren Stufe mit dem Wert r für relaxed genügt eine gemeinsame Organisationsdomain, sodass etwa eine Unterdomain für den Newsletter zur Hauptdomain passt. Die strenge Stufe mit dem Wert s für strict verlangt dagegen eine vollständig identische Domain. Ohne eigene Angabe gilt nach Microsoft die lockere Stufe. Die Technische Richtlinie TR-03182 des BSI sieht für versendende Domains dagegen die strenge Ausrichtung als Regelfall vor und lässt die lockere nur in Ausnahmen wie dem Massenversand über einen Dienstleister zu.
Richtlinien und Berichte im DMARC-Eintrag
Die Richtlinie steht im Tag p und kennt drei Werte, deren Wirkung Google für Gmail beschreibt. Mit none wird die Nachricht ohne weitere Maßnahmen zugestellt, mit quarantine landet sie als Spam markiert im Spam-Ordner, und mit reject lehnt der empfangende Server sie ab und schickt in der Regel eine Unzustellbarkeitsnachricht zurück. Über die tatsächliche Behandlung entscheidet nach Angaben von Microsoft letztlich das empfangende System, sodass der Eintrag den Wunsch des Domaininhabers ausdrückt. Für Unterdomains lässt sich mit dem Tag sp eine abweichende Richtlinie festlegen.
Über das Tag rua nennt der Eintrag eine Adresse für Sammelberichte, die zusammengefasst auflisten, welche Server Nachrichten mit der Domain als Absender verschickt haben und wie die Prüfungen ausgingen. RFC 7489 sah für diese Berichte das Format XML und einen Abstand von 86.400 Sekunden vor, also einen Bericht pro Tag. Google empfiehlt für den Empfang ein eigenes Postfach, weil die Menge der Berichte erheblich sein kann. Das Tag ruf fordert dagegen ausführliche Einzelberichte an, von denen die TR-03182 versendenden Domains abrät, weil das BSI diese Form des Berichts als unvereinbar mit der DSGVO einstuft. Microsoft 365 verschickt solche Einzelberichte grundsätzlich nicht.
DMARC schrittweise einführen
Google rät nach der Einrichtung von SPF und DKIM zu einer Wartezeit von 48 Stunden, bevor der DMARC-Eintrag hinzukommt. Den Anfang macht nach den Empfehlungen von Google und Microsoft die Richtlinie none, bei der Nachrichten wie bisher zugestellt werden und die Berichte zeigen, welche Dienste noch ohne gültigen Nachweis versenden. Nach einer ausreichenden Beobachtungszeit folgt quarantine und später reject, wobei Microsoft nach jeder Stufe eine erneute Auswertung der Ergebnisse vorsieht. Die TR-03182 verlangt diese Auswertung regelmäßig, zeitnah und nach Möglichkeit maschinell und empfiehlt außerdem eine Absicherung der DNS-Zone einer versendenden Domain mit DNSSEC gegen Verfälschung.
Domains ohne E-Mail-Versand, etwa zusätzlich registrierte Schreibvarianten des Firmennamens, lassen sich ebenfalls mit DMARC gegen Missbrauch absichern. Microsoft nennt für solche geparkten Domains den Eintrag p=reject, und die TR-03182 fordert darüber hinaus einen SPF-Eintrag ohne jede Versandberechtigung sowie einen Null-MX-Eintrag nach RFC 7505 für Domains ohne E-Mail-Empfang. Abweichend von Microsoft verlangt das BSI auch für diese Domains eine Adresse für Sammelberichte, damit Versuche des Missbrauchs sichtbar werden.
RFC 9989 als neuer DMARC-Standard
Grundlage von DMARC war lange RFC 7489 aus dem März 2015, ein Dokument mit dem Status „Informational“, das als unabhängige Einreichung außerhalb der Standardisierung der IETF erschienen war. Im Mai 2026 hat die IETF dieses Dokument durch RFC 9989 ersetzt, der DMARC als „Proposed Standard“ führt, während RFC 9990 und RFC 9991 die Berichte regeln. Gestrichen wurde das Tag pct, mit dem sich eine strengere Richtlinie bisher auf einen Anteil der Nachrichten beschränken ließ, da es nach den Erfahrungen der Autoren selten genau umgesetzt wurde.
An seine Stelle tritt das Tag t für einen Testmodus, bei dem Empfänger mit dem Wert y eine Stufe milder verfahren als angegeben, also reject wie quarantine und quarantine wie none behandeln. Neu ist außerdem das Tag np mit einer eigenen Richtlinie für Unterdomains, die im DNS gar nicht existieren. Die zugehörige Organisationsdomain ermitteln Empfänger nach RFC 9989 über eine Folge von DNS-Abfragen, den sogenannten DNS Tree Walk, statt wie bisher über die Public Suffix List.
Was DMARC abdeckt
RFC 9989 beschränkt DMARC auf Fälschungen, die exakt die Domain in der Absenderadresse verwenden. Angriffe über den angezeigten Namen vor der Adresse sowie über optisch ähnliche Domains nimmt der Standard ausdrücklich aus seinem Geltungsbereich aus. Eine Nachricht von einer leicht veränderten Domain wie „micros0ft.com“, die Microsoft als Warnzeichen nennt, prüft DMARC allein anhand der Einträge dieser fremden Domain. Gefälschte Nachrichten mit dem Ziel der Preisgabe von Zugangsdaten bezeichnet RFC 9989 als Phishing, dessen übrige Erkennungsmerkmale für Empfänger deshalb maßgeblich bleiben.