DMARCbis ist jetzt ein von der IETF vorgeschlagener Standard. Es wird RFC 7489 und RFC 9091 ersetzen. Ihre bestehenden Einträge verwenden weiterhin v=DMARC1.
Beginnen Sie jetzt mit der Planung, damit Sie bereit sind, wenn die Veröffentlichung erfolgt.
Was ist DMARCbis? Eine kurze Auffrischung
DMARCbis behält das gleiche Ziel bei. Sie können festlegen, welche absendenden Quellen Ihre Domain verwenden dürfen, und wie Empfänger mit E-Mails umgehen sollen, die diese Prüfungen nicht bestehen. Das Update klärt die Spezifikation, formalisiert Konformität und ändert, wie die Organisationsdomain ermittelt wird: jetzt per DNS-Tree-Walk statt Public Suffix List.
Was ändert sich konkret und warum hilft das bei komplexen Domains:
- Entdeckung und Ausrichtung sind klarer: Empfänger suchen nach einem DMARC-Eintrag zuerst auf der Author Domain, dann auf der Organisation Domain und schließlich auf der Public Suffix Domain. DMARCbis definiert den Tree Walk sowohl für die Richtlinienfindung als auch für die Alignment-Prüfung.
- Public Suffix List (PSL) wird ersetzt durch Tree Walk: Tree Walk ersetzt die PSL-Suchen. So entstehen konsistente Grenzen, auch bei verschachtelten Subdomains und PSD-Einträgen.
- Konformität ist explizit: Für volle DMARC-Teilnahme sollten Sie Einträge für jede Author und Organisationsdomain veröffentlichen, Mails senden, die per SPF und DKIM ausgerichtet sind, und Aggregatberichte auswerten.
- Besser für dezentrales DNS: Einträge können auf mehreren Ebenen veröffentlicht werden. Für sehr tiefe Hostnamen tragen Sie einen Eintrag bei der Author Domain ein, damit er vor dem Walk gefunden wird.
Ihre Updates finden Sie in den Tags
Nutzen Sie die folgende Tabelle, um Alt und Neu abzugleichen: Setzen Sie [t] für Tests, nutzen Sie [np], wenn Sie eine Regel für nicht existierende Namen möchten, [psd] nur wenn Sie ein Public Suffix betreiben; entfernen Sie [pct], [rf], [ri] und behalten Sie [v=DMARC1].
Tag-Übersicht
Tag | Klartext-Bedeutung | Wann nutzen? | Optionen | Beispiel |
[t] | Signalisiert Testmodus für die in p, sp oder np gesetzte Richtlinie | Aktivieren während Testphase; deaktivieren im Normalbetrieb | [y] Test aktiviert, Richtlinie wird nicht angewandt aber Sonderregeln greifen | v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com |
[psd] | Kennzeichnet den Eintrag als veröffentlicht durch einen Public Suffix Operator und steuert den Tree Walk | Nur setzen, wenn Sie eine Public Suffix Domain betreiben (Registry o.ä.). Die meisten Domains brauchen diesen Tag nicht. | [y] = Domain ist ein PSD [n] = Domain ist kein PSD | v=DMARC1; p=quarantine; psd=y; rua=mailto:dmarc@example.com |
[np] | Richtlinie für E-Mails an Namen, die unter Ihrer Domain nicht existieren | Nutzen Sie dies, wenn Sie eine explizite Regel für gefälschte/Vertipper-Subdomains möchten | [none], [quarantine], [reject] | v=DMARC1; p=reject; sp=quarantine; np=reject; rua=mailto:dmarc@example.com |
[rf], [ri] | Ehemalige Hinweise zum Failure Report-Format und Aggregatintervall | Aus alten Einträgen entfernen | - | - |
[pct] | Alte Prozent-Rollout-Steuerung | Durch [t] Test ersetzen, nicht in neuen Einträgen verwenden | - | Siehe unten |
Bereiten Sie sich mit Red Sift OnDMARC auf DMARCbis vor
[Pct] -> [t] Zuordnung
- [pct=0] -> verwende [t=y]
- [pct=100] -> Tag weglassen, t=n muss nicht explizit gesetzt werden
- [pct=1-99] -> keine direkte Entsprechung; [t=y] verwenden und Risiko im Test managen (z.B. auf weniger kritischen Domains).
DMARCbis-Eintragsupdate: 5 schnelle Checks
1. Finden Sie Ihre Einträge
Listen Sie den DMARC-Eintrag auf Ihrer Organisationsdomain und auf Schlüssel-Subdomains auf. Notieren Sie etwaige veraltete Tags wie pct, rf oder ri. Diese sind in DMARCbis jetzt veraltet.
2. Syntax der Tags anpassen
Wenn Sie noch nicht bei pct=100 sind, ersetzen Sie pct durch das neue Test-Flag t. pct=0 wird zu t=y. Bei pct=100 können Sie pct entfernen. Entfernen Sie rf und ri. psd bleibt weg, es sei denn, Sie betreiben wirklich eine Public Suffix Domain. v=DMARC1 bleibt.
3. Legen Sie den Richtlinienbereich fest
Bestimmen Sie p für die Basisdomain und sp für existierende Subdomains. Ergänzen Sie np, wenn Sie eine Regel für Mails an nicht existierende Namen wollen, z.B. np=reject. Fehlt np, greifen Empfänger auf sp, dann p zurück.
4. Wählen Sie Alignment-Modi
Verwenden Sie adkim und aspf. (r=relaxed, s=strict). Wählen Sie strict, wenn Sie exakte Übereinstimmung von authentifizierender Domain und Ihrer From-Domain wollen.
5. Berichte überprüfen
Behalten Sie rua für Aggregatberichte. Nutzen Sie ruf mit fo nur, wenn Sie Detailberichte pro Nachricht brauchen. Viele Empfänger senden keine Failure-Berichte oder lehnen diese aus Datenschutzgründen ab. Planen Sie entsprechend.
Warum Red Sift OnDMARC?
DMARCbis ändert, wie die Richtlinie gefunden wird und welche Tags Sie nutzen. Red Sift OnDMARC unterstützt das nativ und verbindet DMARC, SPF und DKIM, damit Sie das Update schnell umsetzen können.
- Alles an einem Ort: DMARC, SPF, DKIM – bearbeiteten Sie Einträge nebeneinander, sehen Sie Alignment-Auswertungen [adkim/aspf] und beheben Sie Lücken für bessere Durchsetzung.
- Für Tree Walk gebaut – Sehen Sie den Knoten, den der Walk trifft (Author -> Org -> PSD) und wo Sie für tiefe Subdomains veröffentlichen müssen.
- Schrittweise Tag-Updates – Verwenden Sie [t], [np], [psd]; entfernen Sie [pct], [rf], [ri]; behalten Sie [v=DMARC1]. Der Builder führt Sie Schritt für Schritt.
- SPF im großen Maßstab – Dynamisches SPF löst das 10-Lookup-Limit per single include, der bei der Abfrage expandiert.
- Sicherere Einführung – Modellieren Sie zuerst mit [t=y] (einen Schritt weicher), bevor Sie live gehen, und rollen Sie Änderungen großflächig für Marken und Regionen aus.
- Klare Berichte – Aggregierte Ansichten zeigen Fehlanpassungen pro Quelle, damit Sie gezielt nachbessern können.
Sprechen Sie mit unserem Team für einen schnellen Check Ihrer Einträge und führen Sie eine kostenlose Investigate-Prüfung durch, um zu sehen, was Empfänger für Ihre Domain zurückmelden.