DMARCbis: alle Änderungen (und wie Sie sich vorbereiten)

Stand 29. Oktober 2025. Das DMARCbis-Korpus ist nahezu fertig: Das Hauptdokument dmarcbis-41 und aggregate-reporting-32 befinden sich im RFC Editor Queue (MISSREF) und warten auf failure-reporting, das sich noch in der Finalisierung befindet. Bestehende DMARC-Records bleiben im Format v=DMARC1.

TL;DR

• Policy-Discovery & Organisationsdomain: die Public Suffix List (PSL) weicht einem DNS-Tree Walk und dem neuen Marker psd (y/n).
• Neue Tags: psd, np (Richtlinie für non-existent domains), t (testing, ersetzt das sinnvolle Muster pct=0).
• Entfernte Tags: pct, ri, rf.
• Reporting: auf zwei normative Dokumente aufgeteilt (Aggregat- vs. Fehlermeldungen); URI-Längenlimit entfällt; jede aufgeführte URI MUSS einen Report erhalten.
• Interoperabilität: DMARCbis rät für allgemeine Messaging-Domains (Listen, Aliasse, Weiterleitungen) von p=reject ab und empfiehlt p=quarantine, solange die Authentifizierungskette nicht vollständig unter Kontrolle ist; p=reject nur dort einsetzen, wo alle Zwischenstationen unter eigener Hoheit stehen. MTAs dürfen nicht allein wegen p=reject abweisen.
• Kompatibilität: vorhandene DMARC-Records funktionieren weiter; planen Sie die Umstellung auf die neuen Tags und Praktiken.

👉 Am Ende des Artikels fasst ein Glossar die wichtigsten Begriffe zusammen: Public Suffix Domain, Organizational Domain und DNS Tree Walk.

1) Zeitplan & Status

• 17. März 2025: Aggregate Reporting v**–32** → RFC Editor Queue (MISSREF).
• 4. April 2025: DMARCbis v**–41** → RFC Editor Queue (MISSREF).
• 9. Oktober 2025: Failure Reporting v**–17** startet die WG Last Call.
• Veröffentlichung 2025, sofern die offenen Referenzen abgearbeitet werden.
• Sofortige Auswirkung: keine Versionsänderung (v=DMARC1); dennoch müssen Betreiber die neuen Algorithmen und Tags vorbereiten.

2) Policy-Discovery & Organizational Domain: der DNS Tree Walk

DMARCbis ersetzt die Abhängigkeit von der PSL durch einen Aufstieg im DNS-Baum, um

1. die gültige Richtlinie zu finden (Policy Discovery), und
2. die Organisationsdomain für das Alignment zu bestimmen.

Wesentliche Prinzipien:

• Zuerst "_dmarc." + AuthorDomain abfragen. Falls nicht vorhanden, labelweise aufsteigen (maximal 8 Abfragen), bis eine Organizational Domain oder ein PSD gefunden wird.
• Das Tag psd steuert die Interpretation:
  • psd=n ⇒ die veröffentlichende Domain ist eine Organisationsdomain.
  • psd=y (weiter oben) ⇒ die Organisationsdomain liegt einen Label tiefer.
• Wird eine Richtlinie von einer übergeordneten Domain geerbt (Org oder PSD), gilt sp für bestehende Subdomains und np, wenn die Subdomain nicht existiert.
• Wird nichts gefunden, greift DMARC für diese Nachricht nicht.

3) Tags: hinzugekommen, entfernt, unverändert

Neu

• psd: kennzeichnet eine Domain als Public Suffix Domain (y/n) für den Tree Walk.
• np: Richtlinie für nicht existente Domains (Erfahrungen aus den PSD-Piloten).
• t: Testmodus (y/n) – ersetzt das nützliche pct=0-Muster (siehe unten).

Entfernt

• pct: Teil-Rollouts wurden uneinheitlich umgesetzt; das binäre 0/100-Rollout erfolgt künftig über t.
• ri: Intervall für Aggregatberichte (wandert in das Dokument Aggregate Reporting und in Betreiberpraxis).
• rf: Format von Fehlermeldungen (präzisiert im Dokument Failure Reporting).

Unverändert (Beispiele)

v, p, sp, adkim, aspf, fo, rua, ruf, pct (entfällt – bitte ausrollen).

4) psd: Marker für Public Suffix Domains

Das Tag psd gibt an, ob die veröffentlichende Domain vom Tree-Walk-Algorithmus als Public Suffix Domain behandelt werden soll:

• psd=y: die Domain gilt als PSD. Die veröffentlichte Richtlinie deckt das verwaltete Suffix ab, lässt aber registrierbare Domains darunter ihre eigene DMARC-Politik führen.
• psd=n: die Domain ist eine Organisationsdomain und Anker für die Policy-Discovery ihrer Subdomains.

Setzen Sie psd=y nur als Betreiber eines Suffixes (TLDs, Branchenregister, große Organisationen mit delegierten Subdomains). Andernfalls auf psd verzichten oder psd=n setzen, um eine „klassische“ sendende Zone zu kennzeichnen.

5) np: Richtlinie für nicht existente Domains

Das Tag np erweitert DMARC auf nicht existente Subdomains, die während des Tree Walks gefunden werden:

• Es greift nur, wenn für die betroffene Subdomain kein eigener _dmarc-Record existiert (NXDOMAIN).
• Zulässige Werte (none, quarantine, reject) entsprechen p/sp.
• Fehlt np, wird der Wert von p (bzw. vererbtes sp) verwendet.

Veröffentlichen Sie np=reject auf Ihrer Organisationsdomain (oder PSD), um Spoofing auf „leeren“ Subdomains zu blockieren, ohne überall einzelne DMARC-Records anzulegen.

6) t = testing: der praktische Nachfolger von pct=0

Das Tag t=y deaktiviert das Reporting nicht, fordert aber eine mildere Durchsetzung der Richtlinie an:

• p=reject + t=y ⇒ Fehlschläge als quarantine behandeln.
• p=quarantine + t=y ⇒ Fehlschläge als none behandeln.
• p=none ⇒ unverändert.

Ziel: eine sichere Hochstufung ohne die Interoperabilitätsprobleme, die pct verursachte.

7) Reporting: Aufteilung, Deliverability & Sicherheit

• Aufgespalten in zwei RFCs: Aggregatberichte (XML) und Fehlerberichte (pro Nachricht).
• URI-Längenlimit entfällt.
• Mehrere URIs in rua/ruf: jede URI MUSS einen eigenen Report erhalten.
• Externe Ziele (rua/ruf zu einer Fremddomain): das Autorisierungsverfahren bleibt unverändert (Records beim Report-Empfänger).
• Datenschutz: Fehlerberichte vorsichtig aktivieren; die meisten Betreiber fokussieren weiterhin auf Aggregatberichte.

8) Interoperabilität & Richtlinien

• DMARCbis stellt klar, dass Betreiber für allgemeine Messaging-Domains (Mailinglisten, Aliasse, Weiterleitungen) kein p=reject publizieren sollten; bevorzugen Sie p=quarantine, bis die Authentifizierungskette Ende-zu-Ende unter Kontrolle ist, und behalten Sie p=reject nur dort, wo jede Station unter eigener Kontrolle steht.
• Empfänger sollten nicht nur wegen einer veröffentlichten p=reject-Richtlinie eine Nachricht ablehnen; sie müssen weitere Signale korrelieren (Listenverhalten, Header-Umschreibungen, ARC, Reputation etc.).
• Um relaxed-alignment-Bypässe zu verhindern, DMARC-Records so nah wie möglich an den tatsächlichen Versanddomains veröffentlichen (und bei Bedarf adkim=s/aspf=s setzen).

9) Kompatibilität & Umstieg

• v=DMARC1 bleibt: vorhandene Records gelten weiter.
• Abschaffen: pct, ri, rf.
• Einführen: psd wo sinnvoll (PSOs / TLDs oder spezielle registrierbare Domains), np für non-existent domains, t zur Steuerung des Rollouts.

Beispiel-Records

Organisationsrichtlinie + kontrollierte Hochstufung

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; sp=reject; adkim=s; aspf=r; 
  rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; fo=1; t=y"

PSD-Markierung eines Suffix-Betreibers

_dmarc.bank.example. 3600 IN TXT "v=DMARC1; p=reject; psd=y; rua=mailto:psd-agg@pso.example"

Richtlinie für nicht existente Domains

_dmarc.example.net. 3600 IN TXT "v=DMARC1; p=quarantine; np=reject; rua=mailto:agg@example.net"

10) CaptainDNS-Playbook (Praxis-Checkliste)

1. Inventur: reale Author Domains und aktive Subdomains erfassen; Zonen ohne DMARC identifizieren.
2. DNS-Bäume: prüfen, wo der Tree Walk landet (welche Organisationsdomain greift?) und Records so nah wie möglich an den Sendern veröffentlichen.
3. Richtlinien: mit p=quarantine + t=y starten; Aggregatberichte 2–4 Wochen monitoren; dann t=n setzen und weiter verschärfen, wenn False Positives im Griff sind.
4. Alignment: zunächst auf adkim=s abzielen (DKIM auf dem From); aspf=r beibehalten, sofern kein striktes SPF nötig ist.
5. PSD / np: wenn Sie eine Stamm- oder „Familien“-Domain betreiben, np nutzen, um non-existent domains zu blockieren; psd nur setzen, wenn Sie PSO/PSD sind.
6. Reporting: dedizierte rua/ruf-Postfächer, Transportverschlüsselung; externe Autorisierungen prüfen, falls ein Dritter Reports empfängt.
7. Listen / Zwischenstationen: From:-Umschreibungen einkalkulieren; ARC hilft, Reputation zu bewahren und unnötige Rejects zu vermeiden.
8. Aufräumen: pct, ri, rf entfernen; Aggregatberichte beobachten, um Interoperabilitätsabweichungen zu erkennen.

11) FAQ

• Müssen wir v=DMARC1 auf v=DMARC2 ändern? Nein – der Wert bleibt DMARC1.
• Wird pct noch berücksichtigt? Es wurde aus dem Standard entfernt; manche Empfänger ignorieren es. Verwenden Sie stattdessen t.
• Ist die PSL endgültig weg? Für DMARCbis ja: die Discovery stützt sich nun auf den DNS Tree Walk.
• Kann ich überall p=reject setzen? Nur, wenn Sie die Authentifizierungskette komplett kontrollieren; für allgemeine Kommunikation (Listen, Aliasse, Weiterleitungen) empfiehlt DMARCbis p=quarantine.

12) Glossar

• Public Suffix List (PSL): historisch von Mozilla gepflegte Liste öffentlicher Suffixe; DMARCbis ersetzt sie durch den DNS Tree Walk.
• Public Suffix Domain (PSD): Domainsuffix, das von einer Organisation betrieben und an Dritte delegiert wird (z. B. TLDs, Branchenregister) und eine DMARC-Richtlinie für das gesamte Suffix veröffentlichen kann.
• Public Suffix Operator (PSO): Betreiber eines öffentlichen Suffixes (PSD), der eine Referenz-DMARC-Richtlinie für angeschlossene Domains veröffentlichen kann.
• DNS Tree Walk: DMARCbis-Prozess, der den DNS-Baum Label für Label nach einem _dmarc-Record durchläuft, ein PSD erkennt und bei Bedarf vererbte Richtlinien (p, sp, np) anwendet.
• Organizational Domain: primäre Domain einer Organisation; wird per Tree Walk ermittelt und steuert die DMARC-Richtlinie für ausgerichtete Subdomains.
• Author Domain: Domain im sichtbaren From:-Header; dient als Grundlage für DMARC-Alignment.

---

Illustrationen: eigens erstellte SVG-Grafiken für CaptainDNS.