DMARCbis: der vollständige Leitfaden zum neuen DMARC-Standard verstehen und migrieren

⚡TL;DR

• DMARCbis ersetzt DMARC (RFC 7489) und wird ein IETF Proposed Standard. Die drei Dokumente befinden sich in der Warteschlange des RFC Editor, Veröffentlichung wird im Laufe von 2026 erwartet.
• Der DNS Tree Walk ersetzt die Public Suffix List: Die Ermittlung der Organisationsdomäne erfolgt durch aufeinanderfolgende DNS-Abfragen (max. 8), ohne Abhängigkeit von einer externen Liste.
• Drei Tags hinzugefügt: psd (Markierung Public Suffix Domain), np (Richtlinie für nicht existierende Subdomains), t (binärer Testing-Modus).
• Drei Tags entfernt: pct (ersetzt durch t), ri und rf (in die Reporting-Dokumente verschoben).
• Deine aktuellen DMARC-Einträge bleiben gültig (v=DMARC1). Die Migration besteht darin, veraltete Tags zu entfernen und die neuen schrittweise zu übernehmen.

DMARC schützt Domains seit 2015 vor E-Mail-Identitätsmissbrauch. Aber die RFC 7489 hatte strukturelle Schwächen: Abhängigkeit von einer externen Liste (der Public Suffix List), ein schlecht verstandener und schlecht implementierter Tag pct, kein Mechanismus für nicht existierende Subdomains.

DMARCbis behebt diese Probleme. Es ist kein einfaches Update: Es ist eine Neufassung, die DMARC in den Rang eines IETF Proposed Standard erhebt, den ersten normativen Status des Protokolls. Die drei Dokumente (Basis, aggregierte Berichte, Fehlerberichte) befinden sich seit Ende 2025 in der Warteschlange des RFC Editor. Die Veröffentlichung steht unmittelbar bevor.

Dieser Leitfaden richtet sich an Systemadministratoren, E-Mail-Verantwortliche und Sicherheitsingenieure, die die Änderungen verstehen und die Migration vorbereiten müssen. Du findest hier die detaillierte Funktionsweise des DNS Tree Walk, einen vollständigen Tag-Vergleich, einen Migrationsplan und die Auswirkungen auf die Compliance (PCI DSS 4.0, Google, Yahoo, Microsoft).

Ein Glossar am Ende des Artikels definiert die technischen Begriffe: PSL, PSD, PSO, Tree Walk, Organizational Domain, Author Domain.

Was ist DMARCbis?

DMARCbis ist der Nachfolger von DMARC, wie es in der RFC 7489 definiert wurde. Der Begriff "bis" folgt der IETF-Konvention für die zweite Iteration eines Protokolls. Konkret umfasst DMARCbis drei normative Dokumente:

• draft-ietf-dmarc-dmarcbis: das Basisdokument (Richtlinienerkennung, Alignment, Tags)
• draft-ietf-dmarc-aggregate-reporting: die aggregierten XML-Berichte
• draft-ietf-dmarc-failure-reporting: die Fehlerberichte (Nachricht für Nachricht)

Warum diese Überarbeitung?

Die RFC 7489, veröffentlicht 2015, trug den Status "Informational". Das bedeutet, dass DMARC kein Internet-Standard im strengen Sinne war. DMARCbis korrigiert diese Anomalie, indem es zum Proposed Standard wird, was ihm ein normatives Gewicht im IETF-Ökosystem verleiht.

Die technischen Gründe sind präzise:

1. Die Public Suffix List ist fragil. Sie wird manuell von Mozilla gepflegt, ist nicht standardisiert und wird außerplanmäßig aktualisiert. Ein vergessenes Register oder ein nicht gelisteter neuer TLD verursacht falsch-negative Ergebnisse.
2. Der Tag pct war nutzlos. In der Praxis wurden nur die Werte 0 und 100 verwendet. Die Implementierungen variierten zwischen Empfängern, was das Verhalten unvorhersehbar machte.
3. Nicht existierende Subdomains waren nicht geschützt. Ein Angreifer konnte von falsch.subdomain.captaindns.com senden, ohne dass DMARC griff.
4. PSD DMARC (RFC 9091) blieb experimentell. DMARCbis integriert und ersetzt diese Erweiterung durch ein einheitliches Modell mit dem Tag psd und dem Tree Walk.

IETF-Chronologie

Datum	Ereignis
2015	RFC 7489 veröffentlicht (Informational)
2021	RFC 9091 PSD DMARC (Experimental)
2024-2025	Iterative DMARCbis-Drafts innerhalb der WG DMARC
Q4 2025	Die drei Drafts gelangen in die Warteschlange des RFC Editor (Status EDIT)
Q1/Q2 2026	Veröffentlichung als Proposed Standard erwartet

Wesentlicher Punkt: Die Version des DNS-Eintrags bleibt v=DMARC1. Es gibt kein v=DMARC2. Bestehende Einträge funktionieren weiterhin.

Der DNS Tree Walk: das Ende der PSL

Die strukturell bedeutendste Änderung von DMARCbis ist der Ersatz der Public Suffix List durch einen rein DNS-basierten Erkennungsalgorithmus: den Tree Walk.

Das Problem mit der PSL

Mit DMARC v1 konsultierte der Empfänger die Public Suffix List, um die Organisationsdomäne (Organizational Domain) zu bestimmen. Diese Liste, gepflegt von Mozilla, verzeichnet öffentliche Suffixe (co.uk, com.au, gouv.fr). Der Empfänger subtrahierte das öffentliche Suffix von der Domain, um die Organisation zu identifizieren.

Die Grenzen waren bekannt:

• Die Liste muss regelmäßig heruntergeladen und aktualisiert werden (mögliche Verzögerung)
• Neue TLDs oder nicht gelistete Suffixe verursachen Fehler
• Der Mechanismus ist nicht standardisiert: Jede Implementierung handhabt die Liste anders
• Keine DNS-Autorität validiert die Korrektheit der Liste

Wie funktioniert der Tree Walk?

Der Tree Walk befragt direkt das DNS, um die geltende DMARC-Richtlinie zu ermitteln. Der Algorithmus ist wie folgt:

Eingabe: Die Domain aus dem From:-Header (Author Domain)

Schritte:

1. Abfrage von _dmarc.<AuthorDomain>. Wenn ein DMARC-Eintrag mit psd=n (oder ohne Tag psd) gefunden wird, ist diese Domain die Organisationsdomäne. Ende.
2. Wenn kein Eintrag gefunden wird, das linkste Label entfernen und von vorn beginnen.
3. Wenn ein Eintrag mit psd=y gefunden wird, liegt die Organisationsdomäne ein Label unterhalb der aktuellen Domain.
4. Wenn ein Eintrag mit psd=u gefunden wird, den Aufstieg fortsetzen.
5. Wiederholen, bis ein Ergebnis gefunden wird oder das Limit von 8 DNS-Abfragen erreicht ist.

Ausgabe: Die Organisationsdomäne und die geltende Richtlinie (oder "kein DMARC", wenn nichts gefunden wird).

Konkrete Beispiele

Fall 1: einfache Domain

Für newsletter.captaindns.com:

Abfrage 1: _dmarc.newsletter.captaindns.com → kein Eintrag
Abfrage 2: _dmarc.captaindns.com → "v=DMARC1; p=reject; psd=n"

Ergebnis: psd=n bestätigt, dass captaindns.com die Organisationsdomäne ist. 2 DNS-Abfragen.

Fall 2: Public Suffix Domain

Für contact.banque.co.uk:

Abfrage 1: _dmarc.contact.banque.co.uk → kein Eintrag
Abfrage 2: _dmarc.banque.co.uk → kein Eintrag
Abfrage 3: _dmarc.co.uk → "v=DMARC1; p=reject; psd=y"

Ergebnis: psd=y zeigt an, dass co.uk ein PSD ist. Die Organisationsdomäne ist banque.co.uk (ein Label unter dem PSD). 3 DNS-Abfragen.

Fall 3: tiefe Domain

Bei einer Domain mit mehr als 8 Labels springt der Algorithmus nach der ersten Abfrage direkt zu 7 Labels und steigt dann Label für Label auf. Das Limit von 8 Abfragen garantiert, dass der Prozess terminiert.

Vergleich zwischen PSL und Tree Walk

Aspekt	PSL (RFC 7489)	DNS Tree Walk (DMARCbis)
Wahrheitsquelle	Statische Liste (Mozilla)	Das DNS selbst
Aktualisierung	Periodischer Download	Echtzeit über DNS-Abfragen
Abdeckung	Manuell, potenziell unvollständig	Jede Domain mit einem _dmarc-Eintrag
PSD-Erkennung	Lookup in der Liste	Tag psd=y im DNS-Eintrag
Standardisierung	Community-Projekt, nicht normativ	IETF Standards Track

Performance des Tree Walk

Für eine typische Domain mit 3 Labels (wie newsletter.captaindns.com) fügt der Tree Walk maximal 1 zusätzliche DNS-Abfrage im Vergleich zu DMARC v1 hinzu. Das Limit von 8 Abfragen garantiert, dass tiefe Domains keine Überlastung verursachen.

Der DNS-Cache mildert die Auswirkungen in der Praxis. Die _dmarc-Einträge der Organisationsdomäne werden nach der ersten Abfrage gecacht. NXDOMAIN-Antworten werden ebenfalls gemäß dem TTL des MINIMUM-Felds im SOA gecacht. Eine Domain, die Tausende von Nachrichten pro Stunde empfängt, generiert nur eine Handvoll effektiver Tree-Walk-Abfragen.

Im Vergleich dazu erzeugte der PSL-Ansatz keine DNS-Abfragen für die Ermittlung. Er erforderte jedoch den periodischen Download einer etwa 250 KB großen Liste und deren Verwaltung im Speicher.

TTL-Empfehlung: Veröffentliche deine _dmarc-Einträge mit einem TTL von mindestens 3600 s. Ein TTL von 86400 s reduziert die DNS-Last noch weiter. Das ist besonders nützlich für Einträge mit psd=n oder psd=y, die als Ankerpunkte des Tree Walk dienen.

Was sich bei den DMARC-Tags ändert

DMARCbis fügt drei Tags hinzu, entfernt drei und ändert das Verhalten von zwei bestehenden. Der Versions-Tag (v=DMARC1) und die grundlegenden Tags (p, sp, adkim, aspf, fo) bleiben unverändert.

Hinzugefügte Tags

Der Tag psd: Markierung für öffentliche Suffixe

Der Tag psd gibt an, ob die Domain, die den Eintrag veröffentlicht, eine Public Suffix Domain ist.

Wert	Bedeutung
y	Diese Domain ist ein PSD (z. B. co.uk, gouv.fr). Die Organisationsdomäne liegt ein Label darunter.
n	Diese Domain ist eine normale Organisationsdomäne.
u	Nicht bestimmt. Der Tree Walk setzt den Aufstieg fort.

Standardwert: u (undetermined).

Wer sollte ihn verwenden? Nur Betreiber öffentlicher Suffixe (TLD-Registries, sektorale Registries). Für eine Standarddomain lass psd weg oder gib psd=n an.

Beispiel für ein Registry:

_dmarc.co.uk. 3600 IN TXT "v=DMARC1; p=reject; psd=y; rua=mailto:dmarc-agg@registry.co.uk"

Der Tag np: Richtlinie für nicht existierende Subdomains

Der Tag np schließt einen blinden Fleck von DMARC v1: Subdomains, die im DNS nicht existieren. Ein Angreifer konnte von falsch.captaindns.com senden, ohne dass eine Richtlinie griff, wenn kein _dmarc-Eintrag auf dieser Ebene existierte.

Mit np kann die Organisationsdomäne eine spezifische Richtlinie für diese Fälle deklarieren. Die Werte sind identisch mit p: none, quarantine, reject.

Die Fallback-Kette ist: np (falls vorhanden), dann sp (falls vorhanden), dann p.

Der Empfänger prüft die Existenz der Subdomain per DNS. Wenn das DNS NXDOMAIN zurückgibt, gilt die np-Richtlinie.

Beispiel:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc-agg@captaindns.com"

Ergebnis: Existierende Subdomains erben p=quarantine. Nicht existierende Subdomains werden durch np=reject blockiert.

Der Tag t: Testing-Modus

Der Tag t ersetzt die Verwendung von pct=0 für den Testmodus. Die Semantik ist binär:

• t=y: Die Richtlinie wird um eine Stufe herabgestuft (reject wird zu quarantine, quarantine wird zu none)
• t=n: Die Richtlinie gilt normal (Standardwert)

Der Testing-Modus beeinflusst nicht das Reporting: Aggregierte Berichte werden normal gesendet, sodass du die Ergebnisse überwachen kannst, bevor du die strenge Richtlinie anwendest.

Kritischer Punkt für die Übergangsphase: DMARC-v1-Empfänger ignorieren unbekannte Tags. Wenn du p=reject; t=y veröffentlichst, wird ein Empfänger, der DMARCbis noch nicht implementiert hat, reject anwenden, ohne t=y zu berücksichtigen. Dieses Verhalten ist beabsichtigt: Es garantiert, dass standardmäßig die strengste Richtlinie gilt.

Entfernte Tags

Tag	Grund der Entfernung	Ersatz
pct	In der Praxis wurden nur die Werte 0 und 100 verwendet. Das Verhalten variierte zwischen Implementierungen.	t=y für den Testmodus, Streichung für den Rest
ri	Das Reporting-Intervall war de facto auf 24 h standardisiert. Empfänger ignorierten andere Werte.	Geregelt im Dokument Aggregate Reporting
rf	Es existierte nur ein Format (afrf). Keine Alternative wurde jemals eingesetzt.	Geregelt im Dokument Failure Reporting

Wenn deine DMARC-Einträge noch pct, ri oder rf enthalten, funktionieren sie weiterhin (Empfänger ignorieren sie). Es wird jedoch empfohlen, sie zu entfernen, um Mehrdeutigkeiten zu vermeiden.

Geänderte Tags

rua (aggregierte Berichte): Die Syntax für die Größenbegrenzung (!10m) ist gestrichen. Die Prüfung externer Zieladressen ist verschärft: Wenn die Domain der rua-Adresse von der DMARC-Domain abweicht, muss ein Autorisierungseintrag _dmarc-report._report.<rua-domain> existieren.

ruf (Fehlerberichte): In einem separaten RFC-Dokument definiert (Failure Reporting). Gleiche Prüfung externer Zieladressen wie bei rua.

Vergleichstabelle v1 vs. DMARCbis

Tag	DMARC v1	DMARCbis	Status
v	DMARC1	DMARC1	Unverändert
p	none / quarantine / reject	Identisch	Unverändert
sp	Subdomain-Richtlinie	Identisch	Unverändert
adkim	r / s	Identisch	Unverändert
aspf	r / s	Identisch	Unverändert
fo	0 / 1 / d / s	Identisch	Unverändert
rua	URIs mit Größenlimit	URIs ohne Limit, verschärfte externe Prüfung	Geändert
ruf	URIs	In separatem RFC definiert	Geändert
pct	0-100	Entfernt	Entfernt
ri	Sekunden	Entfernt	Entfernt
rf	afrf	Entfernt	Entfernt
np	N/A	none / quarantine / reject	Neu
psd	N/A	y / n / u	Neu
t	N/A	y / n	Neu

Das Reporting wird in drei Dokumente aufgeteilt

DMARC v1 bündelte alles in der RFC 7489: Richtlinie, aggregierte Berichte und Fehlerberichte. DMARCbis trennt diese Verantwortlichkeiten in drei eigenständige normative Dokumente.

Die aggregierten Berichte

Die aggregierten Berichte bleiben im XML-Format, aber das Schema wird weiterentwickelt. Die wichtigsten Änderungen:

• Neuer XML-Namespace: urn:ietf:params:xml:ns:dmarc-2.0
• Neues Feld <testing>: Zeigt an, ob die Domain im Testmodus war (t=y)
• Neues Feld <np>: Richtlinie für nicht existierende Subdomains
• Neues Feld <discovery_method>: Wie die Richtlinie ermittelt wurde (Tree Walk vs. direkt)
• Neue Disposition pass: Zu den möglichen Dispositionen hinzugefügt
• Entfernung von sampled_out: Der Override-Grund entfällt mit pct

Jede in rua gelistete URI erhält ihren eigenen Bericht. Das ist nicht mehr optional: Empfänger MÜSSEN einen separaten Bericht an jede Adresse senden.

Die Fehlerberichte

Die Fehlerberichte werden nun durch ein separates Dokument abgedeckt. Diese Änderung spiegelt die Realität wider: Die meisten großen Anbieter sendeten keine Fehlerberichte, aus Gründen des Datenschutzes und des Volumens.

Das Dokument klärt die Datenschutzanforderungen und die Fälle, in denen der Versand angemessen ist.

Weitere bemerkenswerte Änderungen

• SPF auf MAIL FROM beschränkt: DMARCbis eliminiert die SPF-Prüfung auf Basis von HELO/EHLO. Nur die MAIL-FROM-Domain wird für das Alignment ausgewertet.
• Verstärkte Empfehlung zu p=reject: Domains mit p=reject sollten DKIM verwenden (nicht nur SPF). Empfänger sollten nicht allein aufgrund von p=reject ablehnen, ohne DKIM/SPF auszuwerten. Domains, deren Nutzer in Mailinglisten posten, sollten kein p=reject veröffentlichen.

DMARCbis und Mailinglisten

Mailinglisten sind seit 2015 der problematischste Anwendungsfall für DMARC. DMARCbis löst das Problem nicht, dokumentiert es aber formell und verstärkt die Empfehlungen.

Warum Mailinglisten das Alignment brechen

Eine Mailingliste verändert die Nachricht im Transit. Der SMTP-Envelope ändert sich (neuer MAIL FROM), was das SPF-Alignment bricht. Der Inhalt wird oft verändert (Präfix im Betreff, Abmeldefooter), was die DKIM-Signatur ungültig macht. Das Ergebnis: ein systematisches DMARC-Versagen für Domains mit p=reject.

DMARCbis verstärkt formell die Empfehlung: Domains, deren Nutzer an Mailinglisten teilnehmen, sollten kein p=reject veröffentlichen. Die Richtlinie p=quarantine ist in diesem Fall vorzuziehen.

ARC als Fallback-Mechanismus

ARC (Authenticated Received Chain, RFC 8617) ermöglicht es Intermediären, eine Authentifizierungskette zu bewahren. DMARCbis referenziert ARC als Mechanismus, den Empfänger verwenden KÖNNEN, um die ursprünglichen Authentifizierungsergebnisse wiederherzustellen. Aber DMARCbis macht ARC nicht verpflichtend. Es ist eine Option, keine Garantie.

Die Override-Typen in den aggregierten Berichten

DMARCbis erkennt die folgenden Override-Typen in den aggregierten Berichten an:

• forwarded: Nachricht von einem Dritten weitergeleitet
• mailing_list: Nachricht aus einer Mailingliste
• trusted_forwarder: Vertrauenswürdiger Weiterleiter, identifiziert vom Empfänger
• local_policy: Lokale Richtlinie des Empfängers (Allowlist, Reputation)
• policy_test_mode: Neuer Typ, ersetzt sampled_out (entfernt mit pct)

Diese Typen ermöglichen es zu verstehen, warum ein Empfänger die veröffentlichte Richtlinie nicht angewendet hat.

Praxistipp

Moderne Mailinglisten-Software (Mailman 3, Sympa) enthält integrierte DMARC-Mitigationen. Die häufigste: Umschreiben des From:, um die Adresse der Liste statt der Originaladresse zu verwenden. Wenn deine Domain in Mailinglisten verwendet wird, prüfe, ob diese Mitigationen aktiviert sind. Und bevorzuge p=quarantine gegenüber p=reject.

DMARCbis und E-Mail-Versanddienstleister (ESP)

Kein großer ESP (SendGrid, Mailgun, Amazon SES, Postmark, Brevo) hat im März 2026 eine spezifische DMARCbis-Unterstützung angekündigt. Das ist normal und erwartet: DMARCbis ist eine Änderung auf Empfängerseite, nicht auf Absenderseite. ESPs müssen ihre Infrastruktur nicht anpassen.

DKIM-Alignment: die kritische Herausforderung

Die zentrale Herausforderung für ESPs bleibt das DKIM-Alignment. Zwei Signaturmodi existieren:

• Shared Domain (z. B. d=sendgrid.net): Die DKIM-Signatur verwendet die Domain des ESP. Das strenge Alignment scheitert, weil die DKIM-Domain nicht mit der From:-Domain übereinstimmt. Das relaxed Alignment scheitert ebenfalls.
• Benutzerdefinierte Domain via CNAME (z. B. d=captaindns.com): Die DKIM-Signatur verwendet deine eigene Domain. Das Alignment funktioniert sowohl streng als auch relaxed.

DMARCbis empfiehlt adkim=s (streng). Diese Empfehlung macht eine benutzerdefinierte DKIM-Signatur unverzichtbar für jede Domain, die einen ESP nutzt.

SPF und die Bounce-Domain

DMARCbis eliminiert die SPF-Prüfung auf Basis von HELO/EHLO. Nur die MAIL-FROM-Domain (Return-Path) zählt für das SPF-Alignment. Die meisten ESPs verwenden standardmäßig eine generische Bounce-Domain (z. B. bounce.sendgrid.net). Diese Domain stimmt nicht mit deiner From:-Domain überein, was das SPF-Alignment scheitern lässt.

Die Lösung: Konfiguriere eine benutzerdefinierte Bounce-Domain (Return-Path), die mit deiner From:-Domain übereinstimmt. Die meisten ESPs bieten diese Option über einen CNAME-DNS-Eintrag an.

ESP-Checkliste

1. Benutzerdefinierte DKIM-Signatur prüfen: Dein ESP muss mit d=captaindns.com signieren, nicht mit seiner eigenen Domain.
2. Benutzerdefinierten Return-Path prüfen: Die Bounce-Domain muss mit deiner From:-Domain übereinstimmen.
3. Strenges Alignment testen: Sende eine Test-E-Mail und prüfe die Header. Die Felder d= (DKIM) und Return-Path müssen mit der From:-Domain übereinstimmen.
4. Mit relaxed beginnen, dann auf streng wechseln: Veröffentliche zunächst adkim=r, validiere die Berichte und wechsle dann zu adkim=s.

Wie du zu DMARCbis migrierst

Die gute Nachricht: Die Migration ist schrittweise. Deine aktuellen DMARC-Einträge bleiben funktionsfähig. Hier sind die empfohlenen Schritte.

Schritt 1: Bestehende Einträge auditieren

Identifiziere alle deine Domains und Subdomains, die einen _dmarc-Eintrag veröffentlichen. Notiere die verwendeten Tags, insbesondere pct, ri und rf.

Beispiel eines bestehenden Eintrags:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=100; ri=86400; rua=mailto:dmarc-agg@captaindns.com; ruf=mailto:dmarc-fail@captaindns.com; fo=1"

Schritt 2: Veraltete Tags entfernen

Entferne pct, ri und rf aus deinen Einträgen. Diese Tags werden von DMARCbis-Empfängern ignoriert und bringen v1-Empfängern nichts.

Bereinigter Eintrag:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-agg@captaindns.com; ruf=mailto:dmarc-fail@captaindns.com; fo=1"

Schritt 3: Testing-Modus aktivieren (falls nötig)

Wenn du einen Wechsel von quarantine zu reject vorbereitest, verwende t=y zum Testen:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=reject; t=y; rua=mailto:dmarc-agg@captaindns.com; ruf=mailto:dmarc-fail@captaindns.com; fo=1"

Mit t=y wenden DMARCbis-Empfänger quarantine statt reject an. Die Berichte spiegeln diesen Testmodus wider. Nach der Validierung (2 bis 4 Wochen sauberer Berichte) entferne t=y oder wechsle zu t=n.

Erinnerung: DMARC-v1-Empfänger ignorieren t=y (unbekannter Tag) und wenden p=reject direkt an. Das ist kein Bug: Es ist das erwartete Verhalten.

Schritt 4: Nicht existierende Subdomains schützen

Füge np=reject hinzu, um Spoofing von Subdomains zu blockieren, die in deinem DNS nicht existieren:

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; sp=quarantine; rua=mailto:dmarc-agg@captaindns.com; fo=1"

Schritt 5: DKIM-Alignment prüfen

DMARCbis empfiehlt adkim=s (streng) für Domains, bei denen du die DKIM-Signatur kontrollierst. Strenges Alignment verhindert, dass eine Subdomain die Signatur einer übergeordneten Domain wiederverwendet.

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; adkim=s; aspf=r; rua=mailto:dmarc-agg@captaindns.com; fo=1"

Schritt 6: Externe Reporting-Autorisierungen validieren

Wenn deine rua- oder ruf-Adressen auf eine andere Domain als die DMARC-Domain verweisen, prüfe, ob der Autorisierungseintrag existiert:

captaindns.com._dmarc-report._report.monitoring.captaindns.com. IN TXT "v=DMARC1"

Häufige Migrationsfehler

Sieben Fallen treten bei der Migration zu DMARCbis regelmäßig auf. Sie zu kennen, erspart dir Überraschungen in der Produktion.

1. t=y veröffentlichen, ohne das v1-Verhalten zu verstehen. DMARC-v1-Empfänger (noch die Mehrheit im März 2026) ignorieren t=y, weil es ein unbekannter Tag ist. Sie wenden p=reject direkt an, ohne Herabstufung. Dieses Verhalten ist beabsichtigt, überrascht aber oft Administratoren, die einen universellen Testmodus erwarten.

2. pct=0 zusammen mit t=y beibehalten. Diese Kombination erzeugt inkonsistentes Verhalten. V1-Empfänger wenden pct=0 an (kein Enforcement). DMARCbis-Empfänger ignorieren pct und wenden t=y an (herabgestuftes Enforcement). Ergebnis: Zwei Empfängergruppen mit unterschiedlichem Verhalten. Lösung: Entferne pct, bevor du t hinzufügst.

3. Tree Walk ermittelt eine andere Organisationsdomäne als die PSL. Manche weniger verbreitete TLDs haben einen PSL-Eintrag, der nicht aktuell ist. Der Tree Walk kann dann eine andere Organisationsdomäne identifizieren als der alte PSL-Mechanismus. Mitigation: Veröffentliche einen expliziten _dmarc-Eintrag mit psd=n auf der Ebene deiner Organisationsdomäne.

4. Autorisierungseinträge für externes Reporting vergessen. Wenn du den DMARC-Monitoring-Anbieter wechselst, verweisen die alten _dmarc-report._report-Einträge auf den bisherigen Anbieter. Die Berichte hören stillschweigend auf, ohne Fehlermeldung. Aktualisiere diese Einträge bei jedem Anbieterwechsel.

5. Die Auswirkungen von np=reject nicht testen. Diese Richtlinie kann legitime Dienste betreffen, die dynamische Subdomains verwenden. Manche CDNs, Marketing-Plattformen oder Kampagnen-Tools erstellen Subdomains ad hoc. Prüfe, ob diese Dienste E-Mails von Subdomains senden, die nicht in deinem DNS registriert sind.

6. Sich auf Fehlerberichte (ruf) verlassen. Die großen Anbieter (Google, Yahoo, Microsoft) haben die Fehlerberichte aus Datenschutz- und DSGVO-Gründen praktisch eingestellt. Verwende die aggregierten Berichte (rua) als Hauptquelle für die Analyse. Fehlerberichte sind eine Ergänzung, keine zuverlässige Basis.

7. Eine schrittweise Einführung ohne pct planen. Da pct in DMARCbis gestrichen wurde, gibt es keine prozentuale Einführung mehr. Die Optionen sind t=y (vollständige Herabstufung) oder volles Enforcement (kein t oder t=n). Verwende t=y mit manuellen Monitoring-Fenstern von 2 bis 4 Wochen, um eine schrittweise Einführung nachzubilden.

DMARCbis und regulatorische Compliance

Anti-Phishing-Compliance und Zahlungsstandard

Die Version 4.0 von PCI DSS (gültig seit März 2025) fordert Anti-Phishing-Kontrollen für Unternehmen, die Zahlungen verarbeiten. DMARC im Enforcement-Modus (quarantine oder reject) gehört zu den erwarteten Maßnahmen. DMARCbis verstärkt diese Position mit np=reject (Schutz nicht existierender Subdomains) und der Empfehlung für strenges DKIM-Alignment.

Die Anforderungen von Google und Yahoo für Massenversand

Seit Februar 2024 verlangen Google und Yahoo DMARC für Absender von mehr als 5.000 Nachrichten pro Tag. Obwohl diese Anbieter DMARCbis noch nicht implementiert haben, werden sie die bereinigten Einträge (ohne pct, ri, rf) anerkennen, da diese Tags bereits weitgehend ignoriert werden.

Microsoft und Exchange Online

Microsoft wendet auf Exchange Online und Outlook schrittweise strengere DMARC-Prüfungen an. Die Übernahme von DMARCbis durch Microsoft ist noch nicht angekündigt, aber eine frühzeitige Vorbereitung vermeidet Anpassungen in letzter Minute.

Aktuelle Adoption (März 2026)

Die Adoption auf Empfängerseite ist noch marginal. Nur United Internet AG (GMX, mail.com, WEB.DE) sendet Berichte im DMARCbis-Format (3 Reporter von 3.493 in den beobachteten Daten). Google, Microsoft, Yahoo und Amazon SES haben noch nicht migriert. Jetzt ist der Zeitpunkt, deine Einträge vorzubereiten: Wenn die großen Anbieter umstellen, bist du bereit.

Aktionsplan: die Transition vorbereiten

1. Inventarisieren: Alle Domains und Subdomains mit einem _dmarc-Eintrag erfassen. Die tatsächlichen Author Domains und Zonen ohne DMARC-Eintrag identifizieren.
2. Mit dem DMARCbis Checker testen: Die Kompatibilität jeder Domain prüfen. Veraltete Tags und spezifische Empfehlungen identifizieren.
3. Bereinigen: Einträge säubern, pct, ri, rf entfernen. v=DMARC1 beibehalten.
4. np=reject hinzufügen: Auf Ebene der Organisationsdomäne, um nicht existierende Subdomains zu schützen.
5. t=y verwenden: Für jede Richtlinienverschärfung (Wechsel von quarantine zu reject).
6. Alignment verstärken: adkim=s priorisieren, aspf=r beibehalten, es sei denn, striktes Alignment ist erforderlich.
7. Externe Autorisierungen validieren: Falls deine rua/ruf-Adressen auf einen Drittanbieter verweisen.
8. Aggregierte Berichte überwachen: 2 bis 4 Wochen nach jeder Änderung, um Anomalien zu erkennen.

FAQ

Muss ich v=DMARC1 zu v=DMARC2 ändern?

Nein. Die Version des Eintrags bleibt v=DMARC1. DMARCbis ändert den Versions-Tag nicht. Deine bestehenden Einträge funktionieren weiterhin ohne jegliche Änderung des v-Tags.

Was ist der DNS Tree Walk?

Der DNS Tree Walk ist der DMARCbis-Algorithmus, der die Public Suffix List ersetzt, um die geltende DMARC-Richtlinie für eine Domain zu ermitteln. Er befragt das DNS, indem er vom Absender-Domain (Author Domain) aus Label für Label aufsteigt, mit einem Limit von 8 Abfragen, bis er einen _dmarc-Eintrag findet, der die Organisationsdomäne über den Tag psd identifiziert.

Verschwindet die PSL vollständig?

Ja, aus Sicht von DMARCbis. Die Richtlinienermittlung und die Bestimmung der Organisationsdomäne erfolgen vollständig über den DNS Tree Walk. Die Public Suffix List wird im Standard nicht mehr referenziert. Manche Empfänger können während der Übergangsphase einen PSL-Fallback beibehalten, dies ist aber nicht erforderlich.

Warum wurde der Tag pct entfernt?

In der Praxis wurden nur die Werte 0 (Testmodus) und 100 (vollständige Anwendung) verwendet. Das Verhalten bei Zwischenwerten variierte zwischen Empfängern, was das Ergebnis unvorhersehbar machte. Der Tag t=y/n ersetzt ihn mit einer klaren binären Semantik: Entweder wird die Richtlinie um eine Stufe herabgestuft (Test), oder sie gilt normal.

Ist mein aktueller DMARC-Eintrag DMARCbis-kompatibel?

Ja, sofern der Tag v=DMARC1 vorhanden ist. DMARCbis ist abwärtskompatibel. Die Tags pct, ri und rf werden von DMARCbis-Empfängern ignoriert, ohne einen Fehler auszulösen. Die empfohlene Migration besteht darin, sie zu entfernen und schrittweise np, psd und t zu übernehmen.

Kann ich p=reject für alle meine Domains veröffentlichen?

DMARCbis rät von p=reject für Domains mit allgemeiner Nutzung ab (Mailinglisten, Aliase, Weiterleitungen). Reserviere p=reject für Domains, bei denen du jeden Intermediär End-to-End kontrollierst. Für alle anderen Fälle bleibt p=quarantine empfohlen. Empfänger sollten eine Nachricht nicht allein deshalb ablehnen, weil p=reject veröffentlicht ist: Sie müssen mit anderen Signalen abgleichen (ARC, Reputation, Mailinglisten).

Ist der Tag t=y während der Übergangsphase riskant?

Es gibt ein kalkuliertes Risiko. DMARC-v1-Empfänger ignorieren t=y (unbekannter Tag) und wenden die Richtlinie unverändert an. Wenn du p=reject; t=y veröffentlichst, wird ein v1-Empfänger reject ohne Herabstufung anwenden. Ein DMARCbis-Empfänger wird quarantine anwenden. Dieses Verhalten ist beabsichtigt: Es bevorzugt standardmäßig Sicherheit. Verwende t=y nur, wenn du akzeptierst, dass die strenge Richtlinie bei Empfängern gilt, die noch nicht migriert haben.

Wer sollte den Tag psd verwenden?

Nur Betreiber öffentlicher Suffixe: TLD-Registries (co.uk, com.au, gouv.fr), sektorale Registries und große Organisationen, die Subdomains an unabhängige Einheiten delegieren. Für eine Standard-Unternehmensdomain lass psd weg oder gib psd=n an.

Wann werden die großen Anbieter DMARCbis implementieren?

Kein öffentliches Datum wurde angekündigt (März 2026). Die Adoption auf Empfängerseite ist marginal: Nur United Internet AG (GMX, mail.com, WEB.DE) sendet Berichte im DMARCbis-Format. Die Veröffentlichung der RFCs wird wahrscheinlich die Implementierung bei den großen Anbietern auslösen. Deine Einträge jetzt vorzubereiten, verschafft dir einen Vorsprung.

Wie funktioniert die Fallback-Kette np, sp, p?

Wenn ein DMARCbis-Empfänger eine E-Mail von einer Subdomain empfängt, prüft er zunächst, ob diese Subdomain im DNS existiert. Wenn sie nicht existiert (NXDOMAIN), gilt die np-Richtlinie. Wenn np nicht definiert ist, greift der Empfänger auf sp zurück. Wenn auch sp nicht definiert ist, gilt p. Für existierende Subdomains ist der Fallback sp, dann p (identisch mit DMARC v1).

Verlangsamt DMARCbis die E-Mail-Verarbeitung?

Nein. Der Tree Walk fügt 1 bis 2 DNS-Abfragen für eine typische Domain mit 3 Labels hinzu. Der DNS-Cache mildert diesen Einfluss: Die _dmarc-Einträge und NXDOMAIN-Antworten werden gecacht. Das Limit von 8 Abfragen garantiert eine begrenzte Verarbeitungszeit, auch für tiefe Domains. In der Praxis ist der Latenzunterschied vernachlässigbar.

Muss mein ESP DMARCbis unterstützen?

DMARCbis ist eine Änderung auf Empfängerseite. Dein ESP muss es nicht spezifisch unterstützen. Prüfe jedoch zwei kritische Punkte: die benutzerdefinierte DKIM-Signatur (mit d= passend zu deiner Domain) und den benutzerdefinierten Return-Path (Bounce-Domain abgestimmt auf deine From:-Domain). Diese beiden Elemente sind unverzichtbar für das von DMARCbis empfohlene strenge Alignment.

Glossar

• Author Domain: Domain im From:-Header der Nachricht. Sie ist der Ausgangspunkt des Tree Walk und des DMARC-Alignments.
• DNS Tree Walk: DMARCbis-Algorithmus, der den DNS-Baum Label für Label aufsteigt, um einen _dmarc-Eintrag zu finden und die Organisationsdomäne zu bestimmen. Limit von 8 Abfragen.
• Organizational Domain: Hauptdomain einer Organisation, ermittelt durch den Tree Walk (via psd=n oder Fehlen von psd). Sie ist maßgeblich für die DMARC-Richtlinie, die für ihre Subdomains gilt.
• PSL (Public Suffix List): Von Mozilla gepflegte Liste öffentlicher Suffixe. Wurde von DMARC v1 verwendet, durch den Tree Walk in DMARCbis ersetzt.
• PSD (Public Suffix Domain): Domain-Namenssuffix, das von einer Entität betrieben wird, die Subdomains delegiert (z. B. co.uk, gouv.fr). Identifiziert durch psd=y im DMARC-Eintrag.
• PSO (Public Suffix Operator): Entität, die ein PSD verwaltet und eine Referenz-DMARC-Richtlinie für die zugehörigen Domains veröffentlichen kann.

Verwandte E-Mail-Leitfäden

• DKIM2: alles, was sich ändert
• ARC: die Authentifizierungskette erklärt
• BIMI, VMC, CMC: DNS-Kompatibilität
• Gmail Bulk Sender 2025

Quellen

1. draft-ietf-dmarc-dmarcbis (IETF Datatracker)
2. draft-ietf-dmarc-aggregate-reporting (IETF Datatracker)
3. draft-ietf-dmarc-failure-reporting (IETF Datatracker)
4. DMARC.org Resources
5. PCI DSS 4.0 Summary of Changes (PCI SSC)