Soll ich zu DMARCbis migrieren? Die stressfreie Checkliste

Seit der Veröffentlichung von DMARCbis im Mai 2026 kommt die Frage immer wieder auf: „Muss ich meinen DMARC-Eintrag migrieren?" Die Antwort wird dich entspannen: Es gibt keine verpflichtende Migration. DMARCbis ist abwärtskompatibel, dein aktueller Eintrag bleibt gültig, und niemand wird deine Post zurückweisen, weil sie noch von der RFC 7489 „stammt". Trotzdem lohnen sich ein paar einfache Nachbesserungen. Dieser Leitfaden gibt dir die genaue Checkliste: was zu ändern ist, was du auf keinen Fall anfassen solltest, in welcher Reihenfolge und wie du prüfst. Für den Überblick siehe DMARCbis einfach erklärt.

Zuerst die entspannende Erinnerung

DMARCbis ist kein Bruch. Konkret:

• dein 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.

Wenn du also nichts tust, bleibst du 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:

1. 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.
2. 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.
3. Die rua-Adresse prüfen. Der Berichtskanal wird nun von der RFC 9990 geregelt; nutze die Gelegenheit, um zu bestätigen, dass deine aggregierten Berichte tatsächlich ankommen und dass du sie auch auswertest.

Ein typischer DMARCbis-Eintrag sieht also so aus:

_dmarc.ton-domaine.fr.  IN TXT
  "v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s; rua=mailto:rapports@ton-domaine.fr"

Was du NICHT tun solltest

• Erstelle keinen zweiten DMARC-Eintrag. Wie zuvor: nur ein einziger _dmarc-Eintrag pro Domain. Ein zweiter macht die Policy mehrdeutig und kann ignoriert werden.
• Springe nicht zu p=reject unter dem Vorwand der „Modernisierung", wenn du noch nicht alle deine Quellen ausgerichtet hast. 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.
• Stürze dich nicht auf psd. Dieses Tag betrifft die Betreiber von Public-Suffix-Domains (Registries), nicht gewöhnliche Organisationen.

In welcher Reihenfolge migrieren

Die Reihenfolge hängt von deinem Ausgangspunkt ab.

Wenn du bereits auf p=reject mit sauberer Ausrichtung bist (der Idealfall):

1. füge np=reject hinzu;
2. entferne pct;
3. prüfe deine Berichte. Du bist fertig.

Wenn du noch auf p=none oder p=quarantine bist:

1. füge np=reject sofort hinzu (ohne Risiko, unabhängig vom Rest);
2. setze deine normale Steigerung zu p=reject fort (Inventar → Ausrichtung → quarantine mit t=y → reject);
3. entferne pct nebenbei. Die Priorität ist in diesem Fall nicht DMARCbis: Es ist, die Durchsetzung zu erreichen.

Wie du prüfst, dass alles passt

Nach jeder Änderung zwei einfache Kontrollen:

1. Lies deinen Eintrag erneut 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 gibt dir eine Note.
2. Überwache deine aggregierten Berichte einige Tage lang. Du willst sehen: die legitimen Quellen weiterhin ausgerichtet und die gefälschten nicht existierenden Subdomains nun in der Disposition reject. Lerne, sie zu lesen, 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. Wenn du noch auf p=none bist, ist die eigentliche Baustelle nicht DMARCbis, sondern die Ausrichtung deiner Quellen, die je nach Größe deines 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:rapports@ton-domaine.fr

Nachher:

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:rapports@ton-domaine.fr

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:rapports@ton-domaine.fr

Nachher (du setzt np sofort und setzt deine Steigerung zu reject fort):

v=DMARC1; p=none; np=reject; rua=mailto:rapports@ton-domaine.fr

np=reject hängt nicht von p ab: Selbst auf p=none kannst du 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:rapports@ton-domaine.fr

Eine Domain, von der du niemals versendest, 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. Wenn ein Werkzeug dich auffordert, 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. Du kannst np 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, die du besitzt, einschließlich derer, von denen du niemals versendest — 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 in deinem DNS zu bearbeiten. Wenn ein Dienstleister dein DMARC für dich verwaltet, bitte ihn einfach, 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). Prüfe, dass dein Werkzeug np richtig interpretiert; andernfalls wechsle das Werkzeug oder füge das Tag von Hand hinzu — 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. Wenn deine Authentifizierung heute funktioniert, funktioniert sie nach der Migration. Nutze trotzdem die Gelegenheit, um zu prüfen, dass deine 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, was dich beunruhigen müsste. Ein Empfänger, dessen System noch nach der alten Norm arbeitet, liest deinen 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 zu warten, bis „alle" Empfänger DMARCbis unterstützen, bevor du np hinzufügst — 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? Wenn du sie nutzt, ist die Migration ein guter Moment, um zu prüfen, dass sie noch dem entsprechen, was du willst. Das ruf-Tag (forensische Berichte) wird von immer weniger Anbietern gesendet, aus Datenschutzgründen; verlasse dich für deine Diagnose nicht darauf. Die aggregierten Berichte (rua) bleiben die zuverlässige und universelle Quelle. Diese Überprüfung gehört streng genommen nicht zur DMARCbis-Migration, aber da du den Eintrag ohnehin schon offen hast, kostet es dich nichts, im Vorbeigehen aufzuräumen.

Einen Multi-Domain-Bestand migrieren

Wenn du mehrere Domains verwaltest — das ist bei den meisten Organisationen der Fall, und sei es nur mit ihren Marken-Domains und ihren geparkten Domains — geh die Migration als eine Durchsicht an, nicht als Notfall. Die Methode:

1. Inventarisiere alle deine Domains, einschließlich derer, die du nicht mehr nutzt, aber noch besitzt. Das sind oft die am stärksten exponierten, weil niemand sie überwacht.
2. Teile sie in zwei Gruppen ein: 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).
3. Wende überall dieselben zwei Nachbesserungen an: 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.
4. Priorisiere nach Exposition: Beginne mit deinen 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, kannst du es in einem Durchgang auf deinem 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 dir anschließend, dass nichts Legitimes betroffen war.

Ein Organisationstipp: Benenne einen Verantwortlichen für die DMARC-Posture des Bestands. 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 du ohnehin schon jeden Eintrag anfasst.

Kurz gesagt

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

Lass Thomas die Migration für dich machen

Zwei DNS-Zeilen, aber keine Lust, dich zu vertun? Thomas, dein virtueller CISO, liest den tatsächlichen Zustand deiner Domain, generiert den exakten zu veröffentlichenden DMARCbis-Eintrag (np, t, ohne pct) und prüft anhand deiner Berichte, dass keine legitime Quelle betroffen ist. Du bestätigst, du fügst ein, erledigt.

Analysiere deine Domain kostenlos → oder erstelle ein Konto. Für den vollständigen Kontext siehe dieser neue Standard einfach erklärt.