RFC 9989: DMARC strich drei Tags, 46 % veröffentlichen eines

RFC 9989 machte DMARC im Mai 2026 zu einem echten Internetstandard und strich dabei drei Tags: pct, ri und rf. Von 173 aktiven DMARC-Records, die wir am 15. August 2026 von echten versendenden Domains aufgelöst haben, veröffentlichen 79 noch mindestens eines davon. Fast keine dieser Domains wird es merken, denn 66 der 68 Records mit pct setzen es auf 100, was vorher nichts bewirkte und jetzt nichts bewirkt.

Die Ausnahme ist der Record, den ein sorgfältiger Versender am ehesten veröffentlicht hat. Eine Policy quarantine oder reject mit einem pct unter 100 war eine bewusste Rampe, die die Durchsetzung auf einen Teil der fehlschlagenden Mail anwandte. Dieser Teil ist bei jedem Empfänger nach dem aktuellen Standard weg, und der Record wurde strenger, ohne dass jemand das DNS bearbeitet hat.

Dieser Leitfaden behandelt jede Änderung aus RFC 9989, die einen veröffentlichten Record erreicht, mit den Abschnittsnummern zum Nachprüfen.

RFC 9989 ersetzte drei Dokumente, nicht eines

RFC 9989 macht RFC 7489 und RFC 9091 obsolet und steht auf dem Standards Track statt informell zu sein. Dieser Statuswechsel ist die eigentliche Substanz: DMARC verbrachte acht Jahre als informelles Dokument, das beschrieb, was ein bestehender Rollout tat, und ist jetzt eine Spezifikation, an die Empfänger sich halten sollen.

Zwei Begleitdokumente haben die Reporting-Hälfte abgespalten, und beide machen RFC 7489 ebenfalls obsolet. RFC 9990 deckt Aggregat-Reports ab, die als XML an Ihre rua-Adresse kommen. RFC 9991 deckt Failure-Reports ab, die pro Nachricht an ruf gehen. RFC 9091 war die experimentelle Erweiterung für Public-Suffix-Domains, und ihr psd-Tag überlebt in der Hauptspezifikation.

Eine Seite, die 2026 für irgendetwas an DMARC RFC 7489 zitiert, zitiert ein Dokument, das drei verschiedene RFCs ersetzt haben. Dazu zählt der größte Teil der Anbieterdokumentation, und dazu zählen die Versender-Hinweise von Google und Microsoft, die DMARC weiterhin in den Begriffen von RFC 7489 beschreiben.

Drei Tags sind als historic registriert, was nicht dasselbe ist wie unbekannt

RFC 9989 hat eine IANA-Registry für DMARC-Tags geschaffen und pct, ri und rf mit dem Status historic eingetragen. Der RFC definiert diesen Status mit eigenen Worten: Das Tag "is considered deprecated and is not expected to be in use in any current implementation".

Tag	Was es tat	Status jetzt
pct	Stichprobenrate, der Anteil fehlschlagender Mail, für den die Policy galt	Historic
ri	Intervall für Aggregat-Reports, in Sekunden	Historic
rf	Format der Failure-Reports	Historic

Historic ist ein anderer Zustand als unbekannt, und ein Checker muss ihn als solchen behandeln. Diese drei haben Namen, eine dokumentierte Geschichte und, im Fall von pct, einen erklärten Grund für den Abgang. Ein unbekanntes Tag ist etwas, das niemand definiert hat. Beide ignoriert ein konformer Empfänger, und keines darf einen Record ungültig machen, aber nur eines lohnt es, dem Veröffentlicher beim Namen zu nennen.

Was ein Empfänger mit irgendeinem davon tut, klärt Abschnitt 4.8: "Unknown tags MUST be ignored. Syntax errors in the remainder of the record MUST be discarded in favor of default values (if any) or ignored outright". pct=abc und pct=50 sind bei einem RFC-9989-Empfänger also gleich wirkungslos, und ein Checker, der einen Record wegen eines der beiden rot färbt, meldet einen Fehler, auf den kein Empfänger reagiert.

Nur eine der drei Streichungen ändert, was mit Ihrer Mail passiert

pct ist das Tag, dessen Rückzug lebende Mail bewegt hat, und zwar in die strenge Richtung. Unter RFC 7489 bat p=reject; pct=25 die Empfänger, ein Viertel der fehlschlagenden Nachrichten zurückzuweisen und auf den Rest die nächstniedrigere Policy anzuwenden. Bei einem RFC-9989-Empfänger wird das Tag ignoriert und p=reject gilt für jede fehlschlagende Nachricht.

Niemand hat dafür das DNS bearbeitet. Der Record ist identisch und das Ergebnis nicht, was das Gegenteil davon ist, wie sich ein Rückzug sonst anfühlt.

Beide Verhaltensweisen sind gleichzeitig aktiv, und das ist der Teil, um den herum man planen sollte. Google und Microsoft haben sich nicht auf die Semantik von RFC 9989 festgelegt und ihre Versender-Dokumentation beschreibt weiterhin Stichproben, derselbe Record kann also am selben Tag beim einen Empfänger als Stichprobe und beim anderen voll durchgesetzt werden.

Daraus ergibt sich auch die Reihenfolge der Schritte. Ein pct unter 100 zu löschen erhöht die Durchsetzung bei jedem Empfänger, der es noch beachtet, die sichere Abfolge ist also: erst die Durchsetzungsstufe erreichen, die Sie wirklich wollen, dann das Tag löschen. Andersherum ist es eine Erhöhung der Durchsetzung, verkleidet als Aufräumen.

ri und rf sind leiser. ri bat um ein Reporting-Intervall in Sekunden, und Empfänger schickten überwiegend tägliche Reports, ganz gleich was dort stand. rf benannte ein Format für Failure-Reports, und afrf war der einzige Wert, den überhaupt jemand veröffentlichte. Beide zu entfernen ändert nichts an Ihrer Mail.

Das p-Tag ist keine Pflicht mehr, und zwei Gewohnheiten gehen mit

RFC 9989 führt p als "RECOMMENDED for DMARC Policy Records" statt als Pflicht, und die formale Grammatik nennt nur das Versions-Tag als zwingend. Ein Record ohne p ist kein Syntaxfehler.

Zwei Regeln, die ältere Checker durchsetzen, sind damit weg, und beide weisen Records zurück, die jeder Empfänger akzeptiert:

• Die Tag-Reihenfolge nach v ist nicht festgelegt. RFC 7489 setzte p an zweite Stelle, und Googles Dokumentation für Veröffentlicher sagt das immer noch. RFC 9989 nicht.
• Tag-Werte sind nicht case-sensitiv. Es sind einfache ABNF-Literale, p=Reject ist also gültig.

Ein fehlendes p ist weiterhin einen Hinweis wert, denn ein Record ohne Policy ist eine echte Folge für die Domain. Es ist nur kein Syntaxfehler, und dieser Unterschied entscheidet, was dem Leser zu tun gesagt wird.

Ein Record wird aus genau zwei Gründen verworfen, und das sind verschiedene Zustände

Drei Fehlerzustände müssen auseinandergehalten werden, denn sie zusammenzuwerfen ist die Art, wie ein Checker einer ungeschützten Domain sagt, sie habe bloß einen Tippfehler. Das ist der Teil, den fast keine Erklärung abdeckt, und der Teil, der entscheidet, ob ein Werkzeug richtig liegt.

Das Versions-Tag ist falsch. Fehlend, nicht an erster Stelle oder nicht exakt DMARC1 unter Beachtung der Groß- und Kleinschreibung. Abschnitt 4.7: "the entire record MUST be ignored". Die Policy-Ermittlung läuft darüber hinaus weiter, der Name kann also noch von einem Record weiter oben im Baum gedeckt sein.

Die Policy ist unbrauchbar. p fehlt oder ist unbekannt, oder ein sp oder np ist vorhanden und ungültig. Abschnitt 4.10.1 steckt alle drei in einen Zweig, und das Ergebnis hängt von rua ab: mit mindestens einer syntaktisch gültigen Reporting-URI "the Mail Receiver MUST act as if a record containing p=none was retrieved", und ohne eine wendet der Empfänger überhaupt keine DMARC-Verarbeitung auf die Nachricht an. Dieses zweite Ergebnis ist schlechter als p=none und schlechter, als gar nichts zu veröffentlichen.

Alles andere wird an Ort und Stelle repariert. Wieder Abschnitt 4.8: ein schlechtes fo, ein schlechtes t, ein historic-Tag, ein unbekanntes Tag. Keines davon darf einen Record ungültig machen.

Der Satzteil, den man übersieht, steht im zweiten Punkt. Ein Tippfehler in sp verwirft ein völlig gutes p=reject als Ganzes. v=DMARC1; p=reject; sp=quarintine schützt nichts, und ein Checker, der das lesbare p meldet, gibt einer offenen Domain ein grünes Abzeichen. Wenn Sie sp oder np veröffentlichen, tragen sie ein Gewicht, das p allein nicht hat, und bei der Subdomain-Policy fällt das am stärksten ins Gewicht.

Was 173 aktive DMARC-Records tatsächlich veröffentlichen

Wir pflegen ein Korpus von DMARC-Records, die echte versendende Domains veröffentlichen, aufgelöst über dns.google per DoH, als Falsch-positiv-Kontrolle für unseren eigenen Parser: Jeder Record darin trägt echte Mail, jeder Fehler, den unser Analyzer dagegen erhebt, ist also falsch, bis das Gegenteil bewiesen ist. So sahen die Tags am 15. August 2026 aus.

Tag	Records damit	Anteil
Mindestens ein historic-Tag	79	46 %
pct	68	39 %
pct auf 100 gesetzt	66	38 %
pct unter 100	2	1 %
ri	16	9 %
rf	11	6 %
Alle drei historic-Tags	1	unter 1 %

Zwei Dinge fallen auf, und das zweite erklärt, warum das erste wenig ausmacht. Fast die Hälfte des Korpus trägt ein gestrichenes Tag, was beunruhigend klingt, bis man auf die Werte sieht: 66 der 68 pct-Tags stehen auf 100, einem Wert, der die Policy vor RFC 9989 auf alles anwandte und sie jetzt auf alles anwendet. Die ri-Werte sind 3600, 14400 und 86400 Sekunden, und schlicht jeder rf-Wert ist afrf.

Das Risiko ist ein Record von 173: ein p=reject; pct=25, das um ein Viertel bat und jetzt alles bekommt. Das ist das gesamte praktische Risiko dieser Streichung, und es konzentriert sich bei den Versendern, die sorgfältig waren.

Dieses Korpus ist eine Menge von Domains, die wir verfolgen, keine Zufallsstichprobe des Internets, lesen Sie die Anteile also als das Aussehen echter veröffentlichter Records und nicht als Messung aller Domains. Für die Zahl über die Grundgesamtheit: 48 % veröffentlichen überhaupt eine DMARC-Richtlinie im Unspam 2026 Email Deliverability Benchmark.

Reporting-Ziele in einer anderen Domain müssen jetzt zustimmen

Abschnitt 4 von RFC 9990 verlangt, dass ein Empfänger prüft, ob ein externes Reporting-Ziel dem Empfang Ihrer Reports zugestimmt hat, und jede URI verwirft, die er nicht bestätigen kann. Abschnitt 5 von RFC 9991 wiederholt das für ruf. RFC 7489 sagte, solche Prüfungen "are to be taken"; der neue Text macht daraus ein MUSS und streicht die Hintertür, die einem Empfänger erlaubte, die Prüfung zugunsten einer eigenen Liste zu überspringen.

In der Praxis heißt das: Ein rua, das auf die Domain eines Anbieters zeigt, braucht einen Record in der Zone dieses Anbieters, der Ihrer Domain den Versand dorthin erlaubt. Die meisten Reporting-Anbieter veröffentlichen ihn automatisch, wenn Sie eine Domain hinzufügen, das ist also meist eine Tatsache über eine Einrichtung, die Sie nicht selbst gemacht haben, und keine Änderung an einer, die Sie gemacht haben.

Im selben Tag steckt eine separate Falle, die älter ist als RFC 9989 und weiterhin Leute erwischt. Die Record-Grammatik nutzt zwei verschiedene Trennzeichen: Semikolons trennen Tags, Kommas trennen URIs innerhalb eines Tags. rua=mailto:a@example.com; mailto:b@example.net ist also keine Liste aus zwei Adressen. Es ist ein rua-Tag, gefolgt von einem losen Term, der kein tag=value ist, und die zweite Adresse bekommt nichts. Ein Checker aus Tag-für-Tag-Regulärausdrücken kann das nicht sehen, weil jeder Ausdruck nur fragt, ob sein eigenes Tag irgendwo vorkommt.

BIMI zitiert weiterhin RFC 7489, und das ist richtig so

Die BIMI-Spezifikation widerspricht RFC 9989 bei pct mit Absicht, und beide Aussagen sind aktuell. RFC 9989 machte das Tag im Mai 2026 historic. Der im selben Monat veröffentlichte BIMI-Entwurf zitiert weiterhin RFC 7489, und sein Abschnitt 7.1 blockiert weiterhin ein Logo, wenn ein p=quarantine-Record ein pct trägt, das nicht 100 ist.

Eine Domain kann also einen unter RFC 9989 tadellos modernen Record haben und trotzdem an der BIMI-Prüfung scheitern, wegen eines Tags, das DMARC nicht mehr kennt. Alles zu BIMI wird auf eine Entwurfsfassung zitiert und nie auf einen RFC, denn es gibt keinen BIMI-RFC: Die aktuelle Fassung ist draft-brand-indicators-for-message-identification-14 vom 1. Mai 2026.

Das ist die Art von Detail, die verloren geht, wenn ein Werkzeug einen einzigen DMARC-Parser über mehrere Funktionen teilt. Der BIMI-Pfad braucht seine eigene pct-Prüfung, die überlebt, wenn ein Parser in RFC-9989-Form das Tag fallen lässt.

Was Sie diese Woche mit Ihrem Record tun

Lesen Sie Ihren Record, bevor Sie ihn ändern, denn drei dieser Prüfungen hängen an Werten, an deren Veröffentlichung Sie sich vielleicht nicht erinnern. Unser DMARC-Record-Checker parst nach der Grammatik von RFC 9989 und sortiert Tags in aktiv, historic und unbekannt, ein gestrichenes Tag wird also als Hinweis gemeldet und nicht als Fehler.

1. Suchen Sie nach einem pct unter 100. Finden Sie eines und steht Ihre Policy auf quarantine oder reject, ist Ihr Record bei manchen Empfängern bereits strenger, als Sie denken. Entscheiden Sie die gewünschte Durchsetzungsstufe, erreichen Sie sie, und löschen Sie das Tag danach.
2. Prüfen Sie sp und np Zeichen für Zeichen. Ein Tippfehler in einem von beiden verwirft den ganzen Record. Brauchen Sie keine abweichende Subdomain-Policy, ist es sicherer, sie nicht zu veröffentlichen, als sie ungefähr zu veröffentlichen.
3. Löschen Sie ri und rf, wann es Ihnen passt. Sie sind wirkungslos und waren dem immer nahe.
4. Bestätigen Sie, dass Ihr rua Kommas zwischen Adressen verwendet, keine Semikolons, wenn es mehr als eine listet.
5. Lassen Sie ein pct=100 in Ruhe, außer Sie bearbeiten ohnehin gerade. Es ist Rauschen, kein Fehler.

Wenn Sie einen Record von Grund auf bauen statt einen zu prüfen, erzeugt der DMARC-Record-Generator aktuelle Syntax, und was DMARC tut behandelt den Mechanismus hinter den Tags.

Ein Tag, das niemand beachtet, ist kein kaputter Record

Der häufigste Fehler in den Texten zu dieser Änderung ist, ein historic-Tag als Fehler zu behandeln. Das ist es nicht, und Abschnitt 4.8 ist eindeutig darin, warum: Ein Empfänger ignoriert, was er nicht erkennt, und repariert, was er nicht parsen kann, statt den Record wegzuwerfen. Ein Werkzeug, das einen Record wegen pct rot färbt, schickt seinen Nutzer dazu, funktionierendes DNS zu bearbeiten, und das ist schlimmer, als nichts zu sagen.

Die einzige Stelle, an der eine Warnung verdient ist, ist der enge Fall oben, und sie verdient sie, weil sie eine Aussage über Ihre Mail ist und nicht über Ihre Syntax: Ein pct unter 100 bei Durchsetzung heißt, dass Ihre Policy jetzt für Nachrichten gilt, die sie vorher verschonte. Alles andere an dieser Streichung ist Hausarbeit.

Lassen Sie Ihre Domain durch den DMARC-Record-Checker laufen und schicken Sie dann eine Testnachricht, um zu sehen, ob die Policy, die Sie veröffentlichen, zu dem passt, wo Ihre Mail tatsächlich landet.