DMARCbis: Was sich aendert und was nicht

DMARCbis, die naechste Version der DMARC-Spezifikation (im Grunde DMARC 2.0), hat den IETF Last Call abgeschlossen und befindet sich in der Warteschlange des RFC Editor. Die Veroeffentlichung als Proposed Standard wird fuer 2026 erwartet und wird die derzeitige Spezifikation RFC 7489 ausser Kraft setzen. Wenn Sie einen DMARC-Record betreiben, geschehen die meisten Aenderungen im Stillen. Eine Aenderung nicht.

DMARCbis entfernt das pct-Tag, den einzigen protokollinternen Mechanismus von DMARC fuer einen gestaffelten Rollout. Unsere eigenen Daten zeigen, dass dieses Tag nur selten korrekt und fast nie ueberhaupt verwendet wurde. Seine Entfernung formalisiert eine Luecke, die das Protokoll bereits hatte, und verschaerft eine Frage, die DMARC weiterhin nicht beantworten kann: Wie schafft man den Uebergang vom Monitoring zur Durchsetzung, ohne legitime E-Mails zu beschaedigen?

Wo DMARCbis derzeit steht

Der aktuelle Entwurf ist draft-ietf-dmarc-dmarcbis-41, zuletzt aktualisiert am 13. Januar 2026. Der IETF Last Call wurde Ende 2024 auf Basis von Version 36 abgeschlossen. Das Dokument befindet sich nun in der Warteschlange des RFC Editor, dem letzten administrativen Schritt, bevor einem Proposed Standard eine RFC-Nummer zugewiesen und er veroeffentlicht wird.

Drei praktische Punkte vorab.

1. Bestehende DMARC-Records funktionieren weiterhin. Das Versions-Tag bleibt v=DMARC1. Empfaenger, die DMARCbis implementieren, akzeptieren weiterhin Records im Format von RFC 7489.
2. Die meisten Aenderungen geschehen im Stillen. Umbenennungen von Tags und der Ersatz der Public Suffix List durch einen DNS-basierten Mechanismus laufen innerhalb der Empfaenger-Implementierungen ab. Domaininhaber muessen nichts tun, damit ihre Records gueltig bleiben.
3. Eine Aenderung betrifft den Uebergang vom Monitoring zur Durchsetzung: die Entfernung von pct. In Kombination mit der neu gestalteten Testing-Semantik veraendert dies, wie ein gestaffelter Rollout funktionieren soll. Das ist die Aenderung, die man verstanden haben sollte, selbst wenn man den Rest der Spezifikation nicht liest.

Die Aenderungen auf einen Blick

Die wichtigsten Unterschiede zwischen RFC 7489 (aktuelles DMARC) und DMARCbis:

• Entfernte Tags: pct (prozentuale Policy-Anwendung), rf (Format der Forensic Reports), ri (Report-Intervall).
• Neue Tags: psd (Flag fuer Public Suffix Domain, fuer PSOs, die sich DMARC anschliessen), np (Policy fuer nicht existierende Subdomains), t (binaerer Testing-Modus).
• Organizational Domain: Die Public Suffix List (PSL) ist raus. An ihre Stelle tritt ein DNS Tree Walk, der DMARC-Records an aufeinanderfolgenden uebergeordneten Domains nutzt, um die Grenze zu bestimmen.
• Hinweise zu Mailinglisten: Die Spezifikation raet nun ausdruecklich von p=reject fuer Domains mit aktivem Mailinglistenverkehr ab, um Kollateralschaeden bei Abonnenten zu reduzieren.
• Wird obsolet: RFC 7489 (DMARC) und RFC 9091 (PSD DMARC).

Der Rest dieses Beitrags konzentriert sich auf die Aenderungen, die tatsaechlich beeinflussen, wie ein Team DMARC im Produktivbetrieb fuehrt.

Das pct-Tag ist Geschichte

Das pct-Tag war der Versuch von DMARC, Betreibern einen schrittweisen Einstieg in die Durchsetzung zu ermoeglichen. pct=10 auf einem p=quarantine-Record sollte Empfaengern mitteilen: Wende die Quarantaene-Policy auf 10 % der fehlschlagenden Nachrichten an und lass die uebrigen 90 % durch. Die Idee war, Teams herausfinden zu lassen, was unter voller Durchsetzung brechen wuerde, ohne dass tatsaechlich etwas bricht.

In der Praxis hat das nicht funktioniert. Die eigene Begruendung der IETF fuer die Entfernung des Tags haelt fest, dass Empfaenger pct-Werte uneinheitlich anwendeten und dass das Verhalten bei Werten ausser 0 oder 100 im Empfaenger-Oekosystem unzuverlaessig war. Gestaffelter Rollout ueber pct war eine Lotterie: Der veroeffentlichte Prozentsatz und der tatsaechlich auf die E-Mails angewendete Prozentsatz waren selten dieselbe Zahl.

DMARCbis ersetzt den Mechanismus durch das t-Tag. t=y versetzt den Record in den Testing-Modus, der die effektive Policy um eine Stufe herabstuft: Ein p=reject-Record mit t=y wird wie p=quarantine behandelt. t=n (Standard) ist volle Durchsetzung. Es gibt keinen Prozentsatz. Es gibt keinen Gradienten.

Klar gesagt: Die neue Spezifikation ersetzt pct nicht durch etwas, mit dem gestaffelter Rollout tatsaechlich funktionieren wuerde. Sie entfernt den gescheiterten Mechanismus und ueberlaesst das Problem des gestaffelten Rollouts dem Betreiber.

Von der Public Suffix List zum DNS Tree Walk

Unter RFC 7489 konsultiert ein Empfaenger, wenn er E-Mails von einer Subdomain wie invoices.example.com verarbeitet, die Public Suffix List, ein extern gepflegtes Register, um herauszufinden, wo die Grenze der Organizational Domain liegt. Diese Grenze bestimmt, welche DMARC-Policy gilt und wie Alignment bewertet wird.

DMARCbis ersetzt die PSL durch einen DNS Tree Walk. Statt eine externe Liste zu konsultieren, fragt der Empfaenger direkt das DNS ab: Er sucht einen DMARC-Record an der From-Domain, dann an jeder uebergeordneten Domain, und geht dabei Label fuer Label nach oben (invoices.example.com → example.com → com), bis er am ersten gueltigen DMARC-Record haelt. Das neue psd-Tag in diesem Record sagt dem Empfaenger, ob der Record zu einer Organisation oder einem Public Suffix Operator gehoert, was das weitere Verhalten des Empfaengers praegt.

Fuer typische Domains mit einem einzigen Organisations-Record kommen Tree Walk und PSL zum selben Ergebnis. Was sich aendert, sind die Randfaelle. Drei Situationen lohnen eine Pruefung im eigenen Setup:

• Sie veroeffentlichen DMARC-Records auf Subdomains (ueblich, um Transaktionsmails von Marketing zu trennen oder Drittanbieter-Versender zu isolieren). Unter dem Tree Walk gewinnt der DMARC-Record einer Subdomain fuer Mails dieser Subdomain immer gegenueber der Organisations-Policy. Wenn einzelne Subdomain-Records vor Jahren eingerichtet und nie wieder angefasst wurden, koennen sie Ihre aktuelle Organisations-Policy stillschweigend ueberschreiben. Pruefen Sie sie.
• Sie betreiben einen Public Suffix (eine Hostingplattform, die Kunden Domains unter Ihrer Zone vergibt, ein ccTLD- oder gTLD-Registry, ein BaaS oder CMS, das Tenants Subdomains zuweist). Das neue psd=y-Tag ist genau fuer diesen Fall in DMARCbis eingebaut. Unter RFC 7489 war das ueber den separaten RFC 9091 aufgesetzt; DMARCbis fuehrt es in die Hauptspezifikation zurueck. Pruefen Sie, ob Ihre Zone einen psd=y-Record veroeffentlichen sollte.
• Sie haben einen Sender unter einer ungewoehnlichen TLD, ccTLD oder einem Public Suffix mit mehreren Labels (z. B. etwas unter co.uk, github.io, s3.amazonaws.com). Der PSL-Eintrag fuer dieses Suffix deckt sich nicht zwingend exakt mit dem Tree-Walk-Verhalten. Pruefen Sie, ob Ihr DMARC-Record tatsaechlich so aufgeloest wird, wie Sie es erwarten, indem Sie den Record an Ihrer Domain und an jedem uebergeordneten Label bis zum Public Suffix abfragen.

Fuer alle anderen: nichts zu tun. Ihr bestehender DMARC-Record funktioniert unter dem Tree Walk genauso weiter wie unter der PSL.

Neue Hinweise zu Mailinglisten

Die ueberarbeitete Spezifikation ergaenzt einen expliziten Hinweis, p=reject nicht auf Domains mit aktivem Mailinglistenverkehr zu veroeffentlichen. Die Begruendung ist derselbe operative Schmerzpunkt, den DMARC-Betreiber seit Jahren kennen: Mailinglisten schreiben Header so um, dass das DMARC-Alignment bricht, und eine Reject-Policy bestraft Abonnenten, die nichts falsch gemacht haben.

Wenn Ihre Domain nennenswerte Mailinglisten-Nutzung hat (Open-Source-Projektlisten, Branchenforen, Verbandsnewsletter), sollten Sie die neue Empfehlung ernst nehmen. Der Komplette DMARC-Implementierungsleitfaden beschreibt die Subdomain- und ARC-Muster, mit denen die meisten Teams Listenteilnahme mit einer starken Organisations-Policy vereinbaren.

Was DMARCbis nicht loest

Die Spezifikationsrevision gesteht ein, dass der gestaffelte Rollout nie funktioniert hat. Sie repariert ihn nicht. Sie entfernt ihn.

Fuer Organisationen, die von Monitoring zur Durchsetzung wechseln, formalisiert das eine strukturelle Luecke, die unsere eigenen Daten seit Monaten zeigen. In einem Snapshot aktiv ueberwachter Domains auf der DMARCeye-Plattform aus dem ersten Quartal 2026:

• 39,9 % der Domains mit gueltiger DMARC-Policy verharren dauerhaft auf p=none und bieten keinerlei Schutz vor Spoofing, obwohl sie engagiert genug sind, um ein Monitoring-Tool zu betreiben.
• Von den Domains, die durchsetzen, wenden 93,8 % ihre Policy auf 100 % des Traffics ohne gestaffelten Rollout an. Nur 6,2 % nutzen pct<100.

Zwei Ergebnisse, eine Ursache. DMARC bietet keinen funktionierenden Mittelweg zwischen Monitoring und Durchsetzung. Der Mechanismus, der die Luecke schliessen sollte (das pct-Tag), war eine Lotterie, und mit DMARCbis ist er verschwunden. Das neue binaere Testing-Flag ersetzt nicht, was ein gestaffelter Rollout haette leisten sollen.

Vorbereitung ohne Panik

Fuer die meisten Domaininhaber ist DMARCbis keine Feuerwehruebung. Bestehende Records funktionieren unveraendert, und Empfaenger werden ihr Alignment-Verhalten nicht ueber Nacht umstellen. Ein paar praktische Punkte lohnen sich trotzdem im Blick zu behalten, waehrend die Umstellung voranschreitet.

• Wenn Sie derzeit pct fuer einen gestaffelten Rollout nutzen: Ihre Records bleiben syntaktisch gueltig, aber ein DMARCbis-konformer Empfaenger behandelt pct<100 effektiv wie pct=100. Wenn Sie auf den Prozentsatz angewiesen waren, planen Sie den Uebergang jetzt. Der naechste Ersatz innerhalb der Spezifikation ist t=y fuer den Testing-Modus, aber es stuft die Policy um eine Stufe herab, statt sie probabilistisch anzuwenden.
• Wenn Sie eine komplexe Subdomain-Struktur haben: Pruefen Sie Ihre DMARC-Records unter dem Tree-Walk-Modell. Das praktische Ergebnis ist meist dasselbe wie unter der PSL, aber Randfaelle existieren.
• Wenn Sie mit aktivem Mailinglistenverkehr arbeiten: Der neue Hinweis gegen p=reject fuer solche Domains ist ernst zu nehmen. Eine Subdomain-Auslagerung ist das uebliche Muster.
• Wenn Sie seit laengerem auf p=none sind: DMARCbis veraendert Ihre Lage nicht. Das strukturelle Problem liegt nicht in der Spezifikation. Es liegt im Fehlen eines sicheren Uebergangs, den DMARCbis formalisiert, aber nicht loest.

Unser Leitfaden zum Lesen von DMARC-Aggregate-Reports und der Komplette DMARC-Implementierungsleitfaden gelten unter DMARCbis unveraendert weiter. Was sich nach der Verabschiedung der Spezifikation aendert, ist, was Sie in Ihren Record setzen koennen, nicht, wie Sie lesen, was zurueckkommt.

Was der Uebergang tatsaechlich von Ihnen verlangt

Nichts Dringendes. DMARC bleibt nach DMARCbis DMARC, und der Record, den Sie heute veroeffentlichen, wird am Tag der RFC-Verabschiedung weiterhin akzeptiert. Was der Uebergang verlangt, ist eine Haltungsaenderung: Behandeln Sie den Wechsel vom Monitoring zur Durchsetzung als ein Problem, das Ihnen das Protokoll nicht abnehmen wird, und planen Sie entsprechend.

Werkzeuge, die Ihre Aggregate Reports beobachten, unbekannte Sender vor der Durchsetzung markieren und Ihnen in klarer Sprache sagen, was unter einer strikteren Policy brechen wuerde, werden wertvoller, je strenger das Protokoll wird. DMARCeye ist genau fuer diese Rolle gebaut, und unsere kostenlosen Online-Tools (DMARC-Konfigurator, SPF-, DKIM- und BIMI-Checker) decken die Konfigurationsseite in unter zehn Minuten ab.

DMARCeye kostenlos testen und sehen, was Ihre DMARC-Reports wirklich aussagen, bevor sich die Spezifikation verschiebt.