DMARCbis (DMARC V2): was sich wirklich ändert, einfach erklärt

Von Thomas · virtueller CISO · 27. Juni 2026

Im Mai 2026 hat die IETF DMARCbis veröffentlicht – die modernisierte Version des DMARC-Standards, oft „DMARC V2" oder „DMARC 2.0" genannt. Sie ersetzt die ursprüngliche RFC 7489, die aus dem Jahr 2015 stammte. Wo bereits ein DMARC-Eintrag existiert, ist die erste Frage berechtigt: muss alles neu gemacht werden? Die kurze Antwort ist nein – aber es gibt ein paar Neuerungen, die den Blick wirklich lohnen. Dieser Leitfaden erklärt, was DMARCbis ist, warum es existiert, was sich konkret ändert und was schon heute zu tun ist.

DMARCbis in einem Satz

DMARCbis ist eine Überarbeitung von DMARC: dasselbe Ziel (SPF und DKIM mit der sichtbaren Domain des From: verknüpfen, um Usurpation zu stoppen), aber ein neu geschriebener, besser strukturierter Text mit klareren Definitionen, ein paar neuen Tags und einem robusteren Mechanismus zur Domain-Zuordnung. Für Einsteiger ist DMARC von Grund auf erklärt der richtige Anfang; DMARCbis stellt keinen einzigen der dort beschriebenen Grundsätze infrage – es präzisiert sie.

Warum eine neue Version

Die RFC 7489 hatte einen besonderen Status: Informational. Im Klartext war es ein Referenzdokument, keine offizielle IETF-Norm. Zehn Jahre massiver Nutzung später wollte die Arbeitsgruppe diesen Widerspruch beheben. DMARCbis bringt DMARC daher zum ersten Mal auf die Standards-Schiene (Standards Track, im Rang eines Proposed Standard). Nebenbei erlaubte die Praxiserfahrung, das zu entfernen, was schlecht funktionierte, die Grauzonen zu klären und hinzuzufügen, was fehlte.

Die drei RFCs von DMARCbis

DMARCbis ist nicht ein einziges Dokument, sondern drei, was eine früher verwirrende Organisation klärt:

RFC 9989 – der Kern des Protokolls (Richtlinien, Ausrichtung, Tags). Das ist der direkte Nachfolger der 7489.
RFC 9990 – die aggregierten Berichte (RUA), der tägliche Rückkopplungskanal.
RFC 9991 – die Fehlerberichte (RUF), seltener und Datenschutzbeschränkungen unterworfen.

Zusammen machen diese drei RFCs die RFC 7489 obsolet. Wir behandeln ihren Inhalt im Detail in RFC 9989/9990/9991: was sich in DMARC ändert.

Was sich konkret ändert

Drei Änderungen verdienen Aufmerksamkeit. Keine ist ein Bruch, aber jede hat einen praktischen Effekt.

1. Das Tag `pct` verschwindet, ersetzt durch `t`

Das alte Tag pct erlaubte es, die Richtlinie auf einen Prozentsatz der Post anzuwenden (pct=25, dann 50, dann 100) für ein schrittweises Ausrollen. In der Praxis verhielt es sich je nach Empfänger unvorhersehbar. DMARCbis zieht es zurück und führt einen binären Testmodus ein, das Tag t (t=y bedeutet „ich experimentiere, verschärfe noch nicht streng"). Das Hochfahren stützt sich künftig auf die Beobachtung der Berichte statt auf einen Prozentsatz. Wir vertiefen das Thema in einem eigenen Artikel zum Tag t.

2. Zwei neue Subdomain-Tags: `np` und `psd`

Das Tag np legt die Richtlinie der nicht existierenden Subdomains fest – ein klassisches Usurpationsziel, denn ein Angreifer kann rechnung.beispiel.de fälschen, selbst wenn diese Subdomain nicht existiert. Ein np=reject zu setzen verschließt diese Tür ohne jedes Risiko für die legitime Post. Das Tag psd dient den Betreibern von Public-Suffix-Domains (Registries). Für die meisten Organisationen zählt vor allem np: Ein eigener Artikel zum Tag np wird demnächst verfügbar sein.

3. Der DNS Tree Walk ersetzt die Public Suffix List

Um die „organisatorische Domain" zu bestimmen (etwa dass mail.meine-bank.de zu meine-bank.de gehört), stützte sich DMARC auf die Public Suffix List, eine extern von Hand gepflegte Liste. DMARCbis ersetzt sie durch den DNS Tree Walk: eine Folge von DNS-Abfragen Schritt für Schritt (höchstens acht), ohne Abhängigkeit von einer Drittanbieter-Liste. Robuster, vorhersehbarer. Details in einem eigenen Artikel zum DNS Tree Walk.

Was sich nicht ändert (und das ist beruhigend)

Hier der Punkt, der entspannen darf: DMARCbis ist kein Bruch.

Die Einträge beginnen weiterhin mit v=DMARC1. Kein v=DMARC2, kein neues Format zu lernen.
Die Tags p, sp, rua, ruf, adkim, aspf, fo behalten exakt dieselbe Bedeutung.
Das Prinzip der Ausrichtung – der Kern von DMARC – ist unverändert.
Der bestehende Eintrag bleibt gültig: Kein Empfänger wird ihn ablehnen, weil er aus der 7489 „stammt".

Mit anderen Worten, es ist nichts zu ändern, um geschützt zu bleiben. Die Neuerungen sind Verbesserungen, die sich jederzeit übernehmen lassen, keine dringenden Korrekturen.

Besteht Handlungsbedarf?

Eine Domain, die bereits im p=reject mit sauberer Ausrichtung steht, ist auf der sicheren Seite. Drei kleine Handgriffe, einfach und risikofrei, lohnen sich trotzdem:

np=reject hinzufügen, um die Phantom-Subdomains zu verriegeln.
Ein unnütz gewordenes pct entfernen, falls es noch im Eintrag herumhängt.
Prüfen, dass die Berichte weiterhin ankommen (der RUA-Kanal ist nun durch die RFC 9990 geregelt).

Steckt eine Domain noch im p=none, ist die Priorität nicht DMARCbis: Sie ist, die Durchsetzung zu erreichen. Die Methode ist dieselbe wie zuvor – siehe p=reject erreichen, ohne seine E-Mails zu ruinieren. Der vollständige Migrationsfahrplan wird in einem eigenen Artikel detailliert.

Wo steht der Markt?

Die Einführung von DMARCbis verläuft schrittweise: Die Empfänger aktualisieren ihre Implementierungen in ihrem eigenen Tempo, und die neuen Tags (np, t) tauchen nach und nach in den Berichten auf. Die reale Posture ganzer Branchen lässt sich beobachten – wie viele Domains nur im p=none sind, zum Beispiel – im DMARC-Observatorium. Der Befund bleibt eindeutig: Die Mehrheit der Domains wendet in zahlreichen Branchen noch immer keinerlei Richtlinie an. DMARCbis wird das nicht von allein ändern; die Ausrichtungsdisziplin schon.

Wichtig zu verstehen: Ein Standard und seine reale Verbreitung sind zwei verschiedene Dinge. Eine RFC zu veröffentlichen dauert Jahre; sie im Feld durchzusetzen dauert noch länger. Die großen Empfänger – Google, Microsoft, Yahoo – integrieren die neuen Regeln pragmatisch, ohne die bestehenden Einträge zu brechen, gerade weil DMARCbis die Rückwärtskompatibilität bewusst bewahrt hat. Praktisch bedeutet das, dass es keinen Stichtag für eine „Migration" gibt: Die neuen Tags lassen sich im eigenen Rhythmus übernehmen, beim nächsten Anfassen des Eintrags. Der einzige Fehler wäre, diese Weiterentwicklung als Vorwand zu nehmen, um das Wesentliche aufzuschieben – nämlich eine Domain, die noch im p=none steckt, endlich in die Durchsetzung zu bringen.

Von 2015 bis 2026: warum jetzt

DMARC wurde 2015 als RFC 7489 veröffentlicht, im Status Informational. In einem Jahrzehnt ist es zu einem De-facto-Standard geworden: Google, Microsoft und Yahoo verlangen es massenhaft von den Absendern, und Vorschriften wie NIS2 oder DORA machen es zu einer erwarteten Kontrolle. Dieser Widerspruch – eine kritische Nutzung, die auf einem nur „informativen" Dokument beruht – musste behoben werden. DMARCbis ist die Frucht mehrjähriger Arbeit innerhalb der IETF, um die Praxiserfahrung in eine echte Norm zu verwandeln: das Protokoll auf die Standards-Schiene zu heben, das zu entfernen, was schlecht funktionierte (pct), und die toten Winkel zu schließen (np für die nicht existierenden Subdomains, Tree Walk anstelle der PSL). Der Zeitpunkt Mai 2026 hat nichts Willkürliches: Er besiegelt die Reife eines unverzichtbar gewordenen Protokolls. Konkret bedeutet das, dass sich auf DMARC zu stützen keine Wette mehr auf eine „gute Praxis" ist, sondern auf eine etablierte Norm – ein gewichtiges Argument, wenn Entscheidungen gegenüber einer Geschäftsleitung oder einem Auditor zu rechtfertigen sind.

Häufige Fragen zu DMARCbis

Ersetzt DMARCbis SPF und DKIM? Nein. DMARCbis rührt weder an SPF noch an DKIM: Es bleibt die Schicht, die sie über die Ausrichtung mit der sichtbaren Domain verknüpft. SPF deklariert die Server, DKIM signiert die Nachrichten, DMARC(bis) verlangt, dass sich eines der beiden mit dem From: ausrichtet. Alle drei funktionieren weiterhin zusammen – siehe wie SPF, DKIM und DMARC zusammenarbeiten.

Ist mein v=DMARC1-Eintrag noch gültig? Ja, vollständig. DMARCbis hat den Bezeichner v=DMARC1 bewusst beibehalten, um nichts zu brechen. Ein für die RFC 7489 geschriebener Eintrag bleibt ein vollkommen gültiger DMARCbis-Eintrag; kein Empfänger wird ihn ablehnen.

Muss ich warten, bis mein DNS-Hoster DMARCbis „unterstützt"? Nein. DMARCbis verlangt nichts Besonderes vom Hoster: Veröffentlicht wird weiterhin ein einfacher TXT-Eintrag. Die Neuerungen (np, t) sind nur neue Tags innerhalb dieses TXT, und jeder DNS kann einen TXT hosten.

Braucht man ein neues Werkzeug, um zu DMARCbis „umzusteigen"? Auch nicht. Der Eintrag lässt sich von Hand bearbeiten. Ein Werkzeug hilft vor allem dabei zu wissen, was zu veröffentlichen ist (welche Tags, welche Richtlinie) je nach realem Zustand der Domain – das ist die Aufgabe von Thomas, weiter unten.

Betrifft das auch kleine Domains? Ja, aber ohne Dringlichkeit. Eine kleine Domain gewinnt vor allem, wenn sie np=reject setzt (kostenlos, risikofrei) und, falls sie noch nicht geschützt ist, p=reject anpeilt – DMARCbis hin oder her. Die Größe ändert nicht die Logik, nur die Zahl der auszurichtenden Quellen.

Ein Sicherheitshinweis: die Schlüssel am richtigen Ort

DMARC, SPF und DKIM beruhen auf Geheimnissen – allen voran den privaten DKIM-Schlüsseln. Sie in einer Konfigurationsdatei oder einer E-Mail herumliegen zu lassen ist genau die Art Nachlässigkeit, die ein Angreifer liebt. DMARC.com wird von Hucency herausgegeben, einem Spezialisten für Cybersicherheit; um solche Geheimnisse (DKIM-Schlüssel, DNS-Zugangsdaten, API-Token) zu zentralisieren und zu verschlüsseln, lohnt ein Blick auf Hucency Vault. Eine gute Schlüsselhygiene ist die natürliche Ergänzung einer guten DMARC-Richtlinie.

Thomas kümmert sich um DMARCbis

Die Entwicklung eines Standards zu verfolgen, während ein Betrieb zu führen ist, gehört in keine Stellenbeschreibung. Thomas, der virtuelle CISO, generiert das exakte DNS zum Veröffentlichen (DMARCbis-Tags inklusive: np, t), benennt jede Sendequelle aus den Berichten, bewertet die Bereitschaft anhand gleitender Daten und nennt den genauen Moment, um risikofrei zu verschärfen – von p=none bis p=reject.

Eine Domain kostenlos analysieren oder ein Konto erstellen und Thomas die schwere Arbeit erledigen lassen.