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

_dmarc.beispiel.de.  IN TXT
  "v=DMARC1; p=quarantine; t=y; rua=mailto:berichte@beispiel.de"

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. Die Berichte werden gesammelt, die Quellen inventarisiert.
2. Jede legitime Quelle ausrichten (SPF/DKIM), bis die Berichte sauber sind.
3. p=quarantine mit t=y — die Quarantäne wird im Testmodus erklärt: Die Kontrolle, dass keine vergessene legitime Quelle fallen würde, läuft 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 steht ein klarer Schalter bereit: 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 pct im Eintrag bleibt?

Nichts Schlimmes. Aktuelle DMARCbis-Implementierungen ignorieren pct einfach. Es stehen zu lassen zerbricht nichts, aber es dient zu nichts mehr — also besser entfernen, 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 koexistieren:

• 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: t=y ist bei alten Empfängern kein absolutes Sicherheitsnetz — manche wenden p=quarantine wirklich an. Deshalb bleibt die wahre Sicherheit, stufenweise aufzusteigen und dabei die Berichte zu überwachen: t=y hilft beim Beobachten, aber es ist die Sauberkeit der Berichte, die die Bereitschaft signalisiert, 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. Veröffentlicht wird:

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

Sonst wird nichts angerührt. Die Berichte beginnen einzutreffen; die Quellen treten zutage (Mail-Plattform, CRM, Rechnungsstellung, ein vergessenes Werkzeug).

Wochen 2 bis 4 — Alignment. Für jede legitime Quelle werden ausgerichtetes SPF und DKIM konfiguriert, bis die Berichte sie alle auf Grün zeigen. Der Eintrag ändert sich noch nicht: Die Arbeit läuft „unter der Haube".

Woche 5 — Quarantäne im Test. Die Quarantäne wird erklärt, aber im Testmodus:

v=DMARC1; p=quarantine; t=y; rua=mailto:berichte@beispiel.de

Mit t=y wird beobachtbar, was in den Spam gestellt würde, ohne zu riskieren, eine vergessene legitime Quelle dorthin zu schicken. Einige Tage Überwachung folgen.

Woche 6 — reale Quarantäne. Die Berichte sind sauber? Dann fällt t=y weg:

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

Woche 7 — reject. Gleiche Logik: eventuell p=reject; t=y für einige Tage, dann fällt t=y weg und np=reject kommt hinzu, um die nicht existierenden Subdomains zu verriegeln. Die Anwendung ist 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 die Policy nicht wirklich an: Es besteht kein echter Schutz. Zu entfernen, sobald die Berichte sauber sind.
• Glauben, t=y schütze bei allen. Die alten Empfänger ignorieren t und wenden die Policy voll an. Also kann selbst mit t=y ein p=reject bei manchen beißen. Eine strenge Policy ist nur zu erklären, wenn die Bereitschaft besteht, 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 der Aufstieg p=none → quarantine → reject gelingt sehr wohl auch dadurch, dass auf jeder Stufe einfach die Berichte überwacht werden, 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. Die nächste Änderung des Eintrags ist die Gelegenheit, 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 bittet die Anbieter nicht um Nachsicht mit der Mail; es sagt „diese Policy ist im Test, noch nicht strikt anzuwenden". Die 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 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 die 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. Man überwacht die aggregierten Berichte; sobald sie sauber sind, fällt t=y weg und die Policy beißt überall. Niemals „aus Vorsicht" in t=y stecken bleiben: Das hieße sich geschützt zu glauben, 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 ließe sich „ein Viertel des 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 eine Zahl zum Festhalten, aber diese Zahl beschrieb nichts, was tatsächlich kontrollierbar war. 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, noch nicht als endgültig zu behandeln." Es gibt keine Zwischenwerte zu deuten, keine uneinheitliche Stichprobenlogik über verschiedene Empfänger hinweg, kein falsches Gefühl abgestufter Sicherheit. Entweder es wird getestet, oder es ist ernst gemeint. Die eigentliche Feinsteuerung — die es sehr wohl gibt — liegt woanders, nämlich auf der Ebene der Quellen und der 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 dem Betreiber wirklich in der Hand liegt, 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, noch nicht strikt anzuwenden". Der Aufstieg wird nunmehr über die Beobachtung der Berichte gesteuert, nicht über den Prozentsatz. t=y ist eine Übergangsstufe, zu entfernen, sobald die Berichte sauber sind — niemals ein Ziel.

Thomas steuert den Aufstieg

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, der virtuelle CISO, übernimmt, auf Basis der realen Daten. Er erzeugt den auf jede Stufe angepassten DMARCbis-Eintrag und meldet, wann die nächste Stufe sicher ist.

Eine Domain kostenlos analysieren oder ein Konto erstellen. Für den vollständigen Kontext siehe diesen neuen Standard einfach erklärt.