Nach jahrelanger Arbeit innerhalb der IETF DMARC-Arbeitsgruppe wurde die lang erwartete Aktualisierung des DMARC-Standards veröffentlicht. Drei neue Dokumente, RFC 9989, RFC 9990 und RFC 9991, ersetzen nun offiziell das ursprüngliche RFC 7489 von 2015. Zusammen werden sie allgemein als DMARCbis bezeichnet.

Die neuen Spezifikationen wurden im Mai 2026 veröffentlicht und beförderten DMARC von seinem früheren Informational-Status zu einem Proposed Standard auf dem IETF Standards Track. Dies verleiht DMARC eine stärkere und formellere Stellung im Internet-Standards-Stack.

I. Was jedes RFC abdeckt

Die DMARC-Spezifikation wurde in drei fokussierte Dokumente aufgeteilt statt in eine große Datei:

• RFC 9989: Definiert das DMARC-Kernprotokoll, einschließlich Policy-Evaluierung, Identifier Alignment, Record-Verarbeitung und DNS Tree Walk-Verfahren.
• RFC 9990: Definiert das DMARC-Aggregat-Reporting, auch bekannt als RUA-Reporting.
• RFC 9991: Definiert das DMARC-Fehler-Reporting, manchmal auch Forensic Reporting genannt, das nachrichtenspezifische Details über Authentifizierungsfehler liefern kann, wenn es von empfangenden Systemen unterstützt wird.

Diese Aufteilung macht den Standard einfacher zu implementieren, zu warten und zu referenzieren.

II. Ihr bestehender DMARC-Eintrag funktioniert weiterhin

Dies ist keine bahnbrechende Änderung für Domain-Inhaber.

DMARC-Einträge beginnen weiterhin mit:

v=DMARC1

Sie müssen Ihre DMARC-Implementierung nicht neu aufbauen oder alle Einträge sofort neu veröffentlichen. Bestehende Einträge bleiben gültig, aber die Aktualisierung ist ein guter Grund, Ihre Konfiguration zu überprüfen, veraltetes Verhalten zu entfernen und zu bestätigen, dass Ihre Monitoring-Plattform die neuen Spezifikationen unterstützt.

III. Wichtige technische Änderungen

Mehrere Änderungen sind für Sicherheitsteams, DNS-Administratoren und E-Mail-Authentifizierungsplattformen relevant.

DNS Tree Walk ersetzt die Abhängigkeit von der Public Suffix List

DMARCbis ersetzt die Abhängigkeit von der extern gepflegten Public Suffix List zur Ermittlung der organisatorischen Domain durch DNS Tree Walk-Verfahren.

Empfänger können nun die DNS-Hierarchie hinaufgehen und auf jeder Ebene nach relevanten _dmarc-Einträgen suchen. Dies reduziert die Abhängigkeit von einer Drittanbieterliste und verbessert die Handhabung komplexer Domain-Strukturen, delegierter Domains und Public-Suffix-Domain-Betreiber.

Neue Tags: np, psd und t

RFC 9989 aktualisiert die DMARC-Tag-Registry und führt aktive Unterstützung ein für:

• np: Policy für nicht existierende Subdomains.
• psd: Handhabung von Public-Suffix-Domains.
• t: Test-Flag, mit t=y für Test und t=n für normalen Betrieb.

Das np-Tag ist besonders wichtig für Organisationen mit großen oder komplexen Domain-Portfolios, da es hilft, Spoofing-Versuche gegen nicht existierende Subdomains zu adressieren.

Historische Tags: pct, rf und ri

RFC 9989 markiert mehrere ältere Tags als historisch:

• pct
• rf
• ri

Das pct-Tag war ursprünglich für die Unterstützung eines schrittweisen Policy-Rollouts gedacht, aber die Implementierung war bei den Empfängern inkonsistent. DMARCbis ersetzt diesen Ansatz durch klareres Testverhalten über das t-Tag.

Organisationen sollten bestehende DMARC-Einträge auf historische Tags überprüfen und gegebenenfalls eine Bereinigung planen.

Klarere Leitlinien für Weiterleitung und Mailinglisten

Indirekte E-Mail-Flüsse wie Weiterleitung und Mailinglisten bleiben für DMARC schwierig, da SPF- oder DKIM-Alignment fehlschlagen kann, selbst wenn die Nachricht legitim ist.

DMARCbis gibt explizitere Leitlinien für diese realen Szenarien. Dies ist wichtig, weil viele Produktionsfehler nicht durch bösartige E-Mails verursacht werden, sondern durch legitime E-Mails, die durch Systeme laufen, die Routing, Header oder Authentifizierungskontext verändern.

Besser definierte Konformität

Die aktualisierten Spezifikationen bieten klarere Definitionen für DMARC-Beteiligung und Implementierungsverhalten.

Dies sollte helfen, inkonsistente Interpretationen bei Sendern, Empfängern und Anbietern zu reduzieren. Für Organisationen wird es auch einfacher zu fragen, ob ein Tool oder Anbieter tatsächlich mit dem aktuellen DMARC-Standard übereinstimmt.

IV. RFC 9989: DMARC-Kernprotokoll

RFC 9989 ersetzt RFC 7489 als primäre DMARC-Spezifikation.

Es definiert das Kernprotokoll, einschließlich:

• DMARC-Policy-Discovery.
• Record-Verarbeitung.
• Identifier Alignment.
• Policy-Evaluierung.
• DNS Tree Walk-Verhalten.
• Aktualisierte Tag-Handhabung.
• Konformitätserwartungen.

Policy Discovery und Vererbung

RFC 9989 klärt, wie DMARC-Policy-Discovery über Domain-Hierarchien hinweg funktioniert.

Dies ist wichtig für Organisationen mit vielen Subdomains, delegierten Domains oder regionalen Domains. Ohne klare Policy Discovery können Teams glauben, dass eine Domain geschützt ist, während ein Empfänger die erwartete Policy nicht entdeckt oder anwendet.

Identifier Alignment

DMARC hängt weiterhin von Identifier Alignment ab.

Eine Nachricht besteht DMARC nur, wenn mindestens eine der folgenden Bedingungen wahr ist:

• SPF ist erfolgreich und die SPF-authentifizierte Domain stimmt mit der sichtbaren From-Domain überein.
• DKIM ist erfolgreich und die DKIM-Signatur-Domain stimmt mit der sichtbaren From-Domain überein.

SPF-Erfolg allein bedeutet nicht, dass DMARC besteht. DKIM-Erfolg allein bedeutet nicht, dass DMARC besteht. Alignment ist das, was die Authentifizierung mit der Domain verknüpft, die der Empfänger sieht.

DNS Tree Walk

DNS Tree Walk ist eine der wichtigsten operativen Änderungen in RFC 9989.

Anstatt sich auf die Public Suffix List zur Bestimmung der organisatorischen Domain zu verlassen, verwenden Empfänger DNS-Lookups durch die Domain-Hierarchie, um die anzuwendende DMARC-Policy zu ermitteln.

Dies verbessert die Fähigkeit des Standards, komplexe Delegationsmodelle und Public-Suffix-Domain-Szenarien zu handhaben.

V. RFC 9990: Aggregat-Reporting

RFC 9990 definiert das DMARC-Aggregat-Reporting-Format.

Aggregat-Reports geben Domain-Inhabern Einblick, wie ihre Domain im E-Mail-Ökosystem verwendet wird. Diese Reports enthalten typischerweise:

• Quell-IP-Adressen.
• Authentifizierungsergebnisse.
• Alignment-Ergebnisse.
• Policy-Disposition.
• Sendevolumen.
• Berichtende Organisation.

Das dedizierte Aggregat-Reporting-RFC sollte die Konsistenz über Implementierungen hinweg verbessern und das Reporting-Verhalten für Anbieter und Domain-Inhaber leichter interpretierbar machen.

Für Sicherheitsteams bleiben Aggregat-Reports eine der nützlichsten Möglichkeiten, legitime Absender zu entdecken, nicht autorisierte Quellen zu identifizieren und den DMARC-Durchsetzungsfortschritt zu überwachen.

VI. RFC 9991: Fehler-Reporting

RFC 9991 definiert DMARC-Fehler-Reporting als dedizierte Standards-Track-Spezifikation.

Fehler-Reports können nachrichtenspezifische Details über Authentifizierungsfehler liefern, abhängig von der Empfängerimplementierung und den Datenschutzkontrollen.

Diese Reports können für Fehlersuche und Bedrohungsuntersuchungen nützlich sein, müssen aber sorgfältig behandelt werden. Fehler-Reports können sensible Metadaten enthalten und, je nach Implementierung, Nachrichten-Header oder Inhaltselemente einschließen. Organisationen sollten Datenschutz, Volumen, Aufbewahrung und Zugriffskontrollen berücksichtigen, bevor sie Fehler-Reporting aktivieren oder sich darauf verlassen.

Nicht alle Empfänger senden Fehler-Reports. Sicherheitsteams sollten sie als ergänzendes Signal betrachten, nicht als vollständige Überwachungsquelle.

VII. Was Domain-Inhaber tun sollten

Domain-Inhaber müssen nicht in Panik DNS-Einträge bearbeiten, sollten aber ihre DMARC-Position gegen die aktualisierten Spezifikationen überprüfen.

Eine praktische Überprüfung sollte Folgendes umfassen:

• Bestätigen, dass alle DMARC-Einträge weiterhin v=DMARC1 verwenden.
• Historische Tags wie pct, rf und ri identifizieren und Bereinigung planen.
• Überprüfen, ob das np-Tag für den Schutz nicht existierender Subdomains relevant ist.
• Bestätigen, wie Subdomains geschützt sind.
• Prüfen, ob Drittanbieter-Absender ordnungsgemäß ausgerichtet sind.
• Aggregat-Report-Sichtbarkeit überprüfen.
• Bestätigen, dass Ihre DMARC-Plattform RFC 9989, RFC 9990 und RFC 9991 unterstützt.
• Anbieter fragen, wie sie DNS Tree Walk Policy Discovery handhaben.
• Überprüfen, ob Fehler-Reporting für Ihre Organisation nützlich, angemessen und datenschutzsicher ist.

Das Ziel ist nicht dringende Migration. Das Ziel ist kontrollierte Ausrichtung auf den aktuellen DMARC-Standard.

VIII. Was DMARC-Plattformen unterstützen müssen

DMARCbis-Bereitschaft ist nicht nur ein Thema für Domain-Inhaber. Plattformen, die DMARC verwalten oder überwachen, müssen sich ebenfalls anpassen.

Eine DMARCbis-bereite Plattform sollte Folgendes unterstützen:

• RFC 9989 Kernprotokoll-Verhalten.
• DNS Tree Walk-basierte Policy Discovery.
• Parsen und Interpretation von np, psd und t.
• Erkennung historischer Tags wie pct, rf und ri.
• RFC 9990 Aggregat-Report-Aufnahme und -Analyse.
• RFC 9991 Fehler-Report-Handhabung, wo aktiviert.
• Klare Unterscheidung zwischen Authentifizierung und Alignment.
• Sichtbarkeit über Subdomains und delegierte Domains hinweg.
• Aktualisiertes Konformitätsverhalten, während sich Empfängerimplementierungen weiterentwickeln.

Wenn eine Plattform die aktualisierten Tags oder das Reporting-Verhalten nicht interpretieren kann, können Sicherheitsteams die Sichtbarkeit wichtiger Authentifizierungsänderungen verlieren.

IX. Wie Skysnag Protect hilft

Skysnag Protect hilft Organisationen, sich auf DMARCbis vorzubereiten, indem es aktualisierte Record-Analyse, Reporting-Sichtbarkeit und Policy-Überwachung unterstützt, während sich Empfängerimplementierungen weiterentwickeln.

Die Plattform ist darauf ausgelegt, Organisationen zu helfen:

• DMARC-Durchsetzungsposition zu überwachen.
• SPF- und DKIM-Alignment zu verfolgen.
• Legitime und nicht autorisierte Sendequellen zu identifizieren.
• Sichtbarkeit über Domains und Subdomains hinweg aufrechtzuerhalten.
• Aggregat-Report-Verhalten zu interpretieren.
• Aktualisierte DMARC-Tag-Handhabung zu unterstützen.
• Sich auf DNS Tree Walk-basierte Policy Discovery vorzubereiten.
• Manuelle Komplexität im laufenden DMARC-Management zu reduzieren.

Während die Branche RFC 9989, RFC 9990 und RFC 9991 übernimmt, benötigen Organisationen Tools, die mit dem Standard Schritt halten, ohne unnötige operative Störungen zu erzwingen.

X. Migrations- und Konformitätsüberlegungen

DMARCbis ist kein neues Protokoll. Es ist eine klarere Standards-Track-Version von DMARC, die auf mehr als einem Jahrzehnt operativer Erfahrung basiert.

Organisationen sollten die Aktualisierung als strukturierten Überprüfungspunkt behandeln:

Einträge überprüfen

Prüfen Sie auf historische Tags, inkonsistente Subdomain-Policies, fehlende Reporting-Adressen und veraltete Annahmen über Policy-Rollouts.

Absender überprüfen

Bestätigen Sie, dass jeder legitime Absender ausgerichtetes SPF oder ausgerichtetes DKIM bestehen kann. Dies ist besonders wichtig für Marketing-Plattformen, CRMs, Ticketing-Systeme, Helpdesk-Tools und andere Drittanbieter-Dienste.

Reporting überprüfen

Stellen Sie sicher, dass Aggregat-Reporting korrekt verarbeitet wird und dass jedes Fehler-Reporting mit angemessenen Datenschutz- und Zugriffskontrollen behandelt wird.

Anbieter überprüfen

Fragen Sie E-Mail-Sicherheitsanbieter, ob sie RFC 9989, RFC 9990 und RFC 9991 unterstützen, einschließlich DNS Tree Walk Policy Discovery und aktualisierter Tag-Interpretation.

XI. Abschließende Worte

DMARCbis ist dasselbe DMARC, aber klarer, formeller und besser darauf abgestimmt, wie E-Mail tatsächlich funktioniert.

Die Veröffentlichung von RFC 9989, RFC 9990 und RFC 9991 ist ein guter Anlass für Domain-Inhaber, ihre Einträge zu überprüfen, Absender-Alignment zu validieren, Subdomain-Abdeckung zu prüfen und zu bestätigen, dass ihre Tools für den aktuellen Standard bereit sind.

Für Organisationen, die für Markenschutz, Phishing-Prävention und E-Mail-Vertrauen verantwortlich sind, ist die Änderung nicht störend. Es ist eine Gelegenheit, die Implementierungsqualität zu verbessern.

XII. Wichtige Erkenntnisse

• RFC 9989 ersetzt RFC 7489 als zentrale DMARC-Protokollspezifikation.
• RFC 9990 definiert DMARC-Aggregat-Reporting.
• RFC 9991 definiert DMARC-Fehler-Reporting.
• Bestehende DMARC-Einträge verwenden weiterhin v=DMARC1.
• DNS Tree Walk ersetzt die Abhängigkeit von der Public Suffix List für die Policy-Erkennung.
• RFC 9989 führt aktive Unterstützung für np, psd und t ein.
• pct, rf und ri sind nun historische Tags.
• DMARCbis verbessert die Klarheit und Implementierungskonsistenz, anstatt den grundlegenden Zweck von DMARC zu ändern.
• Organisationen sollten Einträge, Subdomains, Absender, Reporting und Anbieterbereitschaft überprüfen.

Sind Sie bereit, Ihr E-Mail-Authentifizierungsprogramm an DMARCbis anzupassen? Entdecken Sie Skysnag Protect.