Eignungs-Checkliste: Ist eine Domain bereit für p=reject?

Von Thomas · virtueller CISO · 2026-07-19

Es gibt zwei Arten, den Wechsel zu p=reject zu vermasseln. Die erste ist, ihn nie zu versuchen: Der Eintrag bleibt jahrelang auf p=none, die Überwachung schützt niemanden, und die Betrüger schreiben weiter im Namen der Domain. Die zweite ist, ihn zu früh zu versuchen: Die Policy wird verschärft, bevor alle Quellen ausgerichtet sind, und die eigenen Rechnungen, Erinnerungen und Passwort-Resets landen im Spam. Zwischen beiden liegt ein messbarer Zustand — „bereit" — und dieser Artikel liefert dafür die Checkliste.

Das ist nicht die Schritt-für-Schritt-Erzählung der Policy-Verschärfung; das ist p=reject erreichen, ohne die E-Mails zu zerstören, das die Sequenz none → quarantine → reject durchläuft. Hier beantworten wir eine vorgelagerte und nüchternere Frage: Bevor das p-Tag angefasst wird, welche Kästchen müssen abhakbar sein? Diese Liste ist wie ein Vorflug-Check zu behandeln. Bleibt auch nur ein Kästchen leer, ist die Domain nicht bereit — und den Wechsel zu erzwingen, kostet verlorene legitime Post.

1. Alle Versandquellen sind inventarisiert

Das ist das Kästchen, das alles andere scheitern lässt, wenn man es schludert. Die meisten Organisationen versenden von viel mehr Orten aus, als sie denken: die Marketing-Plattform, das CRM, das Rechnungstool, der Support, die HR-Lösung, das Ticketing und diese kleine App, die ein Team vor zwei Jahren angeschlossen hat, ohne die IT zu informieren. Jede vergessene Quelle ist eine legitime E-Mail, die abgewiesen wird, sobald reject greift.

Das Inventar entsteht nicht aus dem Gedächtnis — es liest sich aus den aggregierten DMARC-Berichten. Jede IP, die in den RUA-Berichten auftaucht, ist eine Quelle, die es zu identifizieren und einzuordnen gilt: „Diese ist unsere E-Mail-Plattform, jene das CRM, diese dritte ein Umfrage-Tool, an das sich niemand erinnerte." Dieses Kästchen wird erst abgehakt, wenn sich jeder IP mit nennenswertem Volumen ein Dienstname zuordnen lässt. Mit Überraschungen ist zu rechnen; es gibt immer welche. Dieses Inventar gehört als lebendiges Dokument geführt — eine einfache Tabelle mit Quelle / Verwendung / verantwortlichem Team / Ausrichtungsmethode — statt als einmalige Übung: An dem Tag, an dem jemand fragt „Können wir endlich auf reject wechseln?", macht diese Tabelle den Unterschied zwischen einem sicheren Ja und einem weiteren Monat des Ratens.

2. Jede legitime Quelle besteht DKIM oder SPF und ist ausgerichtet

Die Authentifizierung zu bestehen reicht nicht: DMARC verlangt die Ausrichtung (Alignment). Eine Nachricht muss SPF oder DKIM mit einer Domain bestehen, die der des From: entspricht. Ein Drittanbieter, der die E-Mails mit seinem eigenen Schlüssel signiert (d=marketing-plattform.com), besteht DKIM zwar technisch, aber nicht ausgerichtet — DMARC wertet das als Fehlschlag. Ist noch unklar, wie die drei Bausteine ineinandergreifen, hilft ein erneuter Blick in SPF, DKIM und DMARC gemeinsam erklärt.

Konkret, für jede Quelle aus Kästchen 1:

Entweder wird auf der Plattform eine DKIM-Signatur mit der eigenen Marke (d=beispiel.de) konfiguriert — das ist der zuverlässigste Weg, denn Drittanbieter richten SPF selten aus;
oder ihre Versanddomain wird ins SPF aufgenommen und das sichtbare From: bleibt auf der Domain der Organisation.

Das Kästchen wird nur abgehakt, wenn die Berichte für jede echte Quelle einen ausgerichteten Pass zeigen — nicht nur ein nicht ausgerichtetes dkim=pass.

3. Das SPF überschreitet nicht die 10 DNS-Lookups

SPF ist auf zehn DNS-Auflösungen gedeckelt. Darüber hinaus gibt die Prüfung einen PermError zurück und SPF schlägt fehl — selbst wenn der Eintrag „korrekt" ist. Die include: jedes Dienstleisters zu stapeln, überschreitet diese Grenze schneller, als man denkt. Dieser Zähler ist vor der Verschärfung zu prüfen, sonst trägt unbemerkt DKIM allein die Last. Das Thema wird im Detail in dem SPF-Fehler „too many DNS lookups" behandelt. Kästchen abgehakt, wenn das SPF unter der Marke von zehn auflöst.

4. Die Subdomains sind abgedeckt

Ein Angreifer, der die Root-Domain nicht mehr fälschen kann, weicht auf die Subdomains aus — einschließlich derer, die nicht existieren. Die Standard-Policy der Subdomains erbt p, aber sinnvoll ist, sie explizit mit sp zu steuern und die nicht existierenden Subdomains mit dem np-Tag von DMARCbis zu verriegeln. Das ist ein schneller und risikofreier Gewinn: Keine legitime Post geht von einer Subdomain aus, die nicht existiert. Details in der DMARC-Subdomain-Policy (sp und np). Abgehakt, wenn sp und np gesetzt und mit der Root kohärent sind.

5. Die Berichte fließen und sind seit mehreren Wochen „sauber"

Verschärft wird nicht auf einer Momentaufnahme, sondern auf einem Trend. Die Berichte müssen einige Wochen auflaufen — genug, um die monatlichen Absender (Rechnungen, Auszüge, Quartalskampagnen) zu erfassen und nicht nur den täglichen Verkehr. „Sauber" bedeutet: Die einzigen IPs, die noch in der Ausrichtung fehlschlagen, sind unbekannte Quellen, also Betrüger. Schlagen legitime Quellen noch fehl, geht es zurück zu Kästchen 2. Um sicherzustellen, dass die Berichte auch ankommen, siehe die rua-Adresse konfigurieren und ich erhalte keine DMARC-Berichte.

Ein Wort zu den Geheimnissen, die all das untermauern: Die privaten DKIM-Schlüssel sind kritische Zugangsdaten. Sie in einer Datei zu speichern, die auf einem Server herumliegt, oder in einem Ticket ist ein Risiko an sich; ein dedizierter Tresor wie Hucency Vault (vom Cybersecurity-Anbieter Hucency) verhindert, dass ein Signaturschlüssel abfließt und einem Dritten erlaubt, einen ausgerichteten Versand zu fälschen — der einzige Fall, in dem p=reject nicht schützt.

6. Tooling und Überwachungskadenz sind bereit

Die Policy zu verschärfen ist kein „veröffentlichen und vergessen". Zu planen ist, wer die Berichte nach der Änderung ansieht, wie oft und wie lange. Eine gute Praxis: auf quarantine wechseln, einige Tage überwachen, dann auf reject. Historisch staffelte man mit pct; DMARCbis (2026) entfernt pct zugunsten eines Testmodus (t=y) und eines auf Beobachtung gestützten Anstiegs. Der schrittweise Rollout wird detailliert in DMARC schrittweise ausrollen behandelt.

7. Die Entscheidung ist gefallen: quarantine oder reject?

Nicht jede Organisation muss auf Anhieb bis reject gehen. p=quarantine ist bereits eine echte Verteidigung und bleibt umkehrbar, falls etwas entgangen ist. Die Wahl hängt von der Risikotoleranz und der Kritikalität des Flusses ab — das ist Gegenstand von p=quarantine oder p=reject: was wählen. Dieses Kästchen wird abgehakt, wenn die Entscheidung bewusst getroffen wurde, nicht per Default.

Die Fallstricke, die ein bereits abgehaktes Kästchen leeren

Eine Checkliste ist nur nützlich, wenn die Kästchen abgehakt bleiben. Drei klassische Regressionen machen eine an sich gut gemachte Arbeit zunichte:

Eine neue Quelle taucht unangekündigt auf. Das Marketing startet eine A/B-Testing-Plattform, die HR wechselt ihr Lohntool, eine Tochtergesellschaft versendet unter der Marke des Konzerns. Jede kommt nicht ausgerichtet an und wird unter reject abgewiesen. Der Ausweg ist nicht, alles einzufrieren, sondern die Berichte nach der Verschärfung im Auge zu behalten: Eine neue IP, die in der Ausrichtung fehlschlägt, ist entweder ein Betrüger oder eine zu integrierende Quelle — und welches von beidem, will man wissen, bevor eine wichtige E-Mail fällt.
Ein DKIM-Schlüssel läuft ab oder wird schlecht rotiert. Eine misslungene Rotation zerstört die Ausrichtung mit einem Schlag, für eine ganze Quelle. Deshalb verlangt Kästchen 5 einen Trend, keine Momentaufnahme — und deshalb muss die Rotation dokumentiert und überwacht werden.
Eine SPF-Erneuerung fällt wieder unter die zehn Lookups … und dann darüber. Ein include: zu viel kippt zurück in einen PermError. Der Zähler aus Kästchen 3 ist keine einmalige Kontrolle, sondern eine dauerhafte Hygiene.

Nichts davon ist ein Grund, auf p=none zu bleiben — das hieße, aus Angst vor einem umkehrbaren Zwischenfall auf jeglichen Schutz zu verzichten. Es ist ein Grund, die Überwachung nach der Verschärfung als Teil des Projekts zu behandeln, nicht als optionale Pflichtaufgabe.

Was `p=reject` nicht abdeckt (und nicht nachlässig machen darf)

Die sieben Kästchen abzuhaken schützt vor der direkten Fälschung der Domain: Niemand kann mehr ein gefälschtes From: kontakt@beispiel.de senden, das im Postfach landet. Aber DMARC blockiert weder die ähnlich aussehenden Domains (beispie1.de, beispiel-support.de) noch das Display-Name-Spoofing (der Firmenname, angezeigt auf einer beliebigen Gmail-Adresse) noch kompromittierte legitime Konten. p=reject ist eine notwendige Schicht, keine einzige Schicht. Das hier zu erwähnen, verhindert das falsche Sicherheitsgefühl, das oft auf eine erfolgreiche Migration folgt — das Kästchen „ich weiß, was es nicht abdeckt" ist mental, aber es zählt.

Wie lange dauert es realistisch, alle Kästchen abzuhaken?

Eine Frage, die selten offen ausgesprochen wird: Wie viel Zeit sollte man einplanen? Die ehrliche Antwort lautet, dass es weniger vom Standard als vom jeweiligen Versand-Ökosystem abhängt. Eine kleine Organisation mit zwei oder drei Quellen — etwa Google Workspace plus ein Rechnungstool — hakt alle Kästchen realistisch in drei bis vier Wochen ab: eine Woche, um die Quellen aus den Berichten zu identifizieren und auszurichten, dann zwei bis drei Wochen, um einen sauberen Trend zu bestätigen. Eine große, dezentrale Organisation mit zwanzig oder mehr Quellen, Tochtergesellschaften und einer bewegten Historie braucht eher zwei bis drei Monate, hauptsächlich weil das Inventar aus Kästchen 1 nie ganz fertig zu sein scheint.

Der Fehler, den man hier vermeiden muss, ist, die Frist als Ziel zu behandeln statt als Konsequenz. Es geht nicht darum, „in drei Wochen auf reject zu sein", sondern darum, „auf reject zu gehen, sobald die sieben Kästchen abgehakt sind". Wer sich eine Deadline setzt und dann verschärft, obwohl Kästchen 5 noch keinen sauberen Trend zeigt, kauft sich genau das Problem ein, das die Checkliste verhindern soll. Der Zeitplan ergibt sich aus den Daten, nicht umgekehrt.

Ein pragmatischer Zwischenschritt hilft: Sobald die Kästchen 1 bis 4 stehen, lässt sich bereits np=reject setzen (risikofrei, siehe Kästchen 4) und auf p=quarantine gehen. Das bringt echten Schutz, während der saubere Mehrwochen-Trend für den finalen Sprung auf reject heranreift. So bleibt keine Woche ungeschützt, nur weil ein einzelnes Kästchen noch Zeit braucht.

Das Urteil

Sind die sieben Kästchen abgehakt, ist die Domain geeignet — dann wird verschärft. Bleibt auch nur eines leer, ist die nächste Aufgabe benannt, und sie ist präzise. Die Schönheit der Checkliste ist, dass sie eine angstbesetzte Entscheidung („Was, wenn ich alles kaputtmache?") in eine faktenbasierte Prüfung verwandelt: Entweder sagen die Daten ja, oder sie zeigen genau, was fehlt, ohne Platz für Intuition oder Hoffnung.

Ein letzter Reflex vor der Veröffentlichung des neuen Eintrags: Ein Durchlauf der Domain durch den kostenlosen DMARC-Analyzer zeigt von außen, was die Empfänger sehen werden — Ausrichtung, Policy, Subdomains, SPF. Das ist die finale Kontrolle, die Tippfehler und Last-Minute-Regressionen abfängt. Und wer den Fortschritt über die Zeit verfolgen will statt auf einer Momentaufnahme, findet im DMARC-Observatorium die Domain im Verhältnis zu ihrer Branche verortet. p=reject ist kein Akt der Tapferkeit; es ist eine vollständig abgehakte Checkliste.

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