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

RFC 9990 — die aggregierten Berichte (RUA)

Die aggregierten Berichte sind die täglichen Zusammenfassungen, die die Empfänger an die 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. Wer diese Berichte lesen lernen will, findet die Anleitung in 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, nach der die meisten Leser hier suchen.

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 den eigenen Eintrag bedeutet

Die gute Nachricht, erneut: nichts Dringendes. Der aktuelle 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 die Phantom-Subdomains abzudecken;
• sich 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. Die neuen Tags lassen sich 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:berichte@beispiel.de

Und derselbe, modernisiert für DMARCbis:

v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s; rua=mailto:berichte@beispiel.de

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 % des Eintrags bewegen sich nicht.

Wen betrifft welche RFC

Die drei Dokumente richten sich nicht an dasselbe Publikum, und zu wissen, welches den eigenen Fall betrifft, erspart achtzig Seiten umsonst gelesener Spezifikation:

• DMARC für die eigene Domain veröffentlichen? Nur die RFC 9989 ist wirklich einschlägig, und selbst davon: nur der Teil über die Tags. Reporting-Code wird dabei nie geschrieben, nur konsumiert.
• Berichte empfangen und analysieren (selbst oder über einen Dienstleister)? Die RFC 9990 beschreibt, was ankommt und wie es zu interpretieren ist.
• Eine DMARC-Lösung entwickeln oder einen Mail-Dienst betreiben? Alle drei RFCs sind einschlägig, 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; sie zu lesen ist für die Konformität nicht nötig, nur den richtigen Eintrag zu veröffentlichen.

Eine Vokabelfrage: Existiert „DMARC V2" wirklich?

Überall kursieren „DMARC V2" oder „DMARC 2.0". 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. Behauptet also ein Werkzeug oder ein Artikel, ein Eintrag müsse „auf DMARC2 umgestellt" werden, ist Misstrauen angebracht: Das ist falsch und verrät ein schlechtes Verständnis des Standards.

Wie sich prüfen lässt, ob ein Eintrag „aktuell" ist

Es braucht nicht die Lektüre der drei RFCs, um zu wissen, ob ein 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, gehört es entfernt; es wird von aktuellen Implementierungen ignoriert.
• np vorhanden — ohne dieses Tag sind die nicht existierenden Subdomains nicht abgedeckt.

Ein Analyzer macht diese Prüfungen in wenigen Sekunden: Unser kostenloser DMARC-Analyzer meldet zu einer eingegebenen Domain die veralteten Tags und die Lücken. Die eigene Haltung lässt sich 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 verfügbar, für alle, die die Quelle der Wahrheit wollen. 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 die 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. Auf Absenderseite 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 den Domain-Betreiber bedeutet diese Modularität konkret, dass Stabilität und Weiterentwicklung sich nicht mehr gegenseitig blockieren. Der Teil, der ihn betrifft — die Tags, die er veröffentlicht — 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 der eigene Eintrag anzufassen wäre. 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 auf Absenderseite ohnehin nichts geschrieben wird, und der stabile Teil ist genau der, der täglich veröffentlicht wird 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.

Thomas übersetzt die RFCs in DNS

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

Die Domain kostenlos analysieren oder ein Konto erstellen, um zu starten. Für den Einstieg ins Thema: dieser neue Standard einfach erklärt.