DMARC schrittweise ausrollen, nach dem Ende von pct

Von Thomas · virtueller CISO · 2026-07-21

Jahrelang hatte „DMARC schrittweise ausrollen" eine präzise, technische Bedeutung: Man veröffentlichte p=quarantine; pct=25, sah sich die Berichte an, stieg dann auf pct=50, pct=75, pct=100, bevor man auf reject wechselte und die Skala wiederholte. Das Tag pct wandte die Policy auf einen wachsenden Anteil der scheiternden Mail an — eine beruhigende Sicherheitsstufe. Nur hat DMARCbis (2026) pct entfernt. Die Frage stellt sich also von Neuem: Wie härtet man ohne Prozentsatz, ohne alles auf einmal zu zerbrechen?

Die kurze Antwort: Der schrittweise Rollout beruht nicht mehr auf einem Prozentsatz der Mail, sondern auf einer Abfolge von Policies und auf der realen Granularität, die schon immer die Versandquellen waren. Dieser Leitfaden beschreibt das Ersatzmodell, die Rolle des neuen Testmodus (t=y) und den Überwachungstakt, der das Ganze sicher macht.

Warum `pct` verschwunden ist

pct versprach mehr, als es hielt. Eine Policy auf „25 % der scheiternden Mail" anzuwenden setzte voraus, dass die Empfänger die Auswahl einheitlich implementieren — was nie der Fall war. Schlimmer noch, die Logik war kontraintuitiv: pct=25 bei reject bedeutete, dass 75 % der scheiternden Mail auf die niedrigere Policy (quarantine) zurückfiel, ein Verhalten, das nur wenige Administratoren korrekt antizipierten. DMARCbis hat entschieden: Das Tag wird zugunsten eines binären Testmodus entfernt, der ehrlicher ist. Das Detail dieser Änderung steht in das Ende von pct und der Testmodus t= von DMARCbis.

Das neue Modell: Policy-Stufen, keine Prozentsätze

Ohne pct lebt die Schrittweisheit vollständig in der Abfolge der Policies und in der an jeder Stufe verbrachten Zeit:

p=none — Beobachtung. Nichts wird blockiert; die Berichte laufen ein und das Quelleninventar entsteht.
p=quarantine — erste Anwendung. Die scheiternde Mail geht in den Spam. Kurze Stufe, überwacht, in ihren Auswirkungen reversibel.
p=reject — maximale Anwendung. Die gefälschte Mail wird abgewiesen.

Die Schrittweisheit ist also nicht mehr „welcher Prozentsatz", sondern „wie lange beobachte ich zwischen jeder Stufe, und unter welcher Bedingung steige ich auf". Es ist ein einfacheres und in der Praxis sichereres Modell: Nicht mehr eine schlecht implementierte Zufallsauswahl entscheidet, sondern die eigenen Daten.

Die wahre Granularität waren schon immer die Quellen

Hier der Punkt, den pct verschleierte: Man härtet nie wirklich „25 % eines Flusses". Man macht Quellen konform, eine nach der anderen. Der eigentliche schrittweise Rollout besteht darin, das Inventar zu durchlaufen — Marketing-Plattform, CRM, Rechnungsstellung, Support — und jede auszurichten (DKIM-Signatur auf die eigene Marke, d=beispiel.de), bis die Berichte für alle ein ausgerichtetes Durchkommen zeigen.

Solange legitime Quellen scheitern, bleibt die Domain in none (oder in quarantine, wenn das Risiko akzeptabel ist); sobald sie alle ausgerichtet sind, lässt sich ohne False Positive härten. Das ist der wahre Regler der Schrittweisheit — weit feiner als ein Prozentsatz, weil er an der Ursache ansetzt (eine nicht ausgerichtete Quelle) und nicht an einem Symptom (ein scheiterndes Volumen). Die Methode der Quelle-für-Quelle-Ausrichtung ist detailliert in p=reject erreichen, ohne seine E-Mails zu zerbrechen.

Der Testmodus `t=y`: der ehrliche Ersatz für `pct`

DMARCbis führt das Tag t ein (für testing). Mit veröffentlichtem t=y erfahren die Empfänger, dass die Policy im Test ist: Sie wenden die geforderte Policy an, wissen aber, dass sie noch nicht endgültig ist, was sie zu mehr Nachsicht anhält und die Beobachtung der Auswirkungen ohne brutale Folgen erlaubt. Das ist das wahre moderne Äquivalent eines vorsichtigen Rollouts: nicht mehr „wende auf 25 % an", sondern „hier ist meine Ziel-Policy, behandle sie als Test, bis ich bestätige".

Konkret verwendet man t=y während des Fensters, in dem die Policy hochgeschraubt wird und ein Fallschirm erwünscht ist. Sobald die Berichte sauber sind und das Vertrauen hergestellt ist, fällt t=y weg (oder wechselt auf t=n), um die Policy voll wirksam zu machen. Die genaue Funktionsweise des Tags ist erklärt in das t-Tag von DMARCbis.

Der Überwachungstakt zwischen den Stufen

Ein schrittweiser Rollout ohne Überwachung ist nicht schrittweise, er ist nur langsam. Jede Policy-Änderung verlangt einen expliziten Takt:

Tag 1: Prüfen, dass nichts sofort gebrochen ist — keine große legitime Quelle kippt ins Scheitern.
Tag 3: Die ersten aggregierten Berichte der neuen Stufe kommen an (sie sind täglich, mit Verzögerung). Das Alignment Quelle für Quelle kontrollieren.
Tag 7: Eine volle Woche erfasst die wöchentlichen Schwankungen (Montagskampagnen, Kontoauszüge). Ist alles sauber, lässt sich die nächste Stufe erwägen.

Dieser Takt verwandelt „wir haben DMARC gehärtet" von einer optimistischen Wette in eine kontrollierte Änderung, reversibel beim kleinsten Alarm. Diesen Kontrollpunkten gehört ein Verantwortlicher zugewiesen; ein schrittweiser Rollout, den niemand betrachtet, ist nur dem Namen nach schrittweise.

Wie lange pro Stufe?

Es gibt keine universelle Dauer, aber ein Prinzip: Jede Stufe dauert so lange, wie nötig ist, um den vollständigen Versandzyklus zu erfassen. Gehen monatliche Kontoauszüge raus, wird sie ein Fenster von wenigen Tagen nicht sehen — es braucht mindestens einen beobachteten Abrechnungszyklus, bevor sich schließen lässt, dass „alles sauber ist". Für einen einfachen, täglichen Fluss reichen wenige Tage in quarantine vor reject. Für ein komplexes Ökosystem sind mehrere Wochen zu veranschlagen. Die Frage der Gesamtdauer wird separat im Zeitplan des Policy-Aufstiegs behandelt.

Die Subdomains: eine Stufe, die man nicht vergessen darf

Der schrittweise Rollout betrifft nicht nur die Root-Domain. Die Subdomains erben p standardmäßig, aber sp gehört explizit gesteuert und vor allem die nicht existierenden Subdomains mit np verriegelt. Gute Nachricht: np=reject ist ein sofortiger und risikoloser Gewinn, früh im Rollout zu setzen — keine legitime Mail geht von einer Subdomain aus, die nicht existiert, also nichts zu beobachten, bevor man härtet. Details in die Subdomain-Policy (sp und np).

Zurückgehen können

Ein guter schrittweiser Rollout enthält einen Rückfallplan. Enthüllt eine Stufe eine übersehene legitime Quelle, deren Nachrichten blockiert werden, geht es eine Stufe runter (zum Beispiel von reject auf quarantine, oder durch Reaktivierung von t=y), die Quelle wird ausgerichtet, und dann geht es wieder hoch. Zurückgehen ist kein Scheitern: Es ist genau das, was die Schrittweisheit ermöglichen soll. Der Fehler wäre, in reject zu bleiben und zu hoffen, dass sich das Problem von selbst löst, während legitime E-Mails verschwinden.

Häufige Fallstricke

Sich weiter auf pct verlassen. Manche Werkzeuge akzeptieren es aus Rückwärtskompatibilität, andere ignorieren es. Darauf lässt sich kein Rollout bauen: DMARCbis hat es entfernt, und sein Verhalten war ohnehin uneinheitlich.
Stufen überspringen. Direkt von none auf reject zu wechseln ohne Fenster in quarantine funktioniert nur dann, wenn die Berichte seit Wochen tadellos sind. Im Zweifel bleibt die Schleuse.
Härten ohne Überwachung. Eine Policy-Änderung ohne Kontrolltakt ist eine Wette, kein Rollout.
Vergessen, t=y zu entfernen. Der Testmodus ist eine Phase, kein Ziel: Bleibt er stehen, schwächt er die Ziel-Policy.

Ein typischer Zeitplan, vom ersten Tag bis `reject`

Um all das konkret zu machen, hier wie ein gelassener Ablauf für eine mittelgroße Domain ohne besondere Dringlichkeit aussieht:

Wochen 1 bis 3 — p=none. Der Eintrag wird mit einer rua-Adresse veröffentlicht, np=reject von Anfang an gesetzt, und die Berichte strömen ein. Nichts wird blockiert. Es entsteht das Inventar der Quellen, und die offensichtlichsten werden ausgerichtet.
Wochen 4 bis 6 — Alignment. Der Großteil der kalendarischen Arbeit. Das Inventar wird Quelle für Quelle durchlaufen, auf jeder Plattform kommt eine DKIM-Signatur auf die eigene Marke hinzu, und die Berichte bestätigen, dass jede ausgerichtet durchkommt. Die Domain bleibt in none, solange eine große Quelle noch scheitert.
Woche 7 — p=quarantine; t=y. Erste Anwendungsstufe, im Testmodus. Überwacht wird nach dem Takt Tag 1 / 3 / 7. Der Testmodus signalisiert den Empfängern eine noch ausstehende Bestätigung und lässt einen Fallschirm.
Woche 8 — p=quarantine. t=y fällt weg. Die Quarantäne-Policy ist voll wirksam. Eine Woche Beobachtung, um einen vollständigen Wochenzyklus zu erfassen.
Woche 9 — p=reject. Die Berichte sind seit mehreren Wochen sauber, die einzigen scheiternden Quellen sind unbekannt (also Fälscher). Jetzt wird gehärtet. Die Berichte bleiben weiterhin unter Beobachtung, denn das Auftauchen einer neuen, nicht ausgerichteten Quelle kann immer vorkommen.

Dieser Zeitplan ist keine Regel — ein einfacher Fluss geht doppelt so schnell, ein komplexes Ökosystem doppelt so langsam. Es ist eine Schablone: Jede Stufe wird auf Beweis genommen, nicht auf die Uhr. Die Dauern richten sich nach dem realen Versandzyklus, niemals umgekehrt.

Wer sollte den Rollout überwachen, und wie man ihn dokumentiert

Ein oft übersehener Aspekt des schrittweisen Rollouts ist die menschliche und organisatorische Seite. Ein technisch einwandfreier Plan scheitert, wenn niemand namentlich für die Kontrollpunkte verantwortlich ist. In der Praxis gehört zu jeder Stufe ein benannter Verantwortlicher — nicht „das Team", sondern eine konkrete Person — und ein einfacher Kalender, der festhält, wann jede Policy-Änderung stattgefunden hat und wer sie freigegeben hat. Diese Dokumentation ist keine bürokratische Übung: Sie erlaubt es, im Fall eines Zwischenfalls sofort zu wissen, welche Änderung wann wirksam wurde, und sie liefert bei einem Audit den Nachweis, dass die Härtung kontrolliert und nicht blind erfolgte.

Ein leichtgewichtiges Format genügt vollkommen: ein Datum, die veröffentlichte Policy (p=none, p=quarantine; t=y, usw.), der Zustand der Berichte zum Zeitpunkt der Freigabe der nächsten Stufe und der Name des Verantwortlichen. Musste eine Stufe zurückgenommen werden, weil eine übersehene legitime Quelle auftauchte, gehört auch das festgehalten — es zeigt, dass der Rückfallplan funktioniert hat, und es hilft, beim nächsten Mal die Quelle früher zu inventarisieren. Für Organisationen unter regulatorischem Druck (NIS2, DORA, ISO 27001) verwandelt diese schlichte Chronik den Rollout von einer Reihe undokumentierter DNS-Änderungen in einen nachvollziehbaren, opposablen Prozess. Und selbst ohne regulatorischen Zwang ist sie schlicht gute Hygiene: Sie zwingt zu einer bewussten Freigabe jeder Stufe, statt aus Gewohnheit oder Zeitdruck zu überspringen — was, wie wir gesehen haben, der häufigste Weg ist, einen legitimen Fluss versehentlich zu blockieren.

Zusammengefasst

Das Verschwinden von pct hat den DMARC-Rollout nicht riskanter gemacht — es hat ihn ehrlicher gemacht. Die reale Schrittweisheit beruhte schon immer auf dem Alignment der Quellen und auf der Beobachtungszeit zwischen den Stufen, nicht auf einem Prozentsatz, den die Empfänger uneinheitlich anwandten. Das Trio none → quarantine → reject, getaktet durch eine ernsthafte Überwachung und abgesichert durch den Testmodus t=y, bleibt die richtige Methode.

Um den eigenen Stand zu verorten und das reale Alignment jeder Quelle zu prüfen, bevor eine Stufe ansteht, gehört die Domain in den kostenlosen DMARC-Analyzer; er sagt aus Sicht der Empfänger, ob sich härten lässt, ohne irgendetwas zu zerbrechen.

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