Neue DMARC Spezifikation RFC 9989 (DMARCbis)

Einleitung

Wer in den letzten Monaten über „DMARC 2.0“ gestolpert ist, sollte den Begriff mit Vorsicht verwenden: Einen neuen DNS-Record mit v=DMARC2 gibt es nicht. Was in der Community unter dem Arbeitstitel DMARCbis lief, ist seit Mai 2026 offiziell. Veröffentlicht wurden gleich drei Dokumente:

• RFC 9989 beschreibt das eigentliche DMARC-Protokoll.
• RFC 9990 definiert das Format der Aggregate Reports.
• RFC 9991 behandelt die detaillierten Failure Reports.

Gemeinsam lösen sie den älteren RFC 7489 aus 2015 ab. RFC 9989 ersetzt außerdem RFC 9091, in dem die Behandlung von Public Suffix Domains zuvor experimentell beschrieben wurde.

Bevor jemand panisch die DNS-Zone umschreibt: Die DMARC Policy Records beginnen weiterhin mit v=DMARC1. DMARCbis ist kein komplett neues Protokoll, sondern eine grundlegend überarbeitete und präzisere Spezifikation des bestehenden Verfahrens. DMARC ist damit erstmals Teil des offiziellen IETF Standards Track und nicht mehr nur ein Informational RFC aus einer unabhängigen Einreichung.

Für übliche Konfigurationen gibt es keinen harten Versionsbruch. Ganz folgenlos ist die Umstellung trotzdem nicht: Die Ermittlung der sogenannten Organizational Domain wurde verändert, einige Tags wurden entfernt oder hinzugefügt und auch das XML-Schema der Aggregate Reports wurde überarbeitet.

Kurz: Was DMARC überhaupt macht

DMARC baut auf zwei Bausteinen auf, die ich an anderer Stelle bereits beschrieben habe: SPF und DKIM.

SPF prüft im DMARC-Kontext, ob der versendende Mailserver für die Domain aus dem SMTP-MAIL FROM autorisiert ist. DKIM prüft eine kryptografische Signatur und damit die Verantwortung einer Signing Domain sowie die Integrität der signierten Bestandteile einer Nachricht.

DMARC ergänzt zwei entscheidende Dinge:

1. Alignment – Stimmt die Domain im sichtbaren From:-Header mit der Domain überein, die SPF oder DKIM authentifiziert haben? Genau hier setzen viele Spoofing-Angriffe an. SPF und DKIM allein sagen noch nicht aus, ob die sichtbare Absenderadresse legitim verwendet wurde.

2. Policy und Reporting – Als Domaininhaber veröffentlichen Sie eine Präferenz dafür, wie empfangende Systeme mit Nachrichten umgehen sollen, die DMARC nicht bestehen: keine besondere Behandlung, Quarantäne oder Ablehnung. Zusätzlich erhalten Sie Reports darüber, welche Systeme in Ihrem Namen E-Mails versenden.

Wichtig ist dabei das Wort Präferenz. Die endgültige Entscheidung liegt immer beim empfangenden Mailserver. Eine veröffentlichte Policy ist keine technische Fernsteuerung für fremde Systeme.

Vom Informational RFC zum offiziellen Standard

Der vielleicht unscheinbarste, aber wichtigste Punkt: RFC 7489 war ein Informational RFC aus einer unabhängigen Einreichung – also nie ein formaler IETF-Standard. Mehrdeutigkeiten wurden deshalb über Jahre hinweg teilweise unterschiedlich interpretiert.

DMARCbis ist nun ein Proposed Standard im IETF Standards Track. Das Ziel ist eine klarere und konsistentere Umsetzung bei Mailbox-Providern, Security-Gateways und Softwareherstellern.

Zusätzlich wurde die Spezifikation in drei Dokumente aufgeteilt. Kernprotokoll, Aggregate Reporting und Failure Reporting sind nun sauber voneinander getrennt:

Änderungen am RFC 9989

1. Public Suffix List entfällt, DNS Tree Walk kommt

Das ist die technisch bedeutendste Änderung.

Bisher wurde die sogenannte Organizational Domain üblicherweise mithilfe einer Public Suffix List bestimmt. Vereinfacht gesagt musste DMARC erkennen, dass bei einer Adresse wie mail.example.co.uk die organisatorisch relevante Basisdomain example.co.uk lautet und nicht einfach nur co.uk.

Die bisherige PSL-basierte Ermittlung wird nun durch einen DNS Tree Walk ersetzt. Der empfangende Server arbeitet sich dabei von der konkreten Domain schrittweise nach oben durch die DNS-Hierarchie und sucht nach DMARC-Records.

Der Tree Walk ist auf maximal acht DNS-Abfragen begrenzt. Dadurch verhindert der Standard, dass absichtlich absurd tief verschachtelte Domains unnötig viele DNS-Abfragen verursachen.

Die neue Logik entfernt die Abhängigkeit von extern gepflegten Public-Suffix-Listen. In einzelnen Grenzfällen können alte PSL-basierte Implementierungen und neue Tree-Walk-Implementierungen jedoch zu unterschiedlichen Ergebnissen kommen. Während der Übergangsphase sollte man deshalb nicht davon ausgehen, dass jeder Empfänger bereits exakt dieselbe Policy ermittelt.

2. Drei Tags wurden entfernt: pct, rf und ri

DMARCbis räumt einige Altlasten auf.

pct

Das Tag pct sollte ursprünglich ermöglichen, eine strengere Policy nur auf einen bestimmten Prozentsatz fehlgeschlagener Nachrichten anzuwenden:

v=DMARC1; p=quarantine; pct=10

In der Praxis wurde diese Vorgabe jedoch uneinheitlich umgesetzt. Werte zwischen 0 und 100 führten je nach Empfänger zu unterschiedlichen Ergebnissen. Die feinstufige Prozentsteuerung wurde deshalb entfernt.

Ein Teil der früheren Funktionalität wird nun durch das neue Tag t ersetzt. Dazu später mehr.

rf

Das Tag rf diente bislang dazu, ein gewünschtes Format für Failure Reports anzufordern. Diese Auswahlmöglichkeit wurde entfernt.

Das bestehende Authentication Failure Reporting Format afrf bleibt jedoch weiterhin relevant. Aggregate Reports sind davon unabhängig: Sie werden weiterhin als XML-Dateien übertragen.

ri

Das Tag ri sollte das gewünschte Intervall für Aggregate Reports angeben. Auch dieses Tag ist nicht mehr Bestandteil der aktuellen Spezifikation.

Empfangende Systeme sollen Aggregate Reports mindestens einmal innerhalb von 24 Stunden erzeugen und versenden. In der Praxis umfassen die Reports typischerweise einen UTC-Tag.

3. Drei Tags kamen hinzu: np, psd und t

np

Das Tag np definiert eine eigene Policy für nicht existierende Subdomains:

v=DMARC1; p=quarantine; sp=quarantine; np=reject

Damit kann ein Domaininhaber beispielsweise Nachrichten mit frei erfundenen Absenderdomains wie rechnung.example.com strenger behandeln als Nachrichten von tatsächlich vorhandenen Subdomains.

Fehlt np, greift automatisch die Policy aus sp. Fehlt auch sp, wird die Policy aus p verwendet. Ein explizites np=reject ist deshalb besonders dann interessant, wenn nicht existierende Subdomains bewusst strenger behandelt werden sollen.

psd

Das Tag psd unterstützt die Ermittlung der Organizational Domain beim DNS Tree Walk. Es kennt drei mögliche Werte:

psd=y ist vor allem für Betreiber von Public Suffix Domains relevant. Vollständig irrelevant ist das Tag für normale Domaininhaber aber nicht: Mit psd=n kann eine organisatorische Grenze ausdrücklich markiert werden.

Für durchschnittliche Unternehmensdomains wird das Tag vermutlich selten benötigt. Wer komplexe DNS-Strukturen betreibt, sollte seine Bedeutung dennoch kennen.

t

Das neue Tag t steht für testing. Es ersetzt einen Teil der früheren Funktionalität von pct.

Mit t=y signalisiert ein Domaininhaber, dass sich die veröffentlichte Policy noch im Testbetrieb befindet:

v=DMARC1; p=reject; t=y

Die angegebene Policy wird bei einem DMARC-Fehler um eine Stufe reduziert:

t=n ist der Default und fordert die Anwendung der veröffentlichten Policy an.

Der Testmodus bedeutet also nicht pauschal „keine Durchsetzung“. Bei p=reject; t=y wird eine fehlgeschlagene Nachricht weiterhin wie eine verdächtige Nachricht behandelt und typischerweise in Quarantäne verschoben.

4. p=reject wird deutlich vorsichtiger bewertet

Früher galt häufig der vereinfachte Rat:

p=none  →  p=quarantine  →  p=reject

DMARCbis ist an dieser Stelle wesentlich vorsichtiger. Eine harte Ablehnung kann bei indirekten Mail-Flüssen erhebliche Kollateralschäden verursachen. Dazu gehören insbesondere Weiterleitungen und Mailinglisten.

Bei einer Mailingliste wird eine ursprünglich gültige Nachricht häufig verändert, etwa durch eine Betreffzeile mit Listenpräfix oder einen angehängten Footer. Dadurch kann eine DKIM-Signatur ungültig werden. Gleichzeitig schlägt SPF regelmäßig fehl, weil die Nachricht nicht mehr vom ursprünglichen Mailserver zugestellt wird.

RFC 9989 weist deshalb ausdrücklich darauf hin, dass Domains für allgemeine Kommunikation nicht ohne Weiteres p=reject verwenden sollten.

Auch empfangende Mailserver sollen eine Nachricht nicht ausschließlich deshalb ablehnen, weil ein Domaininhaber p=reject veröffentlicht hat. Die finale Entscheidung bleibt eine lokale Policy-Entscheidung des Empfängers.

Die wichtigsten Tags im DNS-Record

Ein DMARC-Record ist ein TXT-Eintrag unter _dmarc.ihre-domain.de.

Das Tag fo ist nur relevant, wenn gleichzeitig mit ruf eine Adresse für Failure Reports angegeben wurde. Ohne ruf muss fo ignoriert werden.

Einrichtung und Rollout

Ein Minimal-Record zum Einstieg sieht so aus:

_dmarc.ihre-domain.de.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@ihre-domain.de"

Damit veröffentlichen Sie zunächst keine Präferenz für eine verschärfte Behandlung (p=none), sammeln aber Aggregate Reports.

Bei einer produktiv genutzten Domain ist das üblicherweise der erste Schritt: Beobachten Sie zunächst, welche Systeme tatsächlich in Ihrem Namen versenden. Dazu gehören häufig nicht nur der eigene Mailserver, sondern auch Newsletter-Plattformen, Ticketsysteme, CRM-Anwendungen, Buchhaltungssoftware und längst vergessene Altsysteme.

Ein möglicher Rollout-Pfad lautet:

p=none  →  p=quarantine  →  gegebenenfalls p=reject

Das Wort gegebenenfalls ist entscheidend. Ob p=reject sinnvoll ist, hängt vom Einsatzzweck der Domain ab.

Bei klar abgegrenzten Versanddomains für transaktionale Nachrichten lässt sich eine harte Policy häufig gut kontrollieren. Bei Domains für allgemeine Mitarbeiterkommunikation können Weiterleitungen, Mailinglisten und andere indirekte Mail-Flüsse dagegen legitime Nachrichten beeinträchtigen.

Für eine kontrollierte Versanddomain könnte ein Record beispielsweise so aussehen:

_dmarc.mail.ihre-domain.de.  IN  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@ihre-domain.de"

Die Alignment-Modi adkim und aspf stehen standardmäßig auf r (relaxed). Eine Umstellung auf s (strict) kann sinnvoll sein, sollte aber bewusst erfolgen. Striktes Alignment kann legitime Versandkonfigurationen beeinträchtigen, wenn Subdomains verwendet werden.

Mit dem Wegfall von pct entfällt das frühere Werkzeug für einen feinstufigen prozentualen Rollout. Früher konnte man beispielsweise p=quarantine; pct=10 setzen und den Anteil schrittweise erhöhen.

Das neue t=y ist gröber:

v=DMARC1; p=quarantine; t=y

In diesem Beispiel wird bei einem DMARC-Fehler noch keine Quarantäne angefordert. Die Policy wird im Testmodus um eine Stufe reduziert und damit als none behandelt.

Bei einer produktiv genutzten General-Purpose-Domain sollten Sie deshalb ausreichend lange Monitoring-Phasen einplanen. RFC 9989 empfiehlt vor einem Wechsel zu p=reject, zunächst mindestens einen Monat lang p=none und anschließend ebenso lange p=quarantine zu verwenden und die Auswirkungen anhand der Aggregate Reports auszuwerten.

Zusätzlich lohnt sich die Trennung unterschiedlicher Mail-Flüsse auf eigene Subdomains. Ein Wechsel des Newsletter-Anbieters sollte schließlich nicht versehentlich die Zustellung Ihrer Geschäftsmail gefährden.

Wie sehen die Reports aus?

Es gibt zwei Arten von DMARC-Reports.

Aggregate Reports (rua)

Aggregate Reports liefern zusammengefasste Daten über die Verwendung Ihrer Domain. Sie werden in der Praxis häufig täglich versendet und enthalten unter anderem:

• versendende IP-Adressen
• Anzahl der beobachteten Nachrichten
• SPF- und DKIM-Ergebnisse
• Alignment-Ergebnisse
• angewandte Dispositionen
• veröffentlichte DMARC-Policy
• Gründe für mögliche Policy-Ausnahmen

Die Berichte bestehen aus XML-Dateien und sollten GZIP-komprimiert übertragen werden. Typische Dateinamen enden deshalb auf .xml.gz.

RFC 9990 erweitert und präzisiert das XML-Schema. Neue oder ausdrücklich definierte Felder umfassen unter anderem:

• np für die Policy nicht existierender Subdomains
• testing für den Testmodus
• discovery_method mit den Werten psl oder treewalk
• Erweiterungsmöglichkeiten für zukünftige zusätzliche Elemente

Interessantes Detail am Rande: Der DNS-Record bleibt bei v=DMARC1. Das neue XML-Schema verwendet jedoch den Namespace:

urn:ietf:params:xml:ns:dmarc-2.0

Ein kleines semantisches Geschenk an alle, die gehofft hatten, die Diskussion über den Begriff „DMARC 2.0“ wäre damit endgültig beendet.

Failure Reports (ruf)

Failure Reports liefern detaillierte Informationen zu einzelnen Nachrichten oder Gruppen ähnlicher Nachrichten, die eine DMARC-Prüfung nicht bestanden haben.

Sie können bei der Fehlersuche und der Analyse konkreter Missbrauchsfälle hilfreich sein. Allerdings können sie Header-Felder und teilweise sogar vollständige Inhalte fehlgeschlagener Nachrichten enthalten. Damit können personenbezogene Daten oder vertrauliche Informationen offengelegt werden.

Viele Provider versenden Failure Reports deshalb nur eingeschränkt, stark redigiert oder überhaupt nicht.

Für die meisten Umgebungen sind Aggregate Reports das eigentliche Arbeitspferd. Failure Reports sind eher ein gezieltes Diagnoseinstrument und sollten nicht beiläufig als Standardfunktion aktiviert werden.

Reports auswerten

XML-Berichte von Hand zu lesen, ist ungefähr so unterhaltsam, wie es klingt.

In der Praxis benötigen Sie deshalb entweder einen spezialisierten Dienst oder einen eigenen Parser, der die Reports einsammelt, normalisiert und über einen längeren Zeitraum auswertet.

Der interoperable Standardweg für rua ist eine mailto:-Adresse:

rua=mailto:dmarc@ihre-domain.de

Ein eigener Sammler kann dieses IMAP-Postfach regelmäßig leeren, die XML-Dateien entpacken und die Daten anschließend beispielsweise in einer Datenbank oder einem S3-Bucket ablegen.

Ein S3-Bucket ist dabei typischerweise eine interne Ablage hinter dem Mail-Collector und kein universell unterstütztes direktes Ziel im DMARC-Record.

Für einen ersten Überblick reichen einige einfache Fragen:

• Welche Systeme versenden legitime Nachrichten in unserem Namen?
• Welche Absender bestehen weder SPF- noch DKIM-Alignment?
• Gibt es unerwartete Versandquellen?
• Welche Subdomains werden missbraucht?
• Welche legitimen Mail-Flüsse würden durch p=quarantine oder p=reject beeinträchtigt?
• Verwenden unsere Auswertungswerkzeuge bereits das aktualisierte XML-Schema?

Was müssen Sie jetzt konkret tun?

Für den laufenden Betrieb müssen Sie nicht hektisch sämtliche DNS-Records umschreiben. Eine strukturierte Prüfung ist trotzdem sinnvoll:

1. Prüfen Sie bestehende Records auf pct, rf und ri.
2. Entfernen Sie veraltete Tags nicht blind, sondern prüfen Sie zunächst, ob bestehende Prozesse oder Auswertungswerkzeuge noch davon ausgehen.
3. Kontrollieren Sie, ob Ihre DMARC-Auswertung RFC 9990 und das aktualisierte XML-Schema unterstützt.
4. Prüfen Sie, ob eine explizite np-Policy für nicht existierende Subdomains einen Mehrwert bietet.
5. Bewerten Sie bei komplexen DNS-Strukturen, ob psd=n sinnvoll sein könnte.
6. Rollen Sie p=reject nicht reflexartig auf Domains für allgemeine Kommunikation aus.
7. Trennen Sie unterschiedliche Versandzwecke möglichst auf eigene Subdomains.

Fazit

Für übliche Policy Records gilt auch bei RFC 9989 weiterhin: v=DMARC1 bleibt korrekt. DMARCbis verlangt keine panische Umbauaktion in der DNS-Zone.

Trotzdem ist die neue Spezifikation mehr als kosmetische Textpflege. Der DNS Tree Walk ersetzt die PSL-basierte Ermittlung der Organizational Domain. Die unzuverlässige Prozentsteuerung über pct verschwindet. Neue Tags ermöglichen eine differenziertere Behandlung nicht existierender Subdomains und eine klarere Einordnung komplexer DNS-Strukturen. Aggregate Reports erhalten ein präziseres und erweiterbares XML-Schema.

Der eigentliche Grund für DMARC hat sich dabei kein Stück geändert: Jeder kann versuchen, Nachrichten mit einer gefälschten Absenderadresse Ihrer Domain zu versenden. DMARC verhindert diesen Versand nicht direkt. Es gibt empfangenden Systemen aber eine belastbare Grundlage, solche Nachrichten zu erkennen und angemessen zu behandeln.

Und genau solche Identitätsmissbräuche bilden weiterhin den Ausgangspunkt vieler Phishing-Kampagnen.

Wer noch gar kein DMARC einsetzt sollte jetzt überlegen wie er den DNS Record implementiert und mit welchen Tools er die XML-Reports auswerten möchte.