Was misst der Score von 0 bis 100?

Der Score misst die DMARCbis-Kompatibilität Ihres aktuellen DMARC-v1-Eintrags. 100 = keine Änderung erforderlich. 90 oder mehr = ein oder zwei kleinere Anpassungen. 75 bis 89 = Teilmigration. 50 bis 74 = wesentliche Migration. Unter 50 oder ungültiger Eintrag = vor der Migration neu schreiben.

Welche Tags werden in DMARCbis entfernt?

Drei Tags entfallen: pct (die Richtlinie gilt standardmäßig für 100%), rf (es bleibt nur ein Berichtsformat), ri (Standard-Berichtsintervall wird erzwungen). Der fo-Tag wird beibehalten. Wenn pct unter 100 lag, wandelt das Tool den Wert in t=y um, um den Testmodus zu signalisieren.

Wofür ist der neue np-Tag?

Der np-Tag (non-existent subdomain policy) definiert die Richtlinie für nicht existierende Subdomains. In DMARCbis erben diese Subdomains nicht mehr implizit von sp oder p: np muss explizit sein. Das Tool leitet np von sp ab, falls vorhanden, sonst von p.

Was ist der Unterschied zwischen t=y und pct=0?

Der t=y-Tag ist der offizielle Ersatz für pct=0 in DMARCbis. Im t=y-Modus wenden Empfänger eine Richtlinie eine Stufe niedriger an: reject wird zu quarantine, quarantine wird zu none. Die Semantik ist klarer als ein Prozentwert.

Bricht die Migration die Zustellbarkeit?

Nein. Die Version bleibt v=DMARC1 und Empfänger, die DMARCbis noch nicht unterstützen, ignorieren np, t und psd, ohne den Eintrag abzulehnen. Die Abwärtskompatibilität ist vollständig, Ihre E-Mails werden während des Übergangs weiterhin von DMARC v1 verarbeitet.

Welche Dimensionen bewertet der Score?

Sechs gewichtete Dimensionen: keine veralteten Tags (40 Punkte), np-Tag vorhanden (15 Punkte), Stärke der Richtlinie (20 Punkte), DKIM- und SPF-Ausrichtung (10 Punkte), rua-Reporting konfiguriert (10 Punkte) und syntaktische Hygiene (5 Punkte).

Was tun, wenn mein Eintrag ungültig ist?

Das Tool gibt ein kritisches Urteil zurück und behält den ursprünglichen Eintrag bei, ohne die Migration anzuwenden. Beheben Sie zunächst die Syntaxfehler (ungültige Richtlinie, fehlerhafte rua-URI, pct außerhalb des Bereichs) mit dem DMARC Validator und starten Sie die Migration erneut.

Sollte ich vor der offiziellen RFC-Veröffentlichung migrieren?

Es ist nicht verpflichtend. Der DMARCbis-Entwurf befindet sich in der finalen IETF-Phase. Die Vorbereitung Ihres Eintrags durch Entfernen veralteter Tags und Hinzufügen von np ermöglicht es Ihnen, bereit zu sein, sobald der RFC veröffentlicht wird. Die neuen Tags werden von aktuellen Empfängern ignoriert, daher besteht kein Risiko bei einer vorzeitigen Migration.

DMARC zu DMARCbis Migration Tool - Kostenlos

Warum zu DMARCbis migrieren?

DMARCbis löst die 2015 veröffentlichte RFC 7489 ab. Der Entwurf führt vier strukturelle Änderungen ein:

Entfernung von pct, rf, ri: die Richtlinie gilt nun standardmäßig für 100% des Datenverkehrs, es bleibt nur ein definiertes Berichtsformat und das Berichtsintervall wird standardmäßig erzwungen. Der fo-Tag bleibt erhalten.
Hinzufügung von np: die Richtlinie für nicht existierende Subdomains wird explizit und schließt eine Lücke, die Angreifer durch Erfinden fiktiver Subdomains ausnutzen.
Umwandlung von pct<100 in t=y: der Testmodus ersetzt den Prozentwert. Einfacher, vorhersehbarer, besser auf das tatsächliche Empfängerverhalten abgestimmt.
DNS Tree Walk zur Identifikation der organisatorischen Domain, der die Public Suffix List ersetzt.

Ihr aktueller DMARC-Eintrag funktioniert während des Übergangs weiter. Jetzt zu migrieren bedeutet, bei der offiziellen RFC-Veröffentlichung bereit zu sein und sofort vom Schutz nicht existierender Subdomains über np zu profitieren.

Wie der Analyzer funktioniert

Das Tool analysiert Ihren DMARC-v1-Eintrag, wendet die DMARCbis-Transformationen an und berechnet einen DMARCbis-Kompatibilitätsscore von 0 bis 100. Die Berechnung erfolgt lokal, ohne DNS-Auflösung oder externen Aufruf.

Die fünf möglichen Urteile

Urteil	Score	Bedeutung
Bereits konform	90 bis 100	Keine Änderung erforderlich oder kleinere Anpassung. Achten Sie auf die offizielle RFC-Veröffentlichung.
Teilmigration	75 bis 89	Ein bis drei kleinere Änderungen (typischerweise redundantes `pct=100` oder fehlendes `np`).
Wesentliche Migration	50 bis 74	Vier oder mehr Änderungen. Mehrere veraltete Tags und schwache Richtlinie.
Ungültiger Eintrag	0 bis 49 oder ungültiger Zustand	Vor der Migration zu behebende Syntaxfehler.
Kein Eintrag	N/A	Leeres Feld. Fügen Sie zuerst einen DMARC-Eintrag ein, bevor Sie die Analyse starten.

Die sechs Bewertungsdimensionen

Dimension	Gewichtung	Was die Dimension misst
Keine veralteten Tags	40 Punkte	Vorhandensein von `pct`, `rf`, `ri`. Je mehr vorhanden, desto stärker der Abzug.
`np`-Tag vorhanden	15 Punkte	Explizite Richtlinie für nicht existierende Subdomains. Erbt von `sp` oder `p`, falls abwesend.
Stärke der Richtlinie	20 Punkte	`reject` erhält das Maximum, `quarantine` einen Teil, `none` einen Mindestwert.
DKIM- und SPF-Ausrichtung	10 Punkte	`adkim=s` und `aspf=s` erhalten das Maximum, `r` behält einen Teil.
`rua`-Reporting konfiguriert	10 Punkte	Gültige mailto-URI für aggregiertes Reporting.
Syntaktische Hygiene	5 Punkte	Wohlgeformter, parsbarer Eintrag.

Drei Prioritätsfaktoren werden oben im Ergebnis angezeigt, um den Score sofort zu erklären, bevor die Aufschlüsselung nach Dimensionen folgt.

Die wichtigsten Änderungen DMARC zu DMARCbis

Entfernte Tags

Tag	Aktion	Warum
`pct`	Entfernen	Die Richtlinie gilt standardmäßig für 100%. Bei `pct<100` wandelt das Tool den Wert in `t=y` um.
`rf`	Entfernen	In DMARCbis bleibt nur ein Berichtsformat definiert.
`ri`	Entfernen	Empfänger erzwingen ein Standard-Berichtsintervall.

Hinzugefügter Tag

Tag	Wert	Warum
`np`	erbt von `sp` oder `p`	Richtlinie für nicht existierende Subdomains. Muss in DMARCbis explizit sein.

Unverändert beibehaltene Tags

v=DMARC1, p, sp, adkim, aspf, rua, ruf. Ihre Semantik bleibt unverändert.

Empfohlener Migrationsplan

Schritt 1: aktuellen Eintrag prüfen. Starten Sie die Analyse mit Ihrem veröffentlichten DMARC-Eintrag. Notieren Sie den Score, das Urteil und die Empfehlungen.

Schritt 2: vorgeschlagene Änderungen anwenden. Kopieren Sie den migrierten Eintrag und veröffentlichen Sie ihn in Ihrer DNS-Zone unter _dmarc.captaindns.com. Behalten Sie den vorherigen Eintrag 48 Stunden lang mit einem kurzen TTL (300 Sekunden) bei, um bei Bedarf ein schnelles Rollback zu ermöglichen.

Schritt 3: rua-Berichte überwachen. Überprüfen Sie zwei bis vier Wochen lang Ihre aggregierten DMARC-Berichte, um zu bestätigen, dass keine Auswirkungen auf legitime Flüsse vorliegen. Der Wechsel zu np kann undokumentierte aktive Subdomains aufdecken.

Schritt 4: TTL stabilisieren. Sobald die Berichte validiert sind, erhöhen Sie den TTL wieder auf 3600 oder 86400 Sekunden. Die Migration ist abgeschlossen.

Wenn Sie auch von einer lockeren Richtlinie zu p=reject wechseln, verwenden Sie t=y für einige Wochen. DMARCbis-Empfänger wenden dann eine Richtlinie eine Stufe niedriger an, was während der Validierungsphase als Sicherheitsnetz dient.

Häufige Fehler, die zu vermeiden sind

pct=100 beibehalten. Dieser Wert ist in DMARCbis redundant. Der gesamte Tag kann ohne Verhaltensänderung entfernt werden.

np und sp verwechseln. sp zielt auf bestehende Subdomains, np ausschließlich auf nicht existierende Subdomains. Beide Tags sind komplementär, nicht austauschbar.

pct und t kombinieren. In DMARCbis hat t immer Vorrang. Es macht keinen Sinn, pct beizubehalten, wenn t=y vorhanden ist.

rua beim Aufräumen entfernen. Das aggregierte Reporting ist die einzige Quelle der Wahrheit über die Wirksamkeit Ihrer Richtlinie. Behalten Sie rua=mailto:reports@captaindns.com (oder Ihre dedizierte Adresse) im migrierten Eintrag bei.

Migrieren ohne bestehende Berichte zu prüfen. Bevor Sie die Richtlinie verschärfen, überprüfen Sie, welche legitimen Absender noch nicht SPF- oder DKIM-ausgerichtet sind. Eine Migration zu p=reject ohne diesen Schritt kann interne Flüsse blockieren.

psd=y deklarieren, ohne ein Registry zu sein. Der psd=y-Tag ist für Betreiber öffentlicher Suffixe wie .bank oder .gov.uk reserviert. Bei einer Standard-Organisationsdomain lassen Sie den Tag weg oder verwenden Sie psd=n, um ihn explizit zu machen.

Tool	Zweck
DMARCbis Checker	Eine veröffentlichte Domain mit DNS Tree Walk gegen DMARCbis prüfen
DMARC Checker	Veröffentlichung prüfen und den DMARC-Eintrag aus dem DNS auflösen
DMARC Validator	Syntax eines DMARC-v1-Eintrags vor der Veröffentlichung validieren
DMARC Generator	Einen DMARC- oder DMARCbis-Eintrag von Grund auf erstellen
DMARC Report Reader	Aggregierte XML-Berichte dekodieren
DMARC-Monitoring	Empfangen und analysieren Sie Ihre aggregierten DMARC-Berichte automatisch

Empfohlene Lektüre

DMARCbis: der vollständige Leitfaden zum Verständnis und zur Migration zum neuen DMARC-Standard

Referenz: draft-ietf-dmarc-dmarcbis, IETF.