DMARC nach RFC 9989: Was sich am DNS-Eintrag ändert

Was RFC 9989 an DMARC ändert

DMARC war bisher kein Internetstandard im engeren Sinn. RFC 7489 erschien im März 2015 als informatorisches Dokument (RFC 7489), und zwar über den Weg der unabhängigen Einreichungen, nicht als Ergebnis einer Arbeitsgruppe der IETF (RFC 9989). Die neue Fassung ist ein Dokument auf dem Standards Track der IETF. Sie ersetzt neben RFC 7489 auch RFC 9091, das experimentelle Verfahren für DMARC auf öffentlichen Suffixen wie Länderendungen; dieses Experiment wurde nach den Angaben in RFC 9989 nicht so umgesetzt, wie es geschrieben war (RFC 9989).

Die Berichte sind in eigene Dokumente gewandert. RFC 9990 beschreibt die Sammelberichte, die Empfänger an die Adresse aus rua schicken (RFC 9990), RFC 9991 die Fehlerberichte zu einzelnen Nachrichten an die Adresse aus ruf (RFC 9991). Beide ersetzen die entsprechenden Teile von RFC 7489.

Für den Eintrag selbst gibt es eine beruhigende Nachricht: Die Version bleibt v=DMARC1. Neue Tags verlangen ausdrücklich keine neue Version, weil Prüfer unbekannte Tags ignorieren müssen (RFC 9989). Ein bestehender Eintrag bleibt also gültig. Er tut nur unter Umständen nicht mehr das, was sein Verfasser damals beabsichtigt hat, und genau darum geht es in den folgenden Abschnitten.

Der DMARC-Eintrag Tag für Tag

Ein typischer Eintrag aus den vergangenen Jahren sieht etwa so aus: v=DMARC1; p=quarantine; pct=50; rf=afrf; ri=86400; rua=mailto:dmarc@example.com!10m. Fast jedes Element darin ist von der neuen Fassung berührt. Die Tabelle zeigt, was mit jedem Tag geschieht und was für den eigenen Eintrag daraus folgt.

Entfallen heißt nicht falsch: Ein Eintrag mit ri=86400 bleibt gültig, das Tag wird nur nicht mehr ausgewertet. Bei pct dagegen hängt das Verhalten davon ab, nach welcher Fassung der empfangende Server prüft.

pct entfällt: warum 50 Prozent nicht zuverlässig wirkten

Die Idee hinter pct war einleuchtend. RFC 7489 erlaubte jede ganze Zahl von 0 bis 100 (RFC 9989), und Domaininhaber sollten damit schrittweise von none zu quarantine oder von quarantine zu reject wechseln: Die strengere Behandlung trifft zunächst nur einen Teil der Nachrichten, die DMARC nicht bestehen. Viele Anleitungen der vergangenen Jahre bauen darauf eine Treppe aus mehreren Prozentstufen, auch ältere Beiträge auf diesem Blog wie die Anleitung zur Auswertung von DMARC-Reports. Deren Teil zur Auswertung der Berichte bleibt gültig, die Prozenttreppe ist mit RFC 9989 überholt.

Die Praxis sah anders aus. Nach den Betriebserfahrungen, die RFC 9989 festhält, wurde pct in der Regel nur bei den Werten 0 und 100 genau umgesetzt; bei allen anderen Werten wich die Umsetzung je nach Implementierung stark ab (RFC 9989). Der Wert 100 war einfach, weil er die Vorgabe war und keine Sonderbehandlung brauchte. Der Wert 0 bekam dagegen eine Bedeutung, die so nicht geplant war: Zwischenstationen wie Mailinglisten und manche Postfachanbieter nahmen ihn als Signal, die Absenderzeile From: umzuschreiben, damit weitergeleitete Nachrichten später nicht an DMARC scheitern (RFC 9989).

Aus dieser Erfahrung zieht RFC 9989 die Konsequenz: pct entfällt, und an seine Stelle tritt t mit den Werten y und n. t=y soll von Postfachanbietern und Zwischenstationen so behandelt werden wie früher pct=0, t=n wie pct=100 (RFC 9989). Im Register der DMARC-Tags führt die IANA pct jetzt mit dem Status „historic“, also als Tag, das in aktuellen Implementierungen nicht mehr erwartet wird (RFC 9989).

t=y: der Testbetrieb mit klarer Wirkung

Mit t=y bittet der Domaininhaber den prüfenden Empfänger, die veröffentlichte Richtlinie noch nicht anzuwenden. Die Erwartung ist genau beschrieben: Nachrichten, die DMARC nicht bestehen, werden eine Stufe milder behandelt. Aus p=quarantine mit t=y wird in der Wirkung none, aus p=reject mit t=y wird quarantine (RFC 9989). Auf eine Richtlinie none hat das Tag keine Wirkung, und an den Berichten ändert es nichts: Die Sammelberichte kommen weiter (RFC 9989).

Damit ist t=y das Werkzeug für die Phase, in der früher pct=0 stand. Der Domaininhaber veröffentlicht schon p=quarantine, die Empfänger behandeln scheiternde Nachrichten aber noch wie bei none, und Zwischenstationen mit Sonderbehandlung können die Absenderzeile umschreiben. In den Sammelberichten zeigt sich dann, über welche Wege Mail läuft, die ohne diese Umschreibung scheitern würde. Das Beispiel in RFC 9989 beschreibt genau diesen Fall für eine Test-Subdomain mit p=quarantine und t=y (RFC 9989).

Wichtig für die Praxis: t=y gilt für alle Richtlinien-Tags im Eintrag, also auch für sp und np (RFC 9989). Ein Eintrag mit np=reject und t=y schützt nicht existierende Subdomains damit nur auf der Stufe quarantine. Wer np=reject sofort voll wirksam haben will, kann im selben Eintrag nicht zugleich den Testbetrieb nutzen.

Übergangszeit: alte und neue Prüfer zugleich bedienen

RFC 9989 ist seit Mai 2026 veröffentlicht (RFC 9989), aber nicht jeder empfangende Server prüft ab diesem Tag nach der neuen Fassung. Für eine Weile arbeiten alte und neue Implementierungen nebeneinander. Beide Fassungen regeln, was mit Tags geschieht, die eine Implementierung nicht kennt: Sie müssen ignoriert werden (RFC 7489). Ein Prüfer, der nur RFC 7489 kennt, übergeht also t und psd, und ein Prüfer nach RFC 9989 wertet pct nicht mehr aus, weil die neue Fassung das Tag nicht mehr beschreibt.

Daraus ergibt sich, warum pct=50 in der Übergangszeit besonders unglücklich ist: Ein alter Prüfer wendet die Richtlinie auf höchstens die Hälfte der scheiternden Nachrichten an, ein neuer auf alle. Derselbe Eintrag wirkt bei zwei Empfängern verschieden, und die Sammelberichte werden schwer vergleichbar. Eindeutig wird der Eintrag erst, wenn pct fehlt oder auf 100 steht. Dann wenden beide Generationen die Richtlinie voll an, denn 100 war in RFC 7489 die Vorgabe (RFC 7489).

Für den Testbetrieb folgt daraus: Wer auch ältere Prüfer erreichen will, kann pct=0 neben t=y stehen lassen. Der alte Prüfer kennt t nicht und liest pct=0, der neue wertet pct nicht aus und liest t=y. Beide landen bei einer um eine Stufe milderen Behandlung, denn auch nach RFC 7489 sollten Nachrichten, die wegen pct nicht unter reject fallen, wie bei quarantine behandelt werden (RFC 7489). Sobald der Testbetrieb endet, verschwinden beide Tags gemeinsam.

np: Schutz für Subdomains, die es nicht gibt

Wer im Namen einer Marke Mails fälscht, greift gern zu Absendern, die plausibel klingen: rechnung.example.com, versand.example.com, service.example.com. Existieren diese Namen im DNS gar nicht, galt für sie bisher die Subdomain-Richtlinie sp oder, ohne sp, die Hauptrichtlinie p. Mit np kann der Domaininhaber für genau diesen Fall eine eigene Richtlinie setzen. Das Tag stammt aus dem Experiment RFC 9091 und ist jetzt fester Teil des Standards (RFC 9989).

Als nicht existierend gilt ein Name, für den das DNS mit NXDOMAIN antwortet; dann existieren auch alle Namen darunter nicht (RFC 9989). Fehlt np, gilt für solche Namen sp und, wenn auch das fehlt, p (RFC 9989). Das macht np zu einer der wenigen Änderungen, die sich ohne langen Vorlauf lohnen: Von einer Subdomain, die es im DNS nicht gibt, kommt in aller Regel keine legitime Mail. Ein Eintrag, der für die Hauptdomain noch mit p=none beobachtet, kann deshalb schon np=reject tragen. Die Richtlinie trifft ohnehin nur Nachrichten, die DMARC nicht bestehen.

Vor dem Setzen lohnt trotzdem ein Blick in die Sammelberichte. Taucht dort eine Absender-Subdomain mit scheiternder Authentifizierung auf, die tatsächlich von einem eigenen Dienst stammt, etwa einem Ticketsystem oder einem Versanddienst für Rechnungen, gehört zuerst dieser Dienst korrekt eingerichtet. Für Domains, die gar keine Mail verschicken, sieht das BSI in seiner Technischen Richtlinie zur E-Mail-Authentifizierung ohnehin eine DMARC-Richtlinie reject vor (BSI); np=reject überträgt diesen Gedanken auf die Namen unterhalb einer aktiven Domain.

psd und der DNS Tree Walk

Das dritte neue Tag richtet sich an eine kleine Gruppe. Mit psd=y kennzeichnen Betreiber öffentlicher Suffixe, etwa Vergabestellen von Domainendungen, ihren Eintrag; psd=n erklärt einen Namen ausdrücklich zur Organisationsdomain für sich und alles darunter; die Vorgabe u überlässt die Bestimmung dem Verfahren (RFC 9989). Für den Eintrag eines Shops oder Unternehmens heißt das in der Regel: psd weglassen.

Interessanter ist, was dahintersteht. RFC 7489 bestimmte die Organisationsdomain mit Hilfe einer Public Suffix List, legte aber weder eine bestimmte Liste noch einen Abruftakt fest. RFC 9989 ersetzt das durch den DNS Tree Walk: Der Empfänger fragt von der Absenderdomain aus Stufe für Stufe die übergeordneten Namen ab und bestimmt aus den gefundenen DMARC-Einträgen die Organisationsdomain (RFC 9989). Damit Absenderdomains mit sehr vielen Labels keine Abfrageflut auslösen, führen auch sehr lange Namen zu höchstens acht DNS-Abfragen (RFC 9989).

Für die meisten Domains ändert sich am Ergebnis nichts, für verzweigte Organisationen mit tiefen Subdomain-Bäumen unter Umständen schon. RFC 9989 nennt den Ausweg selbst: Unterschiedliche Ergebnisse zwischen alter Listenlogik und neuem Tree Walk lassen sich mit strikter Ausrichtung und ausdrücklichen Einträgen für alle genutzten Absenderdomains vermeiden (RFC 9989). Ein Eintrag direkt am Absendernamen wird vor jedem Tree Walk abgefragt und hat damit Vorrang.

rf, ri und die Größenangabe: Reste, die raus können

Zwei weitere Tags entfallen ersatzlos. rf legte das Format der Fehlerberichte fest, mit der Vorgabe afrf; ri bat um ein Intervall zwischen zwei Sammelberichten, mit der Vorgabe 86400 Sekunden, also einem Tag (RFC 7489). Schon RFC 7489 verlangte nur tägliche Berichte verbindlich, kürzere Abstände galten als Entgegenkommen ohne Pflicht. RFC 9990 beschreibt den Berichtszeitraum jetzt ohne eigenes Tag: Er umfasst typischerweise einen UTC-Tag ab 0 Uhr (RFC 9990).

Auch die Größenangabe hinter einer Berichtsadresse, etwa !10m am Ende von rua=mailto:dmarc@example.com!10m, gehört zur alten Schreibweise. RFC 9989 führt sie nur noch als veraltete Syntax, die Berichtssender ignorieren sollen (RFC 9989). Bleibt sie stehen, schadet das nach dem Wortlaut nicht; ein aufgeräumter Eintrag ist trotzdem leichter zu prüfen.

Die Berichtsadressen selbst bleiben, wie sie sind. rua ist nach wie vor die Grundlage jeder Umstellung: Fehlt das Tag, dürfen Empfänger für die Domain keine Sammelberichte erzeugen (RFC 9989). ruf für Fehlerberichte zu einzelnen Nachrichten bleibt ebenfalls erlaubt. Das BSI rät allerdings davon ab, solche Berichte anzufordern, weil sie personenbezogene Daten transportieren (BSI). Wer ruf noch im Eintrag hat, sollte den Umbau nutzen, um diese Entscheidung bewusst zu treffen.

p=reject ist nicht für jede Domain das Ziel

Neu ist auch der Ton bei der strengsten Richtlinie. RFC 9989 hält ausdrücklich fest, dass Domains mit Nutzern, die an Mailinglisten schreiben könnten, kein p=reject veröffentlichen sollten (RFC 9989). Der Grund sind indirekte Wege wie Weiterleitungen, Rollenadressen und Listen, an denen SPF typischerweise scheitert. Wer dennoch reject will, soll nach RFC 9989 zuerst mindestens einen Monat mit p=none beobachten, dann ebenso lange mit p=quarantine arbeiten und die Ergebnisse vergleichen (RFC 9989).

Für Domains, die reject veröffentlichen, verlangt RFC 9989 außerdem gültige DKIM-Signaturen statt reiner SPF-Absicherung, weil DKIM eine Weiterleitung in der Regel übersteht (RFC 9989). Und auf der Empfängerseite steht ein Satz, der viele überraschen dürfte: Empfänger dürfen Nachrichten nicht allein wegen p=reject ablehnen und müssen ohne weitere Erkenntnisse so verfahren, als stünde dort quarantine (RFC 9989).

Das BSI setzt in seiner Technischen Richtlinie TR-03182 einen anderen Schwerpunkt: Es erwartet quarantine oder reject und nennt reject als langfristiges Ziel (BSI). Beides lässt sich vereinbaren. Für eine reine Versanddomain, über die ein Shop Bestellbestätigungen und Newsletter verschickt und deren Adressen niemand für Mailinglisten nutzt, ist reject meist gut begründet. Für die Domain, unter der das Team seine persönlichen Postfächer führt, ist quarantine oft die vorsichtigere Wahl. Wer ein Markenlogo per BIMI im Postfach zeigt, prüft nach dem Umbau zusätzlich, ob die Anforderungen des jeweiligen Postfachanbieters an die Richtlinie weiter erfüllt sind.

Den DMARC-Eintrag umbauen: Schritt für Schritt

Der Umbau selbst dauert Minuten, die Vorbereitung nicht. In dieser Reihenfolge bleibt der Eintrag in jeder Phase eindeutig:

1. Ist-Stand sichern: den aktuellen Eintrag unter _dmarc abfragen und mit Datum notieren. Der kostenlose Mail-Server-Check gibt den veröffentlichten DMARC-Eintrag im Wortlaut aus und meldet, wenn unter _dmarc mehr als ein Eintrag steht.
2. Sammelberichte lesen: Die Berichte der letzten Wochen zeigen, welche Quellen noch scheitern und ob legitime Absender unter fehlenden Subdomains auftauchen.
3. pct entscheiden: Steht pct unter 100, entweder voll durchsetzen (pct entfernen) oder bewusst in den Testbetrieb gehen (t=y, für ältere Prüfer zusätzlich pct=0).
4. Reste entfernen: rf, ri und Größenangaben wie !10m hinter den Berichtsadressen streichen.
5. np ergänzen: für nicht existierende Subdomains in der Regel np=reject, sofern die Berichte nichts dagegen sprechen lassen. Im Testbetrieb mit t=y wirkt es eine Stufe milder.
6. Ersetzen statt ergänzen: den alten TXT-Eintrag im selben Schritt ändern, keinen zweiten anlegen.
7. Nachmessen: nach Ablauf der TTL den Eintrag erneut abfragen und in den nächsten Sammelberichten prüfen, ob die neue Richtlinie ankommt. Dass danach genau ein Eintrag mit der gewollten Richtlinie steht, zeigt laufend das DNS-Monitoring.

Im Zonen-Eintrag sieht der Umbau für die drei Fälle so aus. Die Adresse example.com steht für die eigene Domain:

; vorher, nach RFC 7489
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=50; rf=afrf; ri=86400; rua=mailto:dmarc@example.com!10m"

; Weg A: Richtlinie voll anwenden
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc@example.com"

; Weg B: Testbetrieb, auch für ältere Prüfer eindeutig
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; np=reject; t=y; pct=0; rua=mailto:dmarc@example.com"

Nach dem Speichern zeigt eine einfache Abfrage, was die Welt tatsächlich sieht. Entscheidend ist die Zahl der Zeilen: Kommen zwei v=DMARC1-Einträge zurück, ist der alte noch da.

Vor der Black Week: den Eintrag im Blick behalten

Gerade vor den umsatzstarken Wochen im November lohnt es sich, den Umbau nicht auf den letzten Tag zu legen. Die großen Postfachanbieter knüpfen ihre Regeln für Massenversender an einen veröffentlichten DMARC-Eintrag: Google verlangt ihn von Absendern, die mehr als 5.000 Nachrichten pro Tag an Gmail-Konten schicken (Google), Microsoft für Outlook von Domains, die mehr als 5.000 Mails pro Tag versenden (Microsoft), und Yahoo von Massenversendern mit mindestens p=none (Yahoo). Eine strenge Richtlinie verlangt keiner der drei; auch Google lässt none zu (Google).

Das Risiko liegt deshalb weniger in der Richtlinie als im Umbau selbst. Wer beim Ändern einen zweiten Eintrag anlegt, sich bei v=DMARC1 vertippt oder den Eintrag versehentlich an den falschen Namen schreibt, steht für diese Empfänger ohne gültigen DMARC-Eintrag da, unter Umständen mitten in einer Kampagne. Welche weiteren Regeln für den Massenversand gelten, fasst der Beitrag zu den Zustellregeln für den Massenversand zusammen.

Im DNS- und Domain-Monitoring prüft XICTRAQ® SPF, DKIM und DMARC bei jeder DNS-Prüfung. Für DMARC zeigt die Website-Ansicht, ob genau ein Eintrag veröffentlicht ist und welche Richtlinie er setzt; stehen unter _dmarc mehrere Einträge, erscheint das als Warnung. Änderungen an den TXT-Einträgen der Domain selbst, etwa am SPF-Eintrag, hält der Changelog mit altem und neuem Wert fest. Fehlt die E-Mail-Authentifizierung ganz, löst das einen Alarm über die eingestellten Benachrichtigungskanäle aus.

Die neuen Tags np, psd und t wertet die Prüfung bislang nicht eigens aus. Wer seinen Eintrag nach RFC 9989 umgestellt hat, liest sie im Wortlaut ab, den der Mail-Server-Check unverändert ausgibt. Ob ein Alarm nachts auch wirklich ankommt, beantwortet eine Alarmierungsübung besser als jede Annahme. Und für die eigene Dokumentation hilft ein einfacher Grundsatz: Jede Änderung am DMARC-Eintrag bekommt ein Datum, den alten und den neuen Wortlaut und einen Satz zur Begründung.

Den DMARC-Eintrag einmal sauber auf RFC 9989 bringen

Der Umbau ist überschaubar: pct, rf, ri und Größenangaben raus, np hinein, t=y nur für einen befristeten Testbetrieb, und psd bleibt in der Regel weg. Wichtiger als jedes einzelne Tag ist, dass der Eintrag danach bei alten und neuen Prüfern dasselbe bedeutet und nur einmal im DNS steht. Wie bei der HSTS-Preload-Liste gilt auch hier: Ein Eintrag, der das Verhalten fremder Server steuert, wird erst geprüft und dann festgeschrieben.

Wer DMARC erst einrichtet, beginnt mit den Grundlagen aus der Anleitung zu SPF, DKIM und DMARC und setzt den Eintrag gleich nach RFC 9989 auf, also ohne pct. Wer bereits umgestellt hat, nutzt die Wochen vor dem Weihnachtsgeschäft, um die Sammelberichte zu lesen und den Eintrag danach ruhig laufen zu lassen. Wie die Prüfung im Alltag aussieht, zeigt die Live-Demo.