Email & Collaboration Threat Protection

DMARC ist nun ein vorgeschlagener IETF-Standard – ist Ihr Unternehmen darauf vorbereitet?

Hier erfahren Sie, was sich geändert hat, welche Auswirkungen dies auf Compliance- und Versicherungsanforderungen hat und warum „p=none“ kein sicherer Ausweg mehr ist

by Alexander Decarne

Juni 02, 2026

Wichtige Punkte

DMARC wurde im Rahmen des IETF-Standardisierungsprozesses von einem Informationsdokument zu einem vorgeschlagenen Standard (RFC 9989) erhoben. Diesen Anforderungen kommt nun das Gewicht eines offiziellen Konsenses zu.
Bestehende v=DMARC1-Einträge behalten ihre volle Gültigkeit. RFC 9989 führt strukturelle Änderungen ein, die Organisationen in ihrem eigenen Tempo umsetzen können; der Druck hinsichtlich der Einhaltung von Vorschriften und im Versicherungsbereich, die Umsetzung voranzutreiben, nimmt jedoch zu.
Cyber-Versicherer stellen im Rahmen der Risikoprüfung zunehmend Fragen zur Durchsetzung von DMARC. Eine „p=none“-Haltung, bei der lediglich eine Überwachung stattfindet, wird von einer wachsenden Zahl von Netzbetreibern als schwächeres Signal gewertet als die Durchsetzung von Richtlinien.

Nach elf Jahren als weit verbreitete Community-Konvention ohne offiziellen IETF-Status ist DMARC nun ein Dokument im IETF-Standards-Track. Der im Mai 2026 veröffentlichte RFC 9989 ersetzt den RFC 7489 und ordnet DMARC demselben Standards-Track zu wie grundlegende Protokolle wie SMTP und IMAP. Für die meisten Organisationen mag dies wie eine technische Fußnote wirken. Das ist es nicht.

Warum die Statusänderung von Bedeutung ist

Der ursprüngliche RFC 7489 wurde 2015 über den „Independent Submission Stream“ der IETF veröffentlicht, was bedeutet, dass er kein formelles Gewicht im Rahmen des IETF-Konsenses hatte. Aus diesem Grund wichen die Implementierungen voneinander ab, und Lücken blieben jahrelang unberücksichtigt. RFC 9989 ändert dies: Die Anforderungen von DMARC spiegeln nun den formellen IETF-Konsens wider, der von der Community geprüft und vom IESG genehmigt wurde.

Die praktische Konsequenz: Regulierte Branchen und Beschaffungsrahmen verfügen nun über eine zitierfähige, verlässliche Grundlage, um die Einführung von DMARC verbindlich vorzuschreiben. Ein „IETF Proposed Standard“ ist eine Art von Dokument, das in Sicherheitsrichtlinien von Behörden, Leitlinien für den Finanzsektor und Risikomanagement-Rahmenwerken von Unternehmensanbietern Einzug hält. Die NIS2-Richtlinie und die DORA der EU verpflichten Organisationen bereits zur Umsetzung von Sicherheitsmaßnahmen für E-Mails; RFC 9989 bietet diesen Rahmenwerken eine präzise technische Grundlage.

Zu RFC 9989 gehören zwei ergänzende Standards. RFC 9990 befasst sich mit der aggregierten Berichterstattung und RFC 9991 mit der Fehlerberichterstattung; beide sind nun eigenständige vorgeschlagene Standards. Durch die Trennung der Berichterstattung vom Kernprotokoll werden die Erwartungen an die Umsetzung sowohl für Absender als auch für Empfänger und Anbieter von Tools klarer.

Der Aspekt der Cyberversicherung, den Sie nicht außer Acht lassen sollten

Über die reine Einhaltung technischer Vorgaben hinaus berücksichtigen Cyberversicherer den DMARC-Status bei ihren Risikoprüfungsentscheidungen, und RFC 9989 dürfte diese Prüfung noch verschärfen. Gallaghers „Ausblick auf die Marktbedingungen für Cyberversicherungen 2025“ belegt, dass Versicherer die Sicherheitslage von Unternehmen immer genauer bewerten, wobei die E-Mail-Authentifizierung neben MFA, EDR und Backup-Verfahren ausdrücklich als Faktoren genannt wird, die die Prämiengestaltung und die Verfügbarkeit von Versicherungsschutz beeinflussen.

In den Antragsformularen großer Versicherer wird mittlerweile routinemäßig gefragt, ob Unternehmen SPF, DKIM und DMARC implementiert haben. Hinter dem Kontrollkästchen verbirgt sich jedoch zunehmend die Frage, ob die Richtlinie tatsächlich durchgesetzt wird. Eine „p=none“-Einstellung, bei der der E-Mail-Verkehr zwar überwacht wird, bei fehlerhaften Nachrichten jedoch keine Maßnahmen ergriffen werden, ist für Versicherer ein schwächeres Signal als „p=quarantine“ oder „p=reject“. Unternehmen, die „p=none“ als dauerhafte Sicherheitsstufe anwenden, müssen bei Vertragsverlängerungen möglicherweise mit einer verstärkten Überprüfung, ungünstigeren Vertragsbedingungen oder reduzierten Deckungssummen rechnen.

Fünf Veränderungen, die IT-Teams verstehen müssen

Bestehende Datensätze, die mit „v=DMARC1“ beginnen, behalten ihre volle Gültigkeit; es gibt keine Frist für die Umstellung. Allerdings werden sich mehrere strukturelle Änderungen auf das DNS-Lookup-Verhalten, die Berichterstellung und die Einführungsstrategie auswirken.

1. Drei Tags werden entfernt: pct=, rf= und ri=

Das Tag „pct=“ (prozentbasierte Einführung) wurde entfernt; in der Praxis wurde es nur selten mit der Nuance „nuance“ verwendet. Das Tag „rf=“ (Berichtsformat) wird ebenfalls entfernt – es wurde ohnehin immer nur ein Format verwendet. Zudem wird „ri=“ (das angeforderte Berichtsintervall) entfernt; RFC 9989 empfiehlt, dass Empfänger täglich Berichte senden. Sollten Ihre Datensätze diese Tags noch enthalten, hat dies keine Auswirkungen – unbekannte Tags werden gemäß RFC 9989 §4.7 stillschweigend ignoriert –, sie können jedoch bereinigt werden.

2. Das t=-Tag ersetzt pct= durch ein vorhersehbares, stufenweises Verhalten

Das t=-Tag hat zwei Werte. Signale mit t=y im Testmodus: Bei der Kombination von p=quarantine und t=y werden fehlerhafte Nachrichten wie bei p=none behandelt; bei der Kombination von p=reject und t=y werden sie wie bei p=quarantine behandelt – also eine Stufe weniger streng als die festgelegte Richtlinie. t=n (Standardwert) sorgt für die normale Durchsetzung der Richtlinie. Dadurch wird die Unklarheit beseitigt, die dazu führte, dass „pct=“ in den verschiedenen Implementierungen uneinheitlich war.

3. Neues Tag: „np=“ für nicht vorhandene Subdomains

RFC 9989 führt „np=“ ein, wodurch die DMARC-Richtlinie speziell für nicht existierende Subdomains definiert wird – also solche ohne DNS-Eintrag. Bisher fielen diese unter „sp=“ oder es wurde standardmäßig der „p=“-Wert der Organisationsdomäne verwendet. Angreifer versenden ihre Nachrichten mitunter über Subdomains, die im DNS nicht existieren, und nutzen dabei diese Unklarheit aus. Das „np=“-Tag gewährt Domain-Inhabern explizite Kontrollmöglichkeiten.

4. Der DNS-Tree-Walk ersetzt die Liste der öffentlichen Suffixe

Die Ermittlung von Organisationsdomänen stützte sich bislang auf die Public Suffix List (PSL), eine statische, manuell gepflegte externe Datenbank. RFC 9989 ersetzt dies durch den DNS-Tree-Walk-Algorithmus, der die DNS-Hierarchie dynamisch ausgehend von der Domäne im „From:“-Header durchläuft, bis er den entsprechenden _dmarc-TXT-Eintrag findet – wodurch eine bekannte Ursache für die falsche Zuordnung von Richtlinien in komplexen Domänenstrukturen beseitigt wird.

5. Die PSD-Unterstützung und das „psd=“-Tag gehören nun zum Kern

Die Unterstützung für Domains mit öffentlichem Suffix befand sich zuvor im experimentellen Stadium (RFC 9091). RFC 9989 ersetzt RFC 9091 und integriert die PSD-Verarbeitung in die Kernspezifikation. Das „psd=“-Tag ist nun Standard und nicht mehr experimentell – dies ist insbesondere für Organisationen relevant, die unter Ländercode-Domains der zweiten Ebene wie beispielsweise .co.uk tätig sind.

Was dies für die Branche bedeutet

Für Organisationen, die sich noch auf der Stufe „p=none“ befinden, verschärft RFC 9989 die Anforderungen gleich in zweierlei Hinsicht. Für Prüfungsrahmenwerke und Beschaffungsanforderungen gibt es nun einen formellen, zitierfähigen Standard als Referenz, und branchenspezifische Vorgaben werden sich zunehmend auf RFC 9989 stützen und nicht mehr auf dessen informativen Vorgänger. Gleichzeitig nimmt der Druck seitens der Versicherungsgesellschaften, zu Durchsetzungsmaßnahmen überzugehen, unabhängig von den Faktoren, die die Einhaltung der Vorschriften fördern, zu.

Der Weg zur Durchsetzung bleibt unverändert: Transparenz steht an erster Stelle; jede Absenderquelle muss identifiziert und jeder SPF- sowie DKIM-Fehler behoben werden, bevor die Richtlinien verschärft werden. Eine wichtige technische Änderung ist besonders hervorzuheben: RFC 9989 rät ausdrücklich davon ab, bei indirekten E-Mail-Flüssen – einschließlich Mailinglisten und Weiterleitungen – den Status „p=reject“ zu verwenden; Empfänger werden angewiesen, diese Fälle als „p=quarantine“ zu behandeln, anstatt sie sofort abzulehnen.

Keine der derzeit im Einsatz befindlichen Komponenten weist Störungen auf. Unternehmen, die „p=none“ als dauerhafte Sicherheitsrichtlinie anwenden, sind jedoch in dreierlei Hinsicht gefährdet: durch das bereits bestehende Risiko von Identitätsbetrug, durch einen Standard, der formell so bedeutend ist, dass er in regulatorischen Vorgaben und Risikobewertungen von Anbietern berücksichtigt wird, sowie durch einen Cyberversicherungsmarkt, der zunehmend zwischen überwachter und erzwungener Authentifizierung unterscheidet.

Mit Mimecast immer einen Schritt voraus

Mimecast verfolgt die Umsetzung von RFC 9989 und der dazugehörigen Standards aufmerksam. Für Unternehmen, die den Mimecast DMARC Analyzer nutzen, sollte die Umstellung nahtlos verlaufen. Die Plattform bietet kontinuierliche Transparenz für die Verwaltung des Authentifizierungsstatus in der Domäne, während sich Standards und Anforderungen an deren Durchsetzung weiterentwickeln. Als Teil einer umfassenden Plattform, die weltweit über 42.000 Organisationen bedient, unterstützt Mimecast Sicherheitsteams dabei, den Compliance- und Versicherungsanforderungen, die sich derzeit im Zusammenhang mit der Durchsetzung von DMARC verdichten, stets einen Schritt voraus zu sein.

Möchten Sie erfahren, was RFC 9989 für Ihre DMARC-Implementierung bedeutet und wie wir Ihnen dabei helfen können? Vereinbaren Sie einen Termin für eine Vorführung und sprechen Sie mit einem unserer Experten.

Quellen: