Ende des pct-Tags: der Testmodus t= von DMARCbis

Wenn du DMARC schon einmal nach einem Leitfaden ausgerollt hast, bist du sicher dem Tag pct begegnet: diesem kleinen Prozentsatz, der die Policy auf einen wachsenden Anteil der Mail anwenden sollte (pct=25, dann 50, dann 100). DMARCbis (2026) entfernt es. An seiner Stelle findet man ein einfacheres und ehrlicheres Tag: t, einen binären Testmodus. Dieser Leitfaden erklärt, warum pct verschwindet, wie t=y funktioniert und vor allem, wie man DMARC im Zeitalter nach pct schrittweise ausrollt. Für die Panoramasicht von DMARCbis siehe DMARCbis einfach erklärt.

Warum pct verschwindet

Auf dem Papier war pct verlockend: p=quarantine auf 10 % der scheiternden Mail anwenden, beobachten, dann aufsteigen. In der Praxis warf das Tag mehrere Probleme auf:

• Ein unvorhersehbares Verhalten. Die Interpretation von pct variierte von einem Empfänger zum anderen. „25 %" bedeutete nicht überall dasselbe, und die Stichprobe war nicht immer repräsentativ.
• Eine falsche Sicherheit. Ein pct=10 erweckte den Eindruck zu „testen", während 90 % der scheiternden Mail weiter wie in p=none behandelt wurden — viele Teams glaubten zu härten, während sie faktisch in Beobachtung blieben.
• Eine unnötige Komplexität. Einen Prozentregler zu verwalten fügte einem bereits heiklen Rollout eine weitere Variable hinzu, ohne verlässlichen Nutzen.

Die DMARCbis-Arbeitsgruppe hat entschieden: Ein klares Signal ist besser als ein unscharfer Prozentsatz. pct wird also aus dem Standard (RFC 9989) entfernt.

Was das Tag t tut

Das neue Tag t (für test) ist binär:

• t=y — Testmodus. Du signalisierst den Empfängern: „Ich experimentiere mit dieser Policy, wende sie noch nicht strikt an; sende mir die Berichte, als wäre sie aktiv." Nützlich, um die Wirkung einer Härtung zu beobachten, bevor sie wirklich beißt.
• t=n (oder Tag abwesend) — Normalmodus. Die Policy p/sp/np gilt voll.

_dmarc.ton-domaine.fr.  IN TXT
  "v=DMARC1; p=quarantine; t=y; rua=mailto:rapports@ton-domaine.fr"

Hier erklärst du p=quarantine, aber mit t=y: Du siehst in deinen Berichten, was in Quarantäne gestellt würde, ohne dass die legitime Mail, die du vergessen hättest, wirklich in den Spam geht. Wenn die Berichte sauber sind, entfernst du t=y, und die Policy beißt richtig.

Wie man DMARC schrittweise ausrollt, ohne pct

Das Verschwinden von pct ändert die Methode des Rollouts nicht — es macht sie sogar klarer. Die Abfolge bleibt die in p=reject erreichen, ohne seine E-Mails zu zerbrechen beschriebene:

1. p=none — reine Beobachtung. Du sammelst die Berichte und inventarisierst deine Quellen.
2. Jede legitime Quelle ausrichten (SPF/DKIM), bis die Berichte sauber sind.
3. p=quarantine mit t=y — du erklärst die Quarantäne im Testmodus: Du prüfst, dass keine vergessene legitime Quelle fallen würde, ohne echtes Risiko.
4. t=y entfernen — die Quarantäne gilt wirklich.
5. p=reject (eventuell zuerst mit t=y, dann ohne) — die vollständige Anwendung.

Statt eines ungenauen Prozentreglers hast du einen klaren Schalter: Test oder real. Die Granularität kommt nicht mehr aus dem „wie viel" (dem Prozentsatz), sondern aus dem „was" (welche Policy, auf welchem Perimeter — Root, Subdomains über sp, nicht existierende über np).

Und wenn ich pct in meinem Eintrag lasse?

Nichts Schlimmes. Aktuelle DMARCbis-Implementierungen ignorieren pct einfach. Du zerbrichst nichts, indem du es lässt, aber es dient zu nichts mehr — also entferne es besser, um einen sauberen Eintrag zu behalten. Es ist einer der kleinen Handgriffe der Migration zu diesem neuen Standard, zusammen mit dem Hinzufügen von np.

Eine Nuance während des Übergangs

Wie immer bei DMARCbis aktualisiert sich das Ökosystem schrittweise. Eine Zeit lang triffst du auf:

• aktuelle Empfänger, die t verstehen und pct ignorieren;
• alte Empfänger, die t ignorieren (und die Policy also voll anwenden, selbst mit t=y).

Praktische Folge: Verlass dich nicht auf t=y als absolutes Sicherheitsnetz bei alten Empfängern — manche wenden p=quarantine wirklich an. Deshalb bleibt die wahre Sicherheit, stufenweise aufzusteigen und dabei die Berichte zu überwachen: t=y hilft dir zu beobachten, aber es ist die Sauberkeit deiner Berichte, die dir sagt, dass du bereit bist, nicht das Tag. Um diese Berichte zu lesen, siehe wie man die aggregierten Berichte liest.

Ein realer Rollout, Woche für Woche

Um die Abfolge konkret zu machen, hier wie der Aufstieg einer mittelgroßen Domain aussehen könnte, mit den Einträgen auf jeder Stufe.

Woche 1 — Beobachtung. Du veröffentlichst:

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

Du rührst nichts anderes an. Die Berichte beginnen einzutreffen; du entdeckst deine Quellen (Mail-Plattform, CRM, Rechnungsstellung, ein vergessenes Werkzeug).

Wochen 2 bis 4 — Alignment. Du konfigurierst ausgerichtetes SPF und DKIM für jede legitime Quelle, bis die Berichte sie alle auf Grün zeigen. Der Eintrag ändert sich noch nicht: Du arbeitest „unter der Haube".

Woche 5 — Quarantäne im Test. Du erklärst die Quarantäne, aber im Testmodus:

v=DMARC1; p=quarantine; t=y; rua=mailto:rapports@ton-domaine.fr

Mit t=y beobachtest du, was in den Spam gestellt würde, ohne zu riskieren, eine vergessene legitime Quelle dorthin zu schicken. Du überwachst einige Tage.

Woche 6 — reale Quarantäne. Die Berichte sind sauber? Du entfernst t=y:

v=DMARC1; p=quarantine; rua=mailto:rapports@ton-domaine.fr

Woche 7 — reject. Gleiche Logik: eventuell p=reject; t=y für einige Tage, dann entfernst du t=y und fügst np=reject hinzu, um die nicht existierenden Subdomains zu verriegeln. Du hast die Anwendung erreicht.

Dieser Zeitplan ist indikativ — eine kleine Domain geht schneller, ein großer Bestand langsamer (siehe p=reject erreichen). Der Schlüsselpunkt: Es ist der Zustand der Berichte, nicht der Zeitplan, der jeden Übergang autorisiert.

Drei Fehler, die man mit t vermeiden sollte

• t=y und pct=100 verwechseln. t=y „reduziert" die Anwendung nicht auf eine Stichprobe: Es signalisiert einen Testmodus, den nur aktuelle Empfänger respektieren. Es ist kein Ersatz für den Prozentsatz, es ist etwas anderes — ein Experimentier-Flag.
• Für immer in t=y bleiben. Der Testmodus ist eine Übergangsstufe, kein Ziel. Solange t=y da ist, wenden die aktuellen Empfänger deine Policy nicht wirklich an: Du bist nicht wirklich geschützt. Entferne es, sobald die Berichte sauber sind.
• Glauben, t=y schütze bei allen. Die alten Empfänger ignorieren t und wenden deine Policy voll an. Also kann selbst mit t=y ein p=reject bei manchen beißen. Erkläre eine strenge Policy nur, wenn du bereit bist, sie überall zu tragen.

Häufige Fragen zu t

Muss ich zwingend t=y verwenden? Nein. Es ist ein nützliches Beobachtungswerkzeug bei einer Härtung, aber du kannst p=none → quarantine → reject sehr wohl aufsteigen, indem du auf jeder Stufe einfach deine Berichte überwachst, ohne t jemals anzurühren.

Ersetzt t=y die Stufe p=none? Nein, das sind zwei verschiedene Dinge. p=none verlangt von den Empfängern keine Handlung; t=y mit p=quarantine oder p=reject sagt ihnen „hier ist mein wahres Ziel, aber ich teste noch". t=y ist nützlich nach p=none, um eine Stufe mit einem Fallschirm zu überschreiten.

Wird mein altes pct=50 ein Problem bereiten? Nein — es wird von aktuellen Implementierungen einfach ignoriert. Nutze eine Änderung des Eintrags, um es zu entfernen.

t, Zustellbarkeit und was die Empfänger wirklich tun

Eine häufige Verwechslung verdient es, aufgeklärt zu werden: t=y ist keine Zustellbarkeits-Einstellung. Es sagt den Anbietern nicht „sei netter zu meiner Mail"; es sagt „diese Policy ist im Test, wende sie noch nicht strikt an". Deine Zustellbarkeit hängt von anderen Faktoren ab — IP-Reputation, Beschwerderate, reales Alignment — nicht von der Anwesenheit von t.

Was die Empfänger mit t=y tun, variiert. Aktuelle DMARCbis-Implementierungen respektieren es: Sie senden dir die Berichte, als wäre die Policy aktiv, stellen die Mail aber nicht wirklich in Quarantäne oder Ablehnung. Die älteren Implementierungen, die t nicht kennen, ignorieren es und wenden deine Policy voll an. Praktische Folge: Während des Übergangs ist t=y ein teilweises, kein totales Sicherheitsnetz.

Der richtige Gebrauch also: t=y als Beobachtungsfenster bei einer Härtung zu nutzen, im Wissen, dass manche Empfänger die Policy bereits wirklich anwenden werden. Du überwachst deine aggregierten Berichte; sobald sie sauber sind, entfernst du t=y und die Policy beißt überall. Bleib niemals in t=y „aus Vorsicht" stecken: Das hieße zu glauben, du seist geschützt, während die aktuellen Empfänger nichts anwenden. Die Vorsicht ist die Sauberkeit der Berichte vor dem Härten — kein Test-Flag, das man unbegrenzt herumliegen lässt.

Warum ein binäres Tag ehrlicher ist als ein Prozentsatz

Es lohnt sich, einen Moment darüber nachzudenken, warum die Arbeitsgruppe einen binären Schalter einem Prozentregler vorgezogen hat — denn die Begründung sagt viel darüber aus, wofür DMARC gedacht ist. Ein Prozentsatz suggeriert eine Feinsteuerung, die es in Wahrheit nie gab. pct=25 klingt, als könntest du „ein Viertel deines Risikos" absichern, aber Risiko verteilt sich nicht gleichmäßig über den Mailstrom: Ein einziger falsch konfigurierter Dienstleister, der zufällig in die 75 % fällt, die auf die niedrigere Policy zurückfallen, macht die ganze scheinbare Vorsicht zunichte. Der Prozentsatz gab dir eine Zahl zum Festhalten, aber diese Zahl beschrieb nichts, was du tatsächlich kontrollieren konntest. Sie war eine Illusion von Steuerung.

Das binäre t=y ist ehrlicher, weil es genau das aussagt, was passiert, und nichts vortäuscht, was nicht passiert: „Diese Policy ist im Test, behandle sie noch nicht als endgültig." Es gibt keine Zwischenwerte zu deuten, keine uneinheitliche Stichprobenlogik über verschiedene Empfänger hinweg, kein falsches Gefühl abgestufter Sicherheit. Entweder testest du, oder du meinst es ernst. Die eigentliche Feinsteuerung — die es sehr wohl gibt — liegt woanders, nämlich auf der Ebene deiner Quellen und deiner Policy-Stufen: welche Quelle ausgerichtet ist, welche Ebene (Root, existierende Subdomains via sp, inexistente via np) welche Policy trägt. Das ist eine Granularität, die etwas Reales beschreibt und die du wirklich in der Hand hast, im Gegensatz zu einem Prozentsatz, dessen Verhalten von der Laune jedes einzelnen Empfängers abhing. Der Wechsel von pct zu t ist damit kein Funktionsverlust, sondern das Eingeständnis, dass die verlorene Funktion ohnehin nie richtig funktioniert hat.

Kurz gefasst

DMARCbis entfernt das Tag pct (prozentualer Rollout, als wenig verlässlich eingestuft) und ersetzt es durch t, einen binären Testmodus: t=y signalisiert „Policy im Test, wende sie noch nicht strikt an". Der Aufstieg wird nunmehr über die Beobachtung der Berichte gesteuert, nicht über den Prozentsatz. t=y ist eine Übergangsstufe, zu entfernen, sobald deine Berichte sauber sind — niemals ein Ziel.

Lass Thomas den Aufstieg steuern

Den richtigen Moment zu wählen, um t=y zu entfernen, von quarantine zu reject zu wechseln, zu prüfen, dass keine Quelle fällt: Das ist genau die Art von Entscheidung, die Thomas, dein virtueller CISO, für dich trifft, auf Basis deiner realen Daten. Er erzeugt den auf jede Stufe angepassten DMARCbis-Eintrag und sagt dir, wann die nächste Stufe sicher ist.

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