DMARCbis: Was das Update der DMARC-Spezifikation für Ihr Unternehmen bedeutet
DMARC wird erwachsen
Seit RFC 7489 aus dem Jahr 2015 ist DMARC das Rückgrat der E-Mail-Authentifizierung. Fast ein Jahrzehnt lang hat die Spezifikation gehalten — aber sie zeigt Risse. Unklare Definitionen, widersprüchliche Interpretationen zwischen Mailbox-Providern und eine Struktur, die alles in einem einzigen Dokument zusammenpresst, haben zu Implementierungsunterschieden geführt, die Administratoren das Leben schwer machen.
DMARCbis ist die Antwort darauf. Die IETF-Arbeitsgruppe DMARC hat die Spezifikation von Grund auf überarbeitet und in drei separate Dokumente aufgeteilt, die im Mai 2026 als Standards-Track-RFCs veröffentlicht wurden. Das Ergebnis ist klarer, präziser und praxistauglicher.
Drei RFCs statt einem
Der größte strukturelle Unterschied: DMARCbis ersetzt das bisherige RFC 7489 durch drei eigenständige Dokumente.
- RFC 9989 — DMARC (Core) beschreibt das eigentliche DMARC-Protokoll: Richtlinien, Identifier Alignment, Reporting-Mechanik. Es löst RFC 7489 (DMARC) und RFC 9091 (PSL-basierte Organizational-Domain-Bestimmung) ab.
- RFC 9990 — DMARC Aggregate Reporting definiert das Format und die Semantik der RUA-Berichte (Aggregate Reports) separat und deutlich präziser als bisher.
- RFC 9991 — DMARC Failure Reporting behandelt RUF-Berichte (Forensic Reports) als eigenständiges Thema, inklusive Datenschutzüberlegungen. Es aktualisiert das ältere RFC 6591.
Diese Trennung klingt nach Bürokratie, ist aber ein echter Gewinn: Wer nur Aggregate Reporting implementieren will, muss nicht mehr das gesamte Protokolldokument durcharbeiten. Und Implementierer können gezielt auf das relevante RFC verweisen.
Was sich inhaltlich ändert
Klarere Definitionen für Identifier Alignment
Eines der häufigsten Missverständnisse bei DMARC ist das Alignment-Konzept: Wann gilt eine Nachricht als DMARC-konform? DMARCbis schärft die Definitionen für Relaxed und Strict Alignment erheblich. Insbesondere der Umgang mit Subdomains wird präziser beschrieben — ein Bereich, der in der Praxis regelmäßig zu Fehlkonfigurationen führt.
Überarbeitete Policy-Vererbung
Die Frage, welche DMARC-Richtlinie für eine Subdomain gilt, wenn keine eigene Policy gesetzt ist, war in RFC 7489 nicht eindeutig — und die Bestimmung der Organizational Domain über die Public Suffix List (PSL) hat regelmäßig zu Fehlinterpretationen geführt. RFC 9989 ersetzt diesen Ansatz durch einen DNS-Tree-Walk: Empfänger laufen die Domain-Hierarchie label-weise hoch, bis sie einen _dmarc-Record finden oder die Organizational Domain erreichen. Zusätzlich führt RFC 9989 das np=-Tag ein, mit dem für nicht-existierende Subdomains eine separate Policy gesetzt werden kann. Für Unternehmen mit vielen Subdomains ist das eine wichtige Klarstellung.
Präziseres Reporting
Das Aggregate-Reporting-Format (DMARC RUA) bleibt im Kern gleich, aber DMARCbis beschreibt genauer, welche Felder Pflicht sind, welche optional, und wie Empfänger mit fehlenden oder unerwarteten Werten umgehen sollen. Das reduziert die Varianz zwischen Reports verschiedener Mailbox-Provider — ein Problem, das jeden kennt, der DMARC-Reports manuell auswertet.
ARC-Integration
Authenticated Received Chain (ARC) — das Verfahren, das E-Mail-Weiterleitungen über Mailing-Listen oder Forwarder DMARC-kompatibel macht — wird in DMARCbis stärker berücksichtigt. RFC 7489 entstand, bevor ARC standardisiert war; DMARCbis beschreibt explizit, wie ARC-Signaturen bei der DMARC-Auswertung berücksichtigt werden können.
Was gleich bleibt
Die grundlegende Logik von DMARC ändert sich nicht. SPF und DKIM bleiben die beiden Authentifizierungsmechanismen. Das Alignment-Prinzip bleibt erhalten. Die Policy-Werte none, quarantine und reject bleiben unverändert. Wer heute eine korrekte DMARC-Konfiguration hat, muss nichts überstürzen.
Auch das DNS-Record-Format bleibt kompatibel. Ein bestehender _dmarc-TXT-Record funktioniert unter DMARCbis weiterhin — es gibt keine Breaking Changes für Sender.
Was das für die Praxis bedeutet
Für die meisten IT-Administratoren ändert sich kurzfristig wenig. DMARCbis ist im Mai 2026 als RFC 9989, RFC 9990 und RFC 9991 auf dem Standards Track veröffentlicht worden — die Spezifikation ist also abgeschlossen. Mailbox-Provider wie Google und Microsoft werden ihre Implementierungen in den kommenden Monaten Schritt für Schritt darauf ausrichten.
Mittelfristig profitieren vor allem Unternehmen, die:
- Viele Subdomains betreiben und bisher unsicher waren, welche Policy greift
- DMARC-Reports automatisiert auswerten und unter inkonsistenten Report-Formaten leiden
- E-Mail-Weiterleitungen oder Mailing-Listen nutzen, bei denen ARC relevant wird
Für MSPs und IT-Dienstleister, die DMARC für mehrere Kunden verwalten, bringt die klarere Spezifikation weniger Interpretationsspielraum — und damit weniger Support-Aufwand.
Jetzt ist ein guter Zeitpunkt für eine Bestandsaufnahme
DMARCbis ändert nichts Grundlegendes — aber es ist ein guter Anlass, die eigene DMARC-Konfiguration zu überprüfen. Sind alle Subdomains abgedeckt? Werden Aggregate Reports ausgewertet? Ist die Policy bereits auf reject oder noch auf none?
Mit dem kostenlosen Domain-Check von DMARCPulse sehen Sie in Sekunden, wo Ihre Domain steht — und was konkret zu tun ist.