Skip to content

DMARCbis-Übersicht

Willkommen im DMARCbis-Dokumentationsbereich. Hier finden Sie einen Überblick über DMARCbis, die bedeutendste Aktualisierung des DMARC-Standards seit seiner ersten Veröffentlichung.

Was ist DMARCbis?

DMARCbis ist eine Überarbeitung von DMARC (Domain-based Message Authentication, Reporting, and Conformance). Die Bezeichnung „bis" folgt den üblichen Namenskonventionen für Protokollüberarbeitungen.

Die ursprüngliche DMARC-Spezifikation (RFC 7489) wurde 2015 als „Informational"-Dokument veröffentlicht, während DMARCbis als „Proposed Standard" veröffentlicht wurde. Dies hebt den formalen Status von DMARC auf den eines bewährten, weit verbreiteten E-Mail-Authentifizierungsprotokolls, das auf mehr als einem Jahrzehnt Einsatzerfahrung aufbaut.

DMARCbis stärkt den ursprünglichen Standard durch:

  • Aufteilung der Spezifikation in klarere, detailliertere Entwürfe mit zusätzlichen Beispielen
  • Verbesserung der Bestimmung der Grenzen von Organisationsdomains durch DNS-native Lookups anstelle einer manuell gepflegten Liste
  • Vereinfachung der Richtlinien-Tags durch Entfernung inkonsistenter Altlasten
  • Erhöhte Berichtsanforderungen für bessere Sichtbarkeit und Sicherheit

Entscheidend ist, dass DMARCbis die Abwärtskompatibilität beibehält. Es verwendet weiterhin v=DMARC1 als Versionskennung, sodass bestehende DMARC-Einträge ohne sofortige Änderungen gültig bleiben — Organisationen können die neuen Funktionen schrittweise einführen.

Wichtige Änderungen in DMARCbis

Umstrukturierte Spezifikation

Der aktualisierte Standard ist in drei separate Entwürfe aufgeteilt:

  • Kernprotokoll — definiert die DMARC-Grundlagen
  • Aggregierte Berichterstattung — beschreibt, wie tägliche Berichte erstellt und formatiert werden
  • Forensische Berichterstattung — beschreibt, wie Informationen zu Authentifizierungsfehlern gemeldet werden

Diese Aufteilung macht den Standard leichter verständlich, umsetzbar und langfristig wartbar.

DNS-Tree-Walk-Algorithmus

Die bedeutendste technische Änderung ersetzt die Public Suffix List (PSL) durch einen DNS-Tree-Walk-Algorithmus zur Ermittlung der Organisationsgrenze einer Domain.

Anstatt sich auf eine manuell gepflegte öffentliche Liste zu verlassen, fragt ein Empfänger aufeinanderfolgende Ebenen der Domain-Hierarchie ab — wobei er sich jeweils ein Label nach oben bewegt — bis er einen DNS-Eintrag findet, der mit psd=y (eine Public-Suffix-Domain) oder psd=n (eine Organisationsgrenze) gekennzeichnet ist.

  • Der Walk ist auf acht Ebenen begrenzt, um übermäßige DNS-Abfragen zu vermeiden.
  • Bei Domains mit acht oder mehr Labels werden die am weitesten links stehenden Labels entfernt, bis sieben verbleiben, bevor der Walk beginnt.
  • Der Walk stoppt, sobald ein gültiger DMARC-Eintrag mit einem expliziten psd-Wert gefunden wird.

Dieser DNS-native Ansatz beseitigt die Abhängigkeit von einer Drittanbieterliste, wodurch es wahrscheinlicher wird, dass Grenzänderungen konsistent erkannt werden, und verbessert insgesamt die Genauigkeit der Domaingrenzenerkennung.

Hinweis: Während der Übergangsphase verwenden manche Empfänger möglicherweise noch die PSL, während andere den Tree Walk nutzen, was gelegentlich zu unterschiedlichen Ergebnissen für dieselbe Domain führen kann. Die Veröffentlichung eines expliziten DMARC-Eintrags für jede Domain und Subdomain — einschließlich eines psd-Tags, wo relevant — vermeidet Mehrdeutigkeiten.

Neue Richtlinien-Tags

DMARCbis führt drei neue Tags für eine feinere Steuerung ein:

TagZweck
psd (Public Suffix Domain)y kennzeichnet die Domain als Public-Suffix-Domain, n kennzeichnet sie als Organisationsdomain. Der Standardwert u überlässt die Bestimmung dem Tree Walk.
np (Non-Existent Subdomain Policy)Legt die Richtlinie für E-Mails fest, die vorgeben, von einer Subdomain zu stammen, die im DNS nicht existiert — und schließt damit eine Spoofing-Lücke, bei der Angreifer erfundene Subdomains wie ceo.example.com verwenden.
t (Testing Mode)Signalisiert, dass eine Richtlinie getestet wird und noch nicht durchgesetzt wird (y), oder normal angewendet wird (n, Standard).

Veraltete Alt-Tags

Drei Tags wurden abgeschafft, da sie bei verschiedenen Empfängern zu inkonsistenten Ergebnissen führten:

  • pct (Prozentsatz) — abgelöst durch das klarere t-Tag (Testing Mode)
  • rf (Berichtsformat)
  • ri (Berichtsintervall) — die Berichtshäufigkeit ist jetzt einheitlich festgelegt, anstatt konfigurierbar zu sein

Diese Tags werden zur Abwärtskompatibilität weiterhin veröffentlicht, wenn sie gesetzt sind, aber DMARCbis-fähige Empfänger werden sich zunehmend auf deren Ersatz verlassen.

Erweiterte Berichterstattung

Aggregierte und forensische Berichterstattung haben nun jeweils einen eigenen Spezifikationsentwurf mit strengeren Anforderungen an Konsistenz und Sicherheit:

  • Verpflichtende Validierung externer Berichtsadressen (der rua=/ruf=-Empfänger muss Berichte autorisieren, die außerhalb der sendenden Domain versendet werden)
  • Standardisierte Anhangsformatierung und Namenskonventionen
  • Strengere Durchsetzung der XML-Struktur und der gzip-Komprimierung

Hinweise zu Mailinglisten

DMARCbis bietet explizite Hinweise zu Mailinglisten und weitergeleiteten E-Mails. Es rät davon ab, eine p=reject-Richtlinie zu veröffentlichen, wenn Mailinglisten Teil des normalen E-Mail-Flusses sind, da Listensoftware häufig sowohl das SPF- als auch das DKIM-Alignment stört — was dazu führen kann, dass legitime Nachrichten abgelehnt werden.

Gleichzeitig ermutigt DMARCbis Domaininhaber weiterhin, wo immer möglich auf eine p=reject-Richtlinie hinzuarbeiten, da dies die einzige Richtlinie ist, die eine Domain vollständig vor unbefugter Nutzung schützt. Die Empfehlung lautet, Ihr E-Mail-Ökosystem — einschließlich etwaiger Mailinglisten — zu bewerten, bevor Sie zu einer strikten Durchsetzung übergehen.

Wichtige Vorteile

  • Genauere Erkennung von Organisationsdomains durch den DNS-Tree-Walk-Algorithmus
  • Einfachere, klarere Richtlinien-Tags mit eindeutigen Testsignalen
  • Stärkerer Schutz vor Spoofing nicht existierender Subdomains
  • Bessere Unterstützung für komplexe Domainstrukturen und Public-Suffix-Domains
  • Verbesserte Konsistenz und Sicherheit bei der Berichterstattung
  • Keine erzwungene Migration — bestehende Einträge bleiben gültig, während Sie neue Funktionen in Ihrem eigenen Tempo einführen

Häufig gestellte Fragen

Muss ich meinen aktuellen DMARC-Eintrag für DMARCbis ändern?

Es sind keine sofortigen Änderungen erforderlich. DMARCbis behält dieselbe Versionskennung (v=DMARC1) bei, sodass bestehende Einträge gültig bleiben. Sie können die neuen Tags schrittweise einführen, um Ihre E-Mail-Authentifizierung im Laufe der Zeit zu stärken.

Wie verbessert der DNS-Tree-Walk die Public Suffix List?

Anstatt sich auf eine manuell gepflegte Liste öffentlicher Suffixe zu verlassen, fragt der Tree Walk das DNS direkt ab und bewegt sich durch die Domain-Hierarchie nach oben, um die korrekte Organisationsgrenze zu ermitteln. Dies ist konsistenter, da es nicht davon abhängt, dass ein Dritter eine Liste aktuell hält.

Sollte ich jetzt eine p=reject-Richtlinie festlegen, da DMARCbis dies für Mailinglisten abrät?

DMARCbis rät nicht generell von p=reject ab — es empfiehlt speziell Vorsicht, wenn Mailinglisten Teil Ihres E-Mail-Flusses sind, da diese das SPF/DKIM-Alignment stören können. Überprüfen Sie, wie die E-Mails Ihrer Domain tatsächlich gesendet und weitergeleitet werden, bevor Sie zu einer strikten Durchsetzung übergehen.

Verwandte Themen

  • DMARC-Übersicht — Einführung in DMARC und seinen Zweck
  • DMARC-Syntax — Detaillierte Informationen zu DMARC-DNS-Eintragsfeldern
  • DMARC-Einstellungen — Konfigurieren Sie DMARCbis-Tags wie Testing Mode und Non-Existent Subdomain Policy