DMARC-zu-DMARCbis-Migration

Leitfaden zur Migration von DMARC zu DMARCbis

Warum migrieren?

Die DMARC-zu-DMARCbis-Migration setzt keine Frist. Ihre aktuellen DMARC-Einträge funktionieren weiterhin. Ein Upgrade-Tool bietet jedoch folgende Vorteile:

• Nicht existierende Subdomains schützen mit dem np-Tag, um eine von Angreifern ausgenutzte Lücke zu schließen
• Verwaltung vereinfachen durch Entfernen von Tags, die von modernen Empfängern ignoriert werden
• Organisatorischen Geltungsbereich deklarieren mit psd=n, um die DNS-Hierarchie für Empfänger zu verdeutlichen

Migrationsschritte

1. Veraltete Tags entfernen

2. Den np-Tag hinzufügen

Wählen Sie eine Richtlinie für nicht existierende Subdomains:

• np=reject: empfohlen bei p=reject (maximaler Schutz)
• np=quarantine: Zwischenansatz
• np=none: nur Monitoring

Wenn np fehlt, gilt die sp-Richtlinie (dann die p-Richtlinie).

3. Den t-Tag bewerten

• Wenn Sie aktuell pct=0 für den Testmodus verwenden, wechseln Sie zu t=y
• Wenn Ihre Richtlinie vollständig durchgesetzt wird, ist keine Aktion erforderlich (der Standard t=n ist gleichwertig)
• Kombinieren Sie nicht pct und t: t hat immer Vorrang

4. psd deklarieren, falls relevant

• Organisatorische Domain (captaindns.com): psd=n erklärt, dass Sie kein öffentliches Suffix sind
• Registry (.bank, .gov.uk): psd=y ermöglicht die Veröffentlichung einer Richtlinie für alle Registranten
• Standard: psd=u (unbestimmt), der DNS tree walk bestimmt die organisatorische Domain

Migrationsbeispiel

Vorher:

v=DMARC1; p=reject; sp=quarantine; pct=100; ri=86400; rua=mailto:dmarc@captaindns.com

Nachher:

v=DMARC1; p=reject; sp=quarantine; np=reject; psd=n; rua=mailto:dmarc@captaindns.com

Änderungen:

• pct=100 entfernt (entspricht dem Standard t=n)
• ri=86400 entfernt (von Empfängern ignoriert)
• np=reject hinzugefügt (Schutz nicht existierender Subdomains)
• psd=n hinzugefügt (Deklaration des organisatorischen Geltungsbereichs)

Praxisnahe Migrationsbeispiele

Hier sind drei repräsentative Szenarien, die Ihnen bei der Migration Ihres DMARC-Eintrags zu DMARCbis begegnen können.

Szenario 1: Eintrag mit partiellem pct

Vorher:

v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@captaindns.com

Nachher:

v=DMARC1; p=quarantine; t=y; np=quarantine; rua=mailto:dmarc@captaindns.com

Der Wert pct=50 bedeutet, dass die Richtlinie nur auf die Hälfte aller Nachrichten angewendet wurde. In DMARCbis wird dieser granulare Ansatz durch einen binären Modus ersetzt. Der t=y-Tag aktiviert den Testmodus: DMARCbis-fähige Empfänger wenden die Richtlinie eine Stufe niedriger an (quarantine wird zu none). Der np=quarantine-Tag erbt von der p-Richtlinie, um nicht existierende Subdomains zu schützen.

Szenario 2: Strikter Eintrag ohne veraltete Tags

Vorher:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@captaindns.com

Nachher:

v=DMARC1; p=reject; sp=reject; np=reject; psd=n; rua=mailto:dmarc@captaindns.com

Dieser Eintrag ist bereits sauber: keine veralteten Tags zu entfernen. Fügen Sie einfach np=reject hinzu, um nicht existierende Subdomains abzudecken, und psd=n, um zu deklarieren, dass die Domain kein öffentliches Suffix ist. Die Migration besteht aus dem Hinzufügen von zwei Tags, ohne die bestehende Richtlinie zu ändern.

Szenario 3: Eintrag mit allen veralteten Tags

Vorher:

v=DMARC1; p=reject; pct=100; ri=86400; rf=afrf; rua=mailto:dmarc@captaindns.com

Nachher:

v=DMARC1; p=reject; np=reject; rua=mailto:dmarc@captaindns.com

Hier werden drei veraltete Tags auf einmal entfernt. pct=100 entspricht dem Standardverhalten (vollständige Durchsetzung), daher ist kein t-Tag erforderlich. ri=86400 hat die Berichtsfrequenz nie tatsächlich beeinflusst. rf=afrf war der einzig mögliche Wert, der jetzt implizit ist. Der np=reject-Tag wird für vollständigen Schutz hinzugefügt.

Was passiert während der Übergangsphase?

Die Übergangsphase zwischen DMARC und DMARCbis birgt kein Risiko für Ihre E-Mail-Zustellbarkeit. Hier ist der Grund:

• Unbekannte Tags werden ignoriert: Empfänger, die DMARCbis noch nicht unterstützen, ignorieren einfach die Tags np, t und psd. Sie wenden weiterhin p, sp und rua wie zuvor an.
• Die Version bleibt v=DMARC1: DMARCbis ändert die Versionskennung nicht. Kein Empfänger wird Ihren Eintrag wegen des Updates ablehnen.
• Der t-Tag in der Praxis: Ein DMARCbis-fähiger Empfänger wendet den Testmodus an, wenn t=y vorhanden ist. Ein DMARC-v1-Empfänger erkennt t nicht und wendet die p-Richtlinie direkt zu 100% an. Das bedeutet, dass Ihre E-Mails während der Übergangsphase vom höchsten Schutzniveau beider Standards profitieren.
• Schrittweise Einführung: Große Anbieter (Google, Microsoft, Yahoo) übernehmen neue Spezifikationen schrittweise. Die Koexistenz beider Verhaltensweisen wird voraussichtlich mehrere Jahre andauern.
• Keine dringende Aktion erforderlich: Ihre aktuellen DMARC-Einträge bleiben funktionsfähig. Die Migration kann in Ihrem eigenen Tempo erfolgen, ohne Wartungsfenster oder Dienstunterbrechung.

Empfohlene Rollout-Strategie

Um sicher zu migrieren, befolgen Sie diese vier Schritte in der angegebenen Reihenfolge:

Schritt 1: Aktuellen Eintrag prüfen. Nutzen Sie unseren DMARCbis Checker, um Ihren veröffentlichten DMARC-Eintrag zu analysieren. Das Tool identifiziert veraltete Tags und bewertet die DMARCbis-Konformität.

Schritt 2: Veraltete Tags entfernen. Löschen Sie pct, rf und ri aus Ihrem Eintrag. Diese Tags haben in DMARCbis keine Wirkung mehr und ihre Anwesenheit belastet Ihre DNS-Konfiguration unnötig.

Schritt 3: Neue Tags hinzufügen. Fügen Sie np=reject (oder die Richtlinie Ihrer Wahl) hinzu, um nicht existierende Subdomains zu schützen. Fügen Sie psd=n hinzu, um Ihren organisatorischen Geltungsbereich explizit zu deklarieren. Beide Ergänzungen stärken Ihre E-Mail-Sicherheit, ohne die Hauptrichtlinie zu ändern.

Schritt 4: Testen vor der Durchsetzung. Wenn Sie von einer lockeren Richtlinie (none oder quarantine) zu einer strikten Richtlinie (reject) wechseln, verwenden Sie t=y für einige Wochen. Überwachen Sie Ihre aggregierten DMARC-Berichte, um sicherzustellen, dass kein legitimer E-Mail-Fluss beeinträchtigt wird. Sobald die Berichte validiert sind, entfernen Sie den t-Tag (der Standard t=n setzt die Richtlinie vollständig durch).

Häufige Fehler, die Sie vermeiden sollten

Den Testmodus vergessen zu deaktivieren. Der t=y-Tag ist während der Validierungsphase nützlich, reduziert aber absichtlich das Schutzniveau. Setzen Sie sich eine Erinnerung, um nach Ihrer Testphase auf t=n umzustellen (oder den Tag zu entfernen).

np und sp verwechseln. Der sp-Tag definiert die Richtlinie für existierende Subdomains. Der np-Tag zielt ausschließlich auf nicht existierende Subdomains ab, also jene, die Angreifer erfinden, um Schutzmaßnahmen zu umgehen. Beide Tags erfüllen unterschiedliche und sich ergänzende Aufgaben.

Den rua-Tag versehentlich entfernen. Achten Sie beim Bereinigen Ihres Eintrags darauf, den rua-Tag beizubehalten, der auf Ihre Adresse für aggregierte Berichte verweist. Ohne Berichterstattung verlieren Sie jegliche Sichtbarkeit über Spoofing-Versuche und Alignment-Probleme.

psd=y deklarieren, ohne ein Registry zu sein. Der psd=y-Tag ist für Public-Suffix-Registries reserviert (wie .bank oder .gov.uk). Wenn Sie Inhaber einer gewöhnlichen organisatorischen Domain sind, verwenden Sie psd=n. Eine fehlerhafte Deklaration könnte den Empfängern ein falsches Signal senden und den DNS tree walk verkomplizieren.

Migrieren, ohne bestehende Berichte zu prüfen. Bevor Sie Ihren Eintrag ändern, analysieren Sie Ihre aktuellen aggregierten DMARC-Berichte. Sie zeigen auf, welche legitimen Absender noch nicht SPF- oder DKIM-aligniert sind. Eine Migration ohne diese Prüfung riskiert die Blockierung legitimer E-Mail-Flüsse beim Wechsel zu einer strikteren Richtlinie.

Verwandte Tools

Prüfen Sie vor der Migration die aktuelle DMARCbis-Kompatibilität Ihrer Domain mit dem DMARCbis Checker. Der Checker führt eine vollständige DNS tree walk-Analyse durch und erkennt alle veralteten Tags.

Für ein vollständiges DMARC-Audit nutzen Sie diese Tools:

• DMARC-Syntaxprüfer zur Validierung Ihrer aktuellen DMARC-Eintrag-Syntax
• DMARC-Inspektor zum Abrufen und Analysieren des auf Ihrer Domain veröffentlichten DMARC-Eintrags
• DMARC-Generator zum Erstellen eines neuen DMARC-Eintrags
• DMARC-Berichtsleser zum Dekodieren aggregierter XML-Berichte

Erfahren Sie mehr über die Protokolländerungen: DMARCbis: alle Änderungen und wie Sie sich vorbereiten.