DMARC verfügt über einen eingebauten Sicherheitsmechanismus, mit dem sich die Policy schrittweise verschärfen lässt. Dieser Mechanismus heißt Staged Rollout: Die neuen Regeln werden in dieser Woche auf 25 % der fehlgeschlagenen E-Mails angewendet, nächste Woche auf 50 %, in der Woche darauf auf 100 %. Es ist die offizielle Antwort auf die Frage „Wie führe ich das ein, ohne meine legitime Mail zu zerschießen?". In unserem Datensatz für das erste Quartal 2026 wenden 94,1 % der Domains, die auf Quarantine umstellen, und 93,5 % der Domains, die auf Reject umstellen, die Policy ab Tag eins zu 100 % an. Fast niemand nutzt also den Sicherheitsmechanismus. Und wie sich herausstellt, wird der kommende DMARCbis-Standard (faktisch DMARC 2.0) ihn voraussichtlich genau aus diesem Grund entfernen.
Dieser Artikel arbeitet das Staged-Rollout-Ergebnis aus dem DMARCeye-Branchenreport für Q1 2026 auf. Den vollständigen Report mit allen 12 Diagrammen und der Methodik finden Sie weiter unten.
Der ursprüngliche DMARC-Standard (RFC 7489, 2015) enthielt pct= als Stellschraube für einen sicheren Rollout. Die Idee dahinter: Wenn ein Domain-Inhaber von p=none auf p=quarantine oder p=reject umstellt, kann er zunächst pct=10 setzen. Empfangende Server wenden die neue Policy dann auf 10 % der fehlgeschlagenen Nachrichten an und behandeln die übrigen 90 % so, als stünde die Domain weiterhin auf p=none. Sollte etwas brechen, sieht man es an einem kleinen Anteil der Mail und kann zurückrollen, bevor es ernsthaft schadet.
Der Mechanismus war darauf ausgelegt, das gefühlte Risiko des Schritts in Richtung Enforcement zu senken. Theoretisch lässt sich so eine Rampe fahren: pct=10, Reports beobachten; pct=25, beobachten; dann pct=50 und schließlich pct=100. In der Praxis macht das fast niemand.
Für jede Enforcing-Domain in unserem Datensatz (also Domains auf p=quarantine oder p=reject) haben wir geprüft, ob pct= gesetzt war und mit welchem Wert:
pct=-Tag oder pct=100). 1,8 % in der späten Rollout-Phase (50 bis 99 %). 3,0 % in der mittleren Phase (10 bis 49 %). 1,1 % in der frühen Phase (1 bis 9 %).Die 6 %, die tatsächlich einen Staged Rollout fahren, gruppieren sich überwiegend im Bereich von 10 bis 49 % (mittlere Phase). In dieser Spanne würde man Domains erwarten, die eine neue Policy an einem nennenswerten Teil der Mail testen, bevor sie aufs Ganze gehen. Die frühe Phase (1 bis 9 %) ist praktisch leer: Weniger als 1,5 % der Domains starten vorsichtig.
Die Q1-Daten zeigen das Was, nicht das Warum. Was wir bei unseren Kunden quer durch den Bestand sehen, sind die folgenden Muster, also als fundierte Vermutungen zu verstehen:
p=none auf Enforcement umstellen, haben in der Regel Wochen oder Monate damit verbracht, Aggregate Reports zu lesen und Versender zu authentifizieren. Wenn sie den Schalter umlegen, sind sie sich sicher, dass die legitime Mail aligned ist. pct würde sie nur ohne Mehrwert ausbremsen.pct=-Staging zu empfehlen. Der Standardablauf setzt auf Dokumentation zuerst: Versender kennen, die nicht authentifizierten reparieren, dann auf 100 % gehen.pct=10 bedeutet, dass 90 % der fehlgeschlagenen Mail so behandelt werden, als gelte die Policy nicht. Für manche Teams unterläuft das den Sinn: Wer halbes Enforcement wollte, hätte auf p=none bleiben können. Entweder man enforced oder eben nicht.pct= auf dieselbe Weise. Der Standard sagt: „Wende die Policy auf pct % der fehlgeschlagenen Nachrichten an." Manche Empfänger interpretieren das streng, andere nähern sich an. Der Mechanismus stützt sich auf Empfängerverhalten, das der Versender nicht prüfen kann.Die kommende DMARCbis-Revision des Standards (zum Zeitpunkt des Q1-Reports im IETF-Working-Group-Review) entfernt das pct=-Tag vollständig. Der Ersatz ist ein binäres Test-Flag t=y: Eine Domain ist entweder im Testmodus oder nicht, ohne Prozent-Stellschraube.
Die Begründung, paraphrasiert aus den Diskussionen der Working Group: pct= hat sich als Funktion erwiesen, die die meisten Betreiber nicht nutzen, die von Empfängern uneinheitlich angewendet wird und über die schwer zu argumentieren ist. Das binäre t=y-Flag passt zu den realen Deployment-Mustern. Wenn Domain-Inhaber nicht hochrampen, sollte der Standard nicht so tun, als täten sie es.
Wer geplant hat, pct= in einem zukünftigen Rollout zu nutzen: Die Q1-Daten zusammen mit der DMARCbis-Richtung sagen klar „lass es weg". Die 94 % der Enforcing-Domains, die direkt auf 100 % gegangen sind, werden sich als die richtige Wahl herausstellen. Der Standard ändert sich, um genau das abzubilden, was sie ohnehin tun.
Wenn Sie heute auf p=none stehen und über Enforcement nachdenken, sieht der praktische Pfad so aus:
p=quarantine bei 100 %. Mail, die fehlschlägt, landet im Spam, nicht in /dev/null. Beobachten Sie die Reports noch ein bis zwei Wochen. Wenn Schritt 1 sauber gemacht ist, schlägt nur Impersonation fehl.p=reject bei 100 %. Fehlgeschlagene Mail wird direkt abgewiesen. Der Wechsel von Quarantine zu Reject ist unsichtbar, wenn Sie sauber authentifiziert haben.Monitoring und Report-Analyse zeigen Ihnen exakt, was authentifiziert ist und was nicht. Sobald Sie das wissen, brauchen Sie keine Prozent-Stellschraube.
Wenn Sie nicht wissen, was Ihre Domain aktuell veröffentlicht, finden Sie es am schnellsten unten heraus. Geben Sie Ihre Domain ein, um Ihren DMARC-Eintrag zu sehen (sowie SPF und DKIM, sofern veröffentlicht).
Die Q1-2026-Zahlen sagen, dass fast niemand DMARC-Enforcement schrittweise hochfährt. Die DMARCbis-Revision sagt, dass diese Domains damit richtig liegen. Der „Sicherheitsmechanismus", der pct= sein sollte, hat sich als Stellschraube entpuppt, die die meisten Betreiber ignoriert haben, auch deshalb, weil der richtige Weg zum Enforcement schlicht keine Prozent-Stellschraube braucht. Dokumentieren Sie Ihre Versender. Authentifizieren Sie sie. Legen Sie den Schalter um.