what-is-dmarcbis

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. Wenn du bereits einen DMARC-Eintrag hast, ist die erste Frage berechtigt: muss ich alles neu machen? 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 du schon heute tun kannst.

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. Wenn du Einsteiger bist, beginne mit was ist DMARC; 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 deine 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.deine-domain.de fälschen, selbst wenn diese Subdomain nicht existiert. Ein np=reject zu setzen verschließt diese Tür ohne jedes Risiko für deine 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 dich entspannen sollte: 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.
• Dein aktueller Eintrag bleibt gültig: Kein Empfänger wird ihn ablehnen, weil er aus der 7489 „stammt".

Mit anderen Worten, du musst nichts ändern, um geschützt zu bleiben. Die Neuerungen sind Verbesserungen, die du übernehmen kannst, wann du willst, keine dringenden Korrekturen.

Musst du handeln?

Wenn deine Domain bereits im p=reject mit sauberer Ausrichtung ist, bist du auf der sicheren Seite. Drei kleine Handgriffe, einfach und risikofrei, lohnen sich trotzdem:

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

Wenn du noch im p=none feststeckst, 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. Du kannst die reale Posture ganzer Branchen 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. Für dich bedeutet das, dass es keinen Stichtag gibt, an dem du „migrieren" müsstest: Du kannst die neuen Tags in deinem eigenen Rhythmus übernehmen, wenn du das nächste Mal deinen Eintrag anfasst. 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 für dich, dass sich auf DMARC zu stützen keine Wette mehr auf eine „gute Praxis" ist, sondern auf eine etablierte Norm – ein gewichtiges Argument, wenn du deine Entscheidungen gegenüber einer Geschäftsleitung oder einem Auditor rechtfertigen musst.

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 deine Server, DKIM signiert deine Nachrichten, DMARC(bis) verlangt, dass sich eines der beiden mit deinem 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 von deinem Hoster: Du veröffentlichst weiterhin einen einfachen 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. Du kannst deinen Eintrag von Hand bearbeiten. Ein Werkzeug hilft vor allem dabei zu wissen, was zu veröffentlichen ist (welche Tags, welche Richtlinie) je nach realem Zustand deiner 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: deine Schlüssel am richtigen Ort

DMARC, SPF und DKIM beruhen auf Geheimnissen – allen voran deinen 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, schau dir Hucency Vault an. Eine gute Schlüsselhygiene ist die natürliche Ergänzung einer guten DMARC-Richtlinie.

Lass Thomas sich für dich um DMARCbis kümmern

Die Entwicklung eines Standards zu verfolgen, während du einen Betrieb führst, ist nicht dein Job. Thomas, dein virtueller CISO, generiert das exakte DNS zum Veröffentlichen (DMARCbis-Tags inklusive: np, t), benennt jede Sendequelle aus deinen Berichten, bewertet deine Bereitschaft anhand gleitender Daten und sagt dir den genauen Moment, um risikofrei zu verschärfen – von p=none bis p=reject.

Analysiere deine Domain kostenlos → oder erstelle ein Konto und lass Thomas die schwere Arbeit erledigen.