Die DMARC-RFCs 9989, 9990 und 9991 ersetzen den RFC 7489
von
Zuletzt aktualisiert: 7 Lesezeit: 7 Minuten
Nach jahrelanger Arbeit in der IETF -DMARC-Arbeitsgruppe wurde nun die lang erwartete Aktualisierung des DMARC-Standards veröffentlicht. Drei neue Dokumente – RFC 9989, RFC 9990 und RFC 9991 – ersetzen nun offiziell den ursprünglichen RFC 7489 aus dem Jahr 2015. Obwohl es sich dabei nicht um einen offiziellen Begriff handelt, waren die RFCs in der Community gemeinsam als „DMARCbis“ bekannt und werden nun als aktualisierte DMARC-Spezifikation mit derselben Versionsnummer veröffentlicht.
Die neuen Spezifikationen wurden im Mai 2026 veröffentlicht und haben DMARC von seinem früheren Status als „Informational“ zu einem „Proposed Standard“ im IETF-Standards-Track erhoben. Dies ist ein bedeutender Schritt, da DMARC dadurch eine stärkere und formellere Stellung im Internet-Standard-Stack erhält.
Was die einzelnen RFCs behandeln
Die DMARC-Spezifikation wurde in drei separate Dokumente aufgeteilt, anstatt in einer einzigen umfangreichen Datei zusammengefasst zu werden. RFC 9989 enthält das Kernprotokoll, einschließlich der Richtlinienauswertung, der Abgleichregeln und der Datensatzverarbeitung. RFC 9990 definiert das Format für aggregierte Berichte (RUA). RFC 9991 befasst sich mit Fehlerberichten, die oft als forensische Berichte bezeichnet werden.
Ihr bestehender DMARC-Eintrag funktioniert weiterhin
Einer der wichtigsten Punkte für Domain-Inhaber ist, dass es sich hierbei nicht um eine grundlegende Änderung handelt. Die Protokollkennung bleibt unverändert, sodass die Einträge weiterhin mit „v=DMARC1“ beginnen. Sie müssen Ihre Konfiguration nicht neu einrichten oder alle Ihre Einträge über Nacht neu veröffentlichen.
Wenn Sie Ihre Kenntnisse über den Aufbau von Datensätzen auffrischen möchten, finden Sie in unserem Leitfaden zu DMARC-Tags eine detaillierte Beschreibung der einzelnen Felder.
Wichtige technische Änderungen
Einige Änderungen fallen besonders ins Auge, und bei einigen davon lohnt es sich, sich genauer zu informieren, bevor Sie Ihre Daten bearbeiten.
Liste der öffentlichen Suffixe durch DNS-Tree-Walk ersetzt
Empfänger stützen sich nicht mehr auf die extern gepflegte „Public Suffix List“, um die Organisationsdomain zu ermitteln. Stattdessen durchlaufen sie die DNS-Hierarchie und suchen auf jeder Ebene nach _dmarc-Einträgen. In der Praxis beginnt ein Empfänger bei der betreffenden Domain und fragt schrittweise übergeordnete Labels ab – bis zu maximal acht Abfragen –, bis er einen veröffentlichten DMARC-Eintrag findet. Dadurch entfällt die Abhängigkeit von Drittanbietern und die Genauigkeit bei komplexen Domainstrukturen wird verbessert.
Es gibt eine praktische Auswirkung, die es zu beachten gilt. Da der „Tree Walk“ die Organisationsdomäne anders auflöst als die alte Methode der „Public Suffix List“, kann ein Empfänger, der RFC 9989 verwendet, in einigen Fällen zu einer anderen Organisationsdomäne gelangen als ein Empfänger, der noch nach RFC 7489 arbeitet. Wenn Sie eine komplexe Subdomain-Hierarchie betreiben oder delegierte Domains verwenden, ist es am sichersten, einen expliziten DMARC-Eintrag für jede Domain und Subdomain zu veröffentlichen, von der aus Sie tatsächlich E-Mails versenden. Dadurch werden jegliche Unklarheiten darüber beseitigt, welche Richtlinie gilt – unabhängig davon, welche Version ein bestimmter Empfänger verwendet.
Neue Tags: np, psd und t
RFC 9989 führt drei neue Tags ein. Im Folgenden wird erläutert, welche Funktion die einzelnen Tags haben und wann man sie tatsächlich verwenden würde.
np (Richtlinie für nicht vorhandene Subdomains)
Mit dem „sp“-Tag können Sie bereits eine Richtlinie für Subdomains festlegen, doch „np“ geht noch einen Schritt weiter, indem es die Richtlinie für Subdomains, die überhaupt nicht existieren – d. h., für die das DNS „NXDOMAIN“ zurückgibt –, gesondert behandelt. Damit wird eine echte Sicherheitslücke beim Subdomain-Spoofing geschlossen, da Angreifer häufig E-Mails von Subdomains fälschen, die nie registriert wurden. Beispielsweise würde ein Eintrag „v=DMARC1; p=none; np=reject;“ keine Richtlinie auf die Root-Domain und ihre echten Subdomains anwenden, aber dennoch E-Mails von nicht existierenden Subdomains zurückweisen. Wenn Ihre Domain bereits auf „p=reject“ oder „sp=reject“ eingestellt ist, wird die strenge Richtlinie automatisch übernommen, sodass „np=reject“ keinen zusätzlichen Nutzen bringt und keine Änderung erforderlich ist. Wenn Sie eine weniger strenge Richtlinie verwenden, aber gezielten Schutz vor diesem spezifischen Angriff wünschen, lohnt es sich auf jeden Fall, „np=reject“ hinzuzufügen.
t (Testmodus)
Dies ist das Tag, das am ehesten falsch interpretiert wird. Die Einstellung „t=y“ deaktiviert Ihre Richtlinie nicht. Stattdessen werden Empfänger aufgefordert, die nächstweniger strenge Richtlinie als die von Ihnen veröffentlichte anzuwenden: Eine Ablehnungsrichtlinie wird als Quarantäne behandelt, eine Quarantänerichtlinie als „none“ und „none“ bleibt unverändert. Dies ist weitaus präziser als das alte „pct“-Verhalten, das es faktisch ersetzt. Ein wichtiger Hinweis: Noch unterstützt nicht jeder Empfänger RFC 9989, sodass einige „t=y“ einfach ignorieren werden. Während der Übergangsphase ist es sicherer, sowohl „pct“ als auch „t“ gemeinsam zu verwenden, damit sowohl ältere als auch neuere Empfänger Ihre Absicht verstehen. Ein „staged record“ könnte beispielsweise so aussehen: v=DMARC1; p=reject; pct=50; t=y;. Weitere Informationen zu dieser Umstellung finden Sie in unserem früheren Beitrag darüber, warum „t“ „pct“ ersetzt.
psd (Domäne mit öffentlichem Suffix)
Dieses Tag hilft Empfängern dabei, die Organisationsdomäne während des DNS-Tree-Walk zu ermitteln. Die meisten gewöhnlichen Domaininhaber sollten es einfach weglassen. Es ist nur in zwei Situationen relevant: bei einer Organisation, die eine bewusste Grenze der Organisationsdomäne auf einer Subdomain festlegen möchte (dort psd=n setzen), oder bei einem Betreiber einer Public-Suffix-Domain wie .bank oder .gov (psd=y setzen). Beachten Sie, dass Empfänger, die noch nach RFC 7489 arbeiten, dieses Tag vollständig ignorieren; es ist daher kein Ersatz für eine solide Datensatzgestaltung.
Drei Tags wurden entfernt: pct, rf und ri
Mit RFC 9989 werden drei Tags abgeschafft. Keine dieser Abschaffungen führt zu Fehlern in bestehenden Datensätzen, dennoch ist es sinnvoll zu verstehen, welche Funktion die einzelnen Tags hatten und wie man damit umgehen sollte. Siehe den entsprechenden Abschnitt weiter unten.
Klarere Richtlinien für Mailinglisten und Weiterleitungen
Indirekte E-Mail-Ströme führen nach wie vor zu einer Nichtübereinstimmung von SPF und DKIM, was in der neuen Spezifikation offen eingeräumt wird. Sie rät von aggressiven „p=reject“-Richtlinien ab, wenn der Verkehr über Mailinglisten üblich ist, was dem tatsächlichen Verhalten von E-Mails in der Praxis entspricht.
Besser definierte Konformität
Der neue Text legt genau fest, was „vollständige DMARC-Teilnahme“ sowohl für Absender als auch für Empfänger bedeutet, was die uneinheitlichen Implementierungen verringern dürfte, die seit Jahren ein Problem darstellen.
Beschränkung der URI-Länge bei der Meldung aufgehoben
Eine kleinere Änderung, die leicht übersehen werden kann: Mit RFC 9989 wurde die Möglichkeit gestrichen, in der Berichts-URI eine maximale Berichtsgröße anzugeben. Datensätze, die ein Größensuffix wie beispielsweise rua=mailto:[email protected]!10m verwendeten, sind nun nicht mehr aussagekräftig, und Empfänger sollten nun jegliche Größenbeschränkung, die an eine RUA- oder RUF-Adresse angehängt ist, ignorieren. Falls Ihre Berichts-URIs diese Syntax enthalten, können Sie den Teil mit der Größenbeschränkung bedenkenlos entfernen.
Die entfernten Tags verstehen
Falls Ihr aktueller Datensatz die Bezeichnungen „pct“, „rf“ oder „ri“ enthält, erfahren Sie hier genau, welche Funktion die einzelnen Bezeichnungen hatten und wie Sie nun vorgehen sollten.
pct (Prozentsatz)
Dieses Tag wurde entwickelt, um Ihnen die schrittweise Einführung einer Richtlinie zu ermöglichen, indem Sie diese auf einen ausgewählten Prozentsatz der E-Mails anwenden. In der Praxis wurde es jedoch nicht einheitlich bei allen Empfängern implementiert, was zu unvorhersehbaren Ergebnissen führte, und es wurde durch das übersichtlichere „t“-Tag ersetzt. Falls Sie sich noch auf „pct“ verlassen, sollten Sie sich künftig nicht mehr ausschließlich darauf stützen. Während der Übergangsphase ist es sinnvoll, „pct“ und „t=y“ gemeinsam auszuführen, damit sowohl ältere Empfänger als auch RFC-9989-konforme Empfänger erkennen, dass Sie schrittweise auf die Durchsetzung der Richtlinie hinarbeiten.
rf (Berichtsformat)
Dieses Tag legte das Format für Fehlerberichte fest, doch der einzige gültige Wert war „afrf“, wodurch das Tag in der Praxis überflüssig wurde. Es kann bedenkenlos aus allen Datensätzen entfernt werden, in denen es vorkommt.
ri (Berichtsintervall)
Dieses Tag legte das gewünschte Intervall zwischen den Sammelberichten in Sekunden fest. Die meisten Empfänger ignorierten es und griffen einfach auf den Standardwert eines täglichen Berichts zurück. RFC 9989 formalisiert dies nun, indem es von den Empfängern verlangt, mindestens einmal täglich Sammelberichte zu senden. Es schadet nicht, das Tag beizubehalten, doch es verliert zunehmend an Bedeutung und man sollte sich nicht darauf verlassen.
Wie aktualisiert man den DMARC-Eintrag gemäß RFC 9989?
Die Veröffentlichung von RFC 9989 hat keine Auswirkungen auf Ihre bestehenden Einstellungen. Ihr Eintrag befindet sich weiterhin an derselben Stelle – als DNS-TXT-Eintrag unter _dmarc.yourdomain.com – und die Versionsangabe lautet nach wie vor v=DMARC1.
Warum also überhaupt ein Update durchführen? Weil RFC 9989 widerspiegelt, wie E-Mail nach einem Jahrzehnt des praktischen Einsatzes tatsächlich funktioniert, und es sich lohnt, einige der darin enthaltenen Änderungen schon jetzt in Ihre Datenbank zu übernehmen, anstatt sie erst später zu entdecken.
Das sollten Domaininhaber tun
Domaininhaber können anhand der folgenden Checkliste ihre Einträge dynamisch aktualisieren:
- Entfernen Sie die Tags „rf“ und „ri“. Beide sind veraltet und können bedenkenlos gelöscht werden.
- Replace pct with t: use t=y for testing (in place of any pct<100), or drop the tag for full enforcement (t=n is the default)
- Erwägen Sie die Hinzufügung von „np=reject“, wenn Sie Spoofing von nicht existierenden Subdomains blockieren möchten, ohne Ihre Hauptrichtlinie zu ändern.
- Entfernen Sie das Suffix zur Begrenzung der URI-Größe, falls Ihre RUA- oder RUF-Einträge ein solches enthalten.
- Lassen Sie „psd“ weg, es sei denn, Sie müssen bewusst eine Organisationsdomänengrenze festlegen oder betreiben eine Domäne mit öffentlichem Suffix.
- Veröffentlichen Sie explizite DMARC-Einträge für jede Domain und Subdomain, von der aus Sie E-Mails versenden, um jegliche Unklarheiten beim DNS-Tree-Walk zwischen Empfängern gemäß RFC 9989 und RFC 7489 zu vermeiden.
Eine ausführlichere Anleitung zu den Änderungen und zur Vorbereitung Ihrer Einträge finden Sie in unserem vollständigen Leitfaden zu DMARCbis.
Ein modernisierter Datensatz gemäß RFC 9989 sieht wie folgt aus:
v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s
Beachten Sie, was fehlt: kein „pct“. Um die Umstellung sicher durchzuführen, fügen Sie „t=y“ hinzu, lassen Sie die aggregierten Berichte zunächst anfallen und entfernen Sie es dann, wenn Sie bereit für die vollständige Umsetzung sind.
Außerdem werden Sie feststellen, dass in diesem Datensatz zwei gültige RFC-9989-Tags fehlen – „t“ und „psd“ – und das ist beabsichtigt, da beide eher situationsabhängig als standardisiert sind.
Das „t“-Tag steht für den temporären Testmodus: Sie fügen es nur während der Einführungsphase hinzu, da es die Empfänger anweist, die nächstniedrigere Richtlinie als die von Ihnen veröffentlichte anzuwenden. Das „psd“-Tag hingegen ist ein Flag, das eine Domain als öffentliches Suffix deklariert. Betreiber öffentlicher Suffixe müssen „psd=y“ festlegen, aber für einen gewöhnlichen Domaininhaber ist die Standardeinstellung (u) genau richtig, und Sie sollten das Tag einfach weglassen.
Stellen Sie sicher, dass Ihre DMARC-Plattform bereit ist
Nicht jedes auf dem Markt erhältliche Tool hat die neuen Standards bereits umgesetzt, und diese Lücke ist von Bedeutung. Wenn Ihre Plattform die neuen Tags nicht lesen oder Berichte im aktualisierten Format nicht verarbeiten kann, verlieren Sie genau dann an Transparenz, wenn sich das Protokoll weiterentwickelt.
PowerDMARC entspricht bereits den neuen Spezifikationen und unterstützt:
- Erstellung von Datensätzen gemäß RFC 9989, 9990 und 9991
- Analyse der neuen Tags „np“, „psd“ und „t“
- RFC 9990: Erfassung und Berichterstellung von aggregierten Daten
- Verwaltung von Organisationsdomänen auf Basis eines DNS-Baumdurchlaufs
- Aktualisiertes Verarbeitungsverhalten, das die neuen Konformitätsregeln widerspiegelt
Wenn Sie sehen möchten, wie Ihr aktueller Eintrag im Vergleich zum neuen Standard abschneidet, lassen Sie ihn durch unseren kostenlosen DMARC-Checker laufen und prüfen Sie, was bereinigt werden muss.
Abschließende Worte
Die aktualisierten RFCs stellen kein neues Protokoll dar. Es handelt sich um dasselbe DMARC, das klarer formuliert und in den Status eines Standardentwurfs erhoben wurde. Nach mehr als einem Jahrzehnt praktischer Anwendung spiegelt die Spezifikation nun wider, wie E-Mail tatsächlich funktioniert, einschließlich ihrer komplexeren Aspekte wie Weiterleitung und Mailinglisten.
Für alle, die für die Domainsicherheit verantwortlich sind, ist die Veröffentlichung der RFCs 9989, 9990 und 9991 ein guter Anlass, Ihre Einträge zu überprüfen und sicherzustellen, dass Ihre Tools für die neuen Tags und den DNS-Tree-Walk-Ansatz bereit sind.
Experte für Domain- und E-Mail-Sicherheit bei PowerDMARC
Ahona ist Marketing-Managerin bei PowerDMARC und verfügt über mehr als 5 Jahre Erfahrung im Schreiben über Cybersicherheitsthemen, insbesondere im Bereich Domain- und E-Mail-Sicherheit. Ahona hat einen Postgraduierten-Abschluss in Journalismus und Kommunikation und ist seit 2019 in der Sicherheitsbranche tätig.
Neueste Beiträge von Ahona Rudra (alle anzeigen)
