RFC 9989, 9990, 9991: Was sich in DMARC wirklich ändert

Wenn man von „DMARCbis" spricht, spricht man in Wirklichkeit von drei Dokumenten, die im Mai 2026 gemeinsam von der IETF veröffentlicht wurden: die RFCs 9989, 9990 und 9991. Zusammen ersetzen sie die alte RFC 7489 von 2015. Diese Aufteilung ist kein Zufall: Sie trennt klar das Protokoll, die aggregierten Berichte und die Fehlerberichte, wo die 7489 alles vermischte. Dieser Leitfaden geht die Rolle jeder RFC durch und listet genau auf, was hinzugefügt, entfernt oder geklärt wurde. Für die Gesamtschau für ein breites Publikum beginnst du besser mit DMARCbis einfach erklärt.

Warum drei Dokumente und nicht eines

Die RFC 7489 war ein einziger Text mit Status Informational — ein Referenzdokument, keine Norm. DMARCbis korrigiert zwei Dinge auf einen Schlag: Es bringt DMARC auf den Standards-Track (Proposed Standard) und zerlegt die Spezifikation in drei, damit jedes Thema sein eigenes Leben führen kann. Konkret kann eine Reporting-Implementierung nun weiterentwickelt werden, ohne den Kern des Protokolls zu berühren, und umgekehrt.

RFC 9989 — der Kern des Protokolls

Das ist das Herzstück, der direkte Erbe der 7489. Sie definiert:

• die im DNS veröffentlichte Policy (p, sp und nun np);
• den Alignment-Mechanismus, der SPF/DKIM mit der Domain des From: verbindet;
• den DNS Tree Walk, der die Public Suffix List zur Identifizierung der Organisationsdomain ersetzt;
• die Gesamtheit der gültigen Tags und ihre Semantik.

Wenn du nur eine der drei lesen müsstest, wäre es diese. Das Alignment-Prinzip selbst hat sich kein Jota verändert — wenn dir dieser Begriff unklar erscheint, lies noch einmal wie die drei Protokolle zusammenarbeiten.

RFC 9990 — die aggregierten Berichte (RUA)

Die aggregierten Berichte sind die täglichen Zusammenfassungen, die die Empfänger an deine rua=-Adresse senden. Die RFC 9990 widmet ihnen nun ein ganzes Dokument: XML-Format, Inhalt, Häufigkeit und bewährte Versandpraktiken. Der Inhalt bleibt vertraut — Zählungen pro Versandquelle, mit den Alignment-Ergebnissen von SPF/DKIM — aber zwei Details ändern sich im Block policy_published der Berichte: Das Tag pct erscheint dort nicht mehr, und das Tag np kann dort auftauchen. Wenn du lernen willst, diese Berichte zu lesen, siehe wie man die aggregierten Berichte liest.

RFC 9991 — die Fehlerberichte (RUF)

Die Fehlerberichte (auch forensische Berichte genannt) sind der andere, weitaus seltenere Kanal. Sie können Stichproben enthalten — daher starke Datenschutzauflagen, die dazu führen, dass viele Empfänger schlicht keine senden. Die RFC 9991 rahmt diesen Kanal separat ein, gerade damit seine Vertraulichkeitsfragen den Rest des Protokolls nicht belasten. Für den praktischen Unterschied zwischen den beiden Typen siehe wie man die aggregierten Berichte liest.

Die Tags: Was hinzugefügt, entfernt, beibehalten wird

Das ist die Tabelle, die du wahrscheinlich gesucht hast, als du hier ankamst.

Hinzugefügte Tags:

• np — Policy für nicht existierende Subdomains (vgl. das np-Tag).
• psd — Marker für Public-Suffix-Domain (für die Registrys).
• t — binärer Testmodus (t=y), der den prozentualen Rollout ersetzt.

Entfernte Tags:

• pct — der Rollout „über einen Prozentsatz der Mail", als wenig verlässlich eingestuft, wird zugunsten von t entfernt (vgl. Ende von pct).
• ri und rf — das Intervall und das Format der Berichte wandern in die Reporting-Dokumente (9990/9991), sie befinden sich nicht mehr im Kern des Protokolls.

Unveränderte Tags:

• v (weiterhin v=DMARC1), p, sp, adkim, aspf, fo, rua, ruf — gleiche Bedeutung wie in der 7489.

Was das für deinen Eintrag bedeutet

Die gute Nachricht, erneut: nichts Dringendes. Dein aktueller Eintrag bleibt vollkommen gültig, und er beginnt weiterhin mit v=DMARC1. Die einzigen sinnvollen Nachbesserungen:

• pct entfernen, falls es noch darin steht (es wird von aktuellen Implementierungen nicht mehr interpretiert);
• np=reject hinzufügen, um deine Phantom-Subdomains abzudecken;
• dich nicht um ri/rf sorgen: Ihr Verschwinden aus dem Kern ist auf Absenderseite transparent.

Der detaillierte Fahrplan, Schritt für Schritt, steht in muss man migrieren.

Warum der Wechsel zum „Proposed Standard" zählt

Über die Technik hinaus hat der Statuswechsel eine konkrete Tragweite. Ein Proposed Standard ist ein weit solideres Fundament für Auditoren und Regulatoren: „DMARC gemäß RFC 9989" zu zitieren hat mehr Gewicht als ein Informational-Dokument zu zitieren. Für Organisationen, die Rahmenwerken wie NIS2 oder DORA unterliegen, in denen die E-Mail-Authentifizierung eine erwartete Kontrolle ist, ist das ein zusätzliches Konformitätsargument. Wir sprechen darüber in Banken.

Und die Interoperabilität während des Übergangs?

Eine Frage kommt oft wieder: „Wenn ich die neuen Tags übernehme, werden die alten Empfänger dann brechen?" Nein. DMARCbis ist auf Rückwärtskompatibilität ausgelegt: Ein Empfänger, der np oder t noch nicht kennt, ignoriert einfach, was er nicht versteht, und wendet p, sp und das Alignment weiterhin wie zuvor an. Du kannst die neuen Tags also ab sofort veröffentlichen, ohne zu warten, bis das gesamte Ökosystem aktualisiert ist — es gibt keinen Nachteil, voraus zu sein, und einen echten Vorteil darin, die Lücke der nicht existierenden Subdomains zu schließen.

Ein Eintrag vorher / nachher

Nichts geht über ein konkretes Beispiel, um zu sehen, was die RFCs ändern. Hier ein typischer Eintrag, wie man ihn unter der RFC 7489 schrieb:

v=DMARC1; p=reject; sp=reject; pct=100; adkim=s; aspf=s; rua=mailto:rapports@ton-domaine.fr

Und derselbe, modernisiert für DMARCbis:

v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s; rua=mailto:rapports@ton-domaine.fr

Nur zwei Unterschiede: pct=100 ist verschwunden (das Tag ist entfernt, und pct=100 diente ohnehin zu nichts), und np=reject ist aufgetaucht, um die nicht existierenden Subdomains abzudecken. Alles Übrige — v=DMARC1, p, sp, das strikte Alignment, das rua — ist identisch. Genau deshalb spricht man von einer Revision und nicht von einer Neuschreibung: 90 % deines Eintrags bewegen sich nicht.

Wen betrifft welche RFC

Die drei Dokumente richten sich nicht an dasselbe Publikum, und zu wissen, welches dich betrifft, erspart dir, 80 Seiten umsonst zu lesen:

• Du veröffentlichst DMARC für deine Domain? Nur die RFC 9989 betrifft dich wirklich, und selbst davon: nur der Teil über die Tags. Du schreibst niemals Reporting-Code, du konsumierst ihn.
• Du empfängst und analysierst Berichte (oder dein Dienstleister tut es)? Die RFC 9990 beschreibt, was du empfängst und wie du es interpretierst.
• Du entwickelst eine DMARC-Lösung oder betreibst einen Mail-Dienst? Alle drei RFCs betreffen dich, dazu die Abschnitte über den Tree Walk und die Interoperabilität.

Für die große Mehrheit der Organisationen hält sich die eigentliche Arbeit in zwei Zeilen DNS (siehe das Beispiel oben). Die RFCs sind die Referenz; du musst sie nicht lesen, um konform zu sein, nur den richtigen Eintrag veröffentlichen.

Eine Vokabelfrage: Existiert „DMARC V2" wirklich?

Du wirst überall „DMARC V2" oder „DMARC 2.0" sehen. Das sind praktische Spitznamen, keine offiziellen Begriffe: Die IETF spricht von „DMARCbis" (das Suffix -bis bedeutet „die revidierte Version"). Und vor allem existiert kein v=DMARC2 in der Syntax — der Identifier bleibt v=DMARC1. Wenn dir also ein Werkzeug oder ein Artikel sagt, du müsstest in deinem Eintrag „auf DMARC2 umstellen", sei misstrauisch: Das ist falsch und verrät ein schlechtes Verständnis des Standards.

Wie du prüfst, dass du „aktuell" bist

Du musst nicht die drei RFCs lesen, um zu wissen, ob dein Eintrag modern ist. Drei Kontrollen genügen:

• v=DMARC1 am Anfang — immer vorhanden (sonst ist es kein gültiger DMARC-Eintrag).
• Kein pct — falls noch eines übrig ist, entferne es; es wird von aktuellen Implementierungen ignoriert.
• np vorhanden — ohne dieses Tag sind deine nicht existierenden Subdomains nicht abgedeckt.

Ein Analyzer macht diese Prüfungen in wenigen Sekunden: Gib deine Domain in unseren kostenlosen DMARC-Analyzer ein, der die veralteten Tags und die Lücken meldet. Du kannst deine Haltung auch im Vergleich zu einer ganzen Branche im Observatorium verorten — wo man mit Zahlen sieht, wie viele Domains nicht einmal p=reject erreicht haben.

Die RFCs selbst sind öffentlich und kostenlos auf der Website der IETF, falls du die Quelle der Wahrheit willst. Aber für nahezu alle Fälle gilt: Der Eintrag zählt mehr als der Text: Das ist es, was die Empfänger sehen, und er ist es, der deine Domain schützt — oder nicht. 80 Seiten RFC zu lesen ändert nichts, solange der veröffentlichte Eintrag nicht aktuell ist.

Kurz gefasst

DMARCbis ist nicht ein einzelnes Dokument, sondern drei RFCs: 9989 (das Protokoll und seine Tags), 9990 (die aggregierten Berichte) und 9991 (die Fehlerberichte), die zusammen die RFC 7489 ersetzen. Für dich hält sich das Wesentliche in zwei Handgriffen — np hinzufügen, pct entfernen — auf einem Eintrag, der weiterhin mit v=DMARC1 beginnt. Der Wechsel zum Proposed Standard stärkt vor allem den Wert von DMARC als auditierbare Kontrolle.

Warum die Trennung in drei Dokumente langfristig zählt

Die Aufteilung in drei RFCs mag auf den ersten Blick wie eine reine Formalität der IETF wirken, aber sie hat eine handfeste Konsequenz für die kommenden Jahre. Solange alles in einem einzigen Dokument steckte, konnte man das Reporting-Format nicht weiterentwickeln, ohne den Text zu berühren, der auch das Kernprotokoll definierte — jede kleine Anpassung am XML-Schema der Berichte hätte theoretisch eine Neuauflage der gesamten Spezifikation bedeutet. Mit der Trennung kann die RFC 9990 künftig überarbeitet werden, um ein neues Feld in den aggregierten Berichten aufzunehmen, ohne dass die RFC 9989, die die Policy und das Alignment beschreibt, angetastet wird. Umgekehrt könnte der Kern des Protokolls präzisiert werden, ohne die Reporting-Dokumente neu freigeben zu müssen.

Für dich als Domain-Betreiber bedeutet diese Modularität konkret, dass Stabilität und Weiterentwicklung sich nicht mehr gegenseitig blockieren. Der Teil, der dich betrifft — die Tags, die du veröffentlichst — lebt in der stabilsten der drei RFCs, der 9989. Die beweglicheren Teile, die das Format und den Versand der Berichte betreffen, sind ausgelagert und können sich anpassen, ohne dass du deinen Eintrag anfassen musst. Das ist genau der Grund, warum die Migration zu DMARCbis für die allermeisten Organisationen so wenig Aufwand bedeutet: Der veränderliche Teil des Standards liegt dort, wo du ohnehin nichts schreibst, und der stabile Teil ist genau der, den du täglich veröffentlichst und der zu 90 % identisch bleibt. Diese saubere Trennung von Verantwortlichkeiten ist auch das, was Auditoren und Werkzeug-Herstellern das Leben erleichtert: Jeder liest genau das Dokument, das seinen Zuständigkeitsbereich betrifft, ohne sich durch achtzig Seiten zu arbeiten, die ihn nichts angehen.

Lass Thomas die RFCs in DNS übersetzen

Drei RFCs zu lesen, um daraus zwei Zeilen DNS zu ziehen, ist keine gute Allokation deiner Zeit. Thomas, dein virtueller CISO, kennt DMARCbis: Er erzeugt den genauen Eintrag, den du veröffentlichen musst — Tags np und t inbegriffen — ausgehend vom realen Zustand deiner Domain, benennt jede Versandquelle aus deinen Berichten und begleitet dich bis p=reject.

Analysiere deine Domain kostenlos → oder erstelle ein Konto, um zu starten. Neu beim Thema? Beginne mit diesem neuen Standard einfach erklärt.