Ist eine Migration zu DMARCbis nötig? Die stressfreie Checkliste

Von Thomas · virtueller CISO · 2026-07-02

Seit der Veröffentlichung von DMARCbis im Mai 2026 kommt die Frage immer wieder auf: „Muss ich meinen DMARC-Eintrag migrieren?" Die Antwort ist entspannend: Es gibt keine verpflichtende Migration. DMARCbis ist abwärtskompatibel, der aktuelle Eintrag bleibt gültig, und niemand weist Post zurück, weil sie noch von der RFC 7489 „stammt". Trotzdem lohnen sich ein paar einfache Nachbesserungen. Dieser Leitfaden liefert die genaue Checkliste: was zu ändern ist, was auf keinen Fall anzufassen ist, in welcher Reihenfolge und wie sich das Ergebnis prüfen lässt. Für den Überblick siehe DMARCbis einfach erklärt.

Zuerst die entspannende Erinnerung

DMARCbis ist kein Bruch. Konkret:

der Eintrag beginnt weiterhin mit v=DMARC1 (kein v=DMARC2);
die Tags p, sp, rua, ruf, adkim, aspf, fo behalten die gleiche Bedeutung;
das Prinzip der Ausrichtung ist unverändert;
ein Empfänger, der noch nicht aktualisiert ist, ignoriert einfach die Neuerungen, die er nicht kennt.

Wer also nichts tut, bleibt genauso geschützt wie zuvor. Die „Migration" ist nur eine Optimierung, kein Notfall.

Was zu ändern ist (3 kleine Handgriffe)

Drei Nachbesserungen, alle einfach und ohne Risiko:

np=reject hinzufügen. Das ist der wichtigste Gewinn: Es sperrt die nicht existierenden Subdomains, eine Lücke, die sp nicht abdeckte. Kein Risiko, da nichts Legitimes von einer nicht existierenden Subdomain versendet. Details: das np-Tag.
pct entfernen, falls es noch herumliegt. Das Tag wird von DMARCbis abgeschafft; aktuelle Implementierungen ignorieren es. Die Steigerung der Policy erfolgt nun mit dem Testmodus t=y — siehe Ende von pct, Platz für t.
Die rua-Adresse prüfen. Der Berichtskanal wird nun von der RFC 9990 geregelt; eine gute Gelegenheit zu bestätigen, dass die aggregierten Berichte tatsächlich ankommen und auch ausgewertet werden.

Ein typischer DMARCbis-Eintrag sieht also so aus:

_dmarc.beispiel.de.  IN TXT
  "v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s; rua=mailto:berichte@beispiel.de"

Was NICHT zu tun ist

Keinen zweiten DMARC-Eintrag erstellen. Wie zuvor: nur ein einziger _dmarc-Eintrag pro Domain. Ein zweiter macht die Policy mehrdeutig und kann ignoriert werden.
Nicht zu p=reject springen unter dem Vorwand der „Modernisierung", solange nicht alle Quellen ausgerichtet sind. DMARCbis ändert nichts an dieser goldenen Regel: Verschärfen auf einem unvollständigen Inventar zerstört legitime Post. Die Reihenfolge bleibt die von p=reject erreichen.
Sich nicht auf psd stürzen. Dieses Tag betrifft die Betreiber von Public-Suffix-Domains (Registries), nicht gewöhnliche Organisationen.

In welcher Reihenfolge migrieren

Die Reihenfolge hängt vom Ausgangspunkt ab.

Bei einer Domain schon auf p=reject mit sauberer Ausrichtung (der Idealfall):

np=reject hinzufügen;
pct entfernen;
die Berichte prüfen. Fertig.

Bei einer Domain noch auf p=none oder p=quarantine:

np=reject sofort hinzufügen (ohne Risiko, unabhängig vom Rest);
die normale Steigerung zu p=reject fortsetzen (Inventar → Ausrichtung → quarantine mit t=y → reject);
pct nebenbei entfernen. Die Priorität ist in diesem Fall nicht DMARCbis: Es ist, die Durchsetzung zu erreichen.

Wie sich prüfen lässt, dass alles passt

Nach jeder Änderung zwei einfache Kontrollen:

Den Eintrag erneut lesen mit einem Analysator, um die Syntax und das Vorhandensein der erwarteten Tags (np, Fehlen von pct) zu bestätigen — unser kostenloser Analysator macht das in wenigen Sekunden und vergibt eine Note.
Die aggregierten Berichte überwachen, einige Tage lang. Zu sehen sein sollen: die legitimen Quellen weiterhin ausgerichtet und die gefälschten nicht existierenden Subdomains nun in der Disposition reject. Wie sie sich lesen lassen, steht in wie man die aggregierten Berichte liest.

Wie lange dauert das?

Für eine bereits gut gepflegte Domain läuft die DMARCbis-„Migration" auf zwei DNS-Nachbesserungen hinaus — ein paar Minuten, plus die Propagierungszeit. Steht die Domain noch auf p=none, ist die eigentliche Baustelle nicht DMARCbis, sondern die Ausrichtung der Quellen, die je nach Größe des Versandbestands von einigen Tagen bis zu einigen Monaten dauern kann (siehe p=reject erreichen, ohne seine E-Mails zu zerstören).

Drei konkrete Fälle, vorher/nachher

Je nach Ausgangspunkt nimmt die „Migration" eine andere Form an. Hier sind drei reale Einträge, vorher und nachher.

Fall 1 — bereits geschützte Domain. Vorher:

v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:berichte@beispiel.de

Nachher:

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:berichte@beispiel.de

Wir entfernen pct=100 (unnötig) und fügen np=reject hinzu. Zwei Sekunden Arbeit.

Fall 2 — Domain in Überwachung. Vorher:

v=DMARC1; p=none; rua=mailto:berichte@beispiel.de

Nachher (np wird sofort gesetzt, die Steigerung zu reject läuft weiter):

v=DMARC1; p=none; np=reject; rua=mailto:berichte@beispiel.de

np=reject hängt nicht von p ab: Selbst auf p=none lassen sich die nicht existierenden Subdomains ohne Risiko sperren.

Fall 3 — geparkte Domain (kein Versand). Vorher: oft überhaupt nichts. Nachher:

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:berichte@beispiel.de

Eine Domain, von der niemals versandt wird, muss alles ablehnen. Das ist die strengste Konfiguration und die am einfachsten zu rechtfertigende.

Drei falsche Vorstellungen über die Migration

„Man muss auf v=DMARC2 umsteigen." Falsch. Die Kennung bleibt v=DMARC1. Fordert ein Werkzeug dazu auf, v=DMARC2 zu setzen, ist das ein Alarmsignal.
„Mein alter Eintrag wird abgelehnt." Falsch. Ein 7489-Eintrag bleibt ein gültiger DMARCbis-Eintrag. Nichts „verfällt".
„Ich muss alles am selben Tag migrieren." Falsch. Es gibt keine Frist. np lässt sich heute hinzufügen, pct nächsten Monat entfernen — oder eine bereits gesunde Domain nie anfassen. DMARCbis erlegt keinen Zeitplan auf.

Häufige Fragen zur Migration

Wie viele Domains muss ich behandeln? Alle im eigenen Besitz, einschließlich derer, von denen niemals versandt wird — das sind gerade die am häufigsten gefälschten. Ein Multi-Domain-Bestand verdient eine Durchsicht; das Prinzip (np hinzufügen, pct entfernen) ist überall dasselbe.

Muss ich meinen Hoster oder meinen E-Mail-Dienstleister informieren? Nein. Die Migration läuft darauf hinaus, einen TXT-Eintrag im eigenen DNS zu bearbeiten. Verwaltet ein Dienstleister das DMARC, genügt die Bitte, np hinzuzufügen und pct zu entfernen.

Und wenn ich einen DMARC-Monitoring-Dienst nutze? Die meisten aktualisieren sich, um DMARCbis widerzuspiegeln (Auftauchen von np, Verschwinden von pct in den Berichten). Zu prüfen ist, ob das Werkzeug np richtig interpretiert; andernfalls hilft ein Werkzeugwechsel oder das Tag von Hand — es bleibt in jedem Fall gültig.

Muss ich meine DKIM-Schlüssel oder mein SPF neu machen? Nein, DMARCbis rührt weder SPF noch DKIM an. Was heute funktioniert, funktioniert nach der Migration weiter. Die Gelegenheit lohnt trotzdem, um zu prüfen, dass die DKIM-Schlüssel am richtigen Ort gespeichert sind, nicht in einer herumliegenden Datei.

Was ändert sich für die Empfänger, die DMARCbis noch nicht umgesetzt haben? Nichts Beunruhigendes. Ein Empfänger, dessen System noch nach der alten Norm arbeitet, liest den Eintrag, erkennt das ihm bekannte v=DMARC1 und wendet die Tags an, die er versteht. Die Neuerungen, die er nicht kennt — typischerweise np —, ignoriert er schlicht, ohne den restlichen Eintrag zu verwerfen. Genau das meint „abwärtskompatibel": Die Migration nützt bei den aktualisierten Empfängern und schadet bei den anderen nicht. Es gibt also keinen Grund, mit np zu warten, bis „alle" Empfänger DMARCbis unterstützen — der Gewinn ist sofort dort, wo er zählt, und die Kosten sind anderswo null.

Sollte ich bei dieser Gelegenheit auch fo oder ruf überprüfen? Sind sie im Einsatz, ist die Migration ein guter Moment zu prüfen, ob sie noch dem gewünschten Verhalten entsprechen. Das ruf-Tag (forensische Berichte) wird von immer weniger Anbietern gesendet, aus Datenschutzgründen; als alleinige Diagnosegrundlage taugt es nicht. Die aggregierten Berichte (rua) bleiben die zuverlässige und universelle Quelle. Diese Überprüfung gehört streng genommen nicht zur DMARCbis-Migration, aber da der Eintrag ohnehin schon offen ist, kostet das Aufräumen im Vorbeigehen nichts.

Einen Multi-Domain-Bestand migrieren

Werden mehrere Domains verwaltet — das ist bei den meisten Organisationen der Fall, und sei es nur mit ihren Marken-Domains und ihren geparkten Domains —, ist die Migration eine Durchsicht, kein Notfall. Die Methode:

Alle Domains inventarisieren, einschließlich derer, die nicht mehr genutzt, aber noch gehalten werden. Das sind oft die am stärksten exponierten, weil niemand sie überwacht.
In zwei Gruppen einteilen: die, die Post versenden (sorgfältig zu behandeln, Ausrichtung inbegriffen), und die, die keine versenden (geparkte Domains, direkt auf p=reject; sp=reject; np=reject zu setzen).
Überall dieselben zwei Nachbesserungen anwenden: np hinzufügen, pct entfernen. Für die geparkten Domains ist es die Gelegenheit, einen ersten strengen Eintrag zu veröffentlichen, falls es keinen gab.
Nach Exposition priorisieren: zuerst die Marken-Domains für Privatkunden, die am ehesten gefälscht werden, vor den internen oder technischen Domains.

Der Vorteil einer gruppierten Behandlung ist die Konsistenz: Ein Bestand, in dem jede Domain dieselbe strenge Policy anwendet, lässt kein schwaches Glied. Und da np=reject ohne Risiko ist, lässt es sich in einem Durchgang auf dem gesamten Bestand ausrollen, ohne zu befürchten, irgendetwas zu zerstören — keine dieser Domains versendet von einer nicht existierenden Subdomain. Die aggregierten Berichte jeder Domain bestätigen anschließend, dass nichts Legitimes betroffen war.

Ein Organisationstipp: einen Verantwortlichen für die DMARC-Posture des Bestands benennen. Domains driften — ein neuer Dienstleister hier, eine vergessene Kampagnen-Subdomain dort — und ohne jemanden zur Überwachung regrediert ein einst sauberer Bestand still und leise. Die Migration zu DMARCbis ist ein guter Zeitpunkt, um diese Verantwortung einzurichten, da ohnehin jeder Eintrag angefasst wird.

Kurz gesagt

Es gibt keine verpflichtende Migration: DMARCbis ist abwärtskompatibel und der v=DMARC1-Eintrag bleibt gültig. Die einzigen zwei nützlichen Nachbesserungen sind, np=reject hinzuzufügen und pct zu entfernen. Steht die Domain noch auf p=none, bleibt die eigentliche Priorität, p=reject mit der gewohnten Methode zu erreichen. Und vor allem: kein v=DMARC2, das existiert nicht.

Thomas übernimmt die Migration

Zwei DNS-Zeilen — und trotzdem der Wunsch, sich nicht zu vertun. Thomas, der virtuelle CISO, liest den tatsächlichen Zustand der Domain, generiert den exakten zu veröffentlichenden DMARCbis-Eintrag (np, t, ohne pct) und prüft anhand der Berichte, dass keine legitime Quelle betroffen ist. Bestätigen, einfügen, erledigt.

Kostenlose DMARC-Analyse einer Domain oder ein Konto erstellen. Für den vollständigen Kontext siehe dieser neue Standard einfach erklärt.

DMARC anwenden — konkret

Thomas, der virtuelle CISO von DMARC.com, identifiziert jede legitime Versandquelle, schreibt die exakten DNS-Einträge und bringt eine Domain sicher von p=none zu p=reject — ohne den Mailverkehr zu stören.

Zu p=reject — kostenlos