Die DMARC-Checkliste 2026: von null zu p=reject

Von Thomas · virtueller CISO · 15. August 2026

Die meisten DMARC-Anleitungen werfen drei Zeilen DNS zum Kopieren hin und wünschen viel Glück. So funktioniert das nicht. Eine Domain von „nichts" zu wirklich geschützt zu bringen, ist ein Aufstieg: Jeder Schritt bereitet den nächsten vor, und einen zu überspringen bedeutet zu fallen — ein zu früh veröffentlichtes p=reject blockiert die eigene legitime Post, und man kehrt hektisch zu p=none zurück und schwört, dass „DMARC alles kaputt macht". Diese Checkliste bringt die Schritte in die richtige Reihenfolge. Zehn davon, jeder in zwei Sätzen zusammengefasst, jeder mit dem Leitfaden verlinkt, der in die Tiefe geht. Wer sie der Reihe nach abhakt, nicht quer, erreicht die Durchsetzung, ohne unterwegs je eine E-Mail zu verlieren.

Ein Wort zur Lage 2026, bevor wir anfangen. Der Standard hat einen neuen Namen: Seit Mai 2026 ersetzt DMARCbis die alte RFC 7489. In der Praxis bewegen sich drei Dinge — der DNS Tree Walk ersetzt die Public Suffix List, um eine Subdomain an ihre Organisationsdomain zu knüpfen, eine np-Marke deckt nun nicht existierende Subdomains ab, und der Testmodus t= ersetzt das alte pct. Nichts davon stellt die Logik der Checkliste auf den Kopf; es schärft sie. Wer vor dem Eintauchen den Überblick sucht, findet ihn in was sich mit DMARCbis wirklich ändert in zehn Minuten. Ansonsten legen wir los.

Schritt 1 — Jede Versandquelle inventarisieren

Vor jeder Zeile DNS ist eine dumme und doch entscheidende Frage zu beantworten: Wer sendet Post im Namen der Domain? Der Hauptmailserver, ja — aber auch das CRM, die Newsletter-Plattform, das Rechnungstool, das Bewerber-ATS, das SaaS, das die Belege verschickt, und der Marketingdienst, von dem niemand je erzählt hat. Jede dieser Quellen muss am Ende ausgerichtet sein, sonst fällt sie in dem Moment aus, in dem die Durchsetzung greift. Ist noch nicht klar, was DMARC in dieser Kette tatsächlich tut, legt was DMARC ist und wozu es dient das Fundament. Das Inventar ist die Grundlage: Alles Folgende wird an dieser Liste gemessen.

Schritt 2 — Das SPF prüfen und korrigieren

SPF erklärt, welche Server für die Domain senden dürfen. Es zu prüfen ist im Prinzip einfach und in der Praxis tückisch, wegen einer harten Grenze: ein SPF-Eintrag darf 10 DNS-Abfragen nicht überschreiten, sonst fällt er in permerror und schützt lautlos nicht mehr. Am Anfang steht, den SPF-Eintrag zu prüfen, um den Stand zu sehen. Stapeln sich die include:-Einträge der Anbieter, ist die Decke schnell erreicht — das mit Abstand häufigste Problem, aufgeschlüsselt in das SPF-Lookup-Limit und wie man es umgeht. Die Säule SPF versammelt den Rest.

Schritt 3 — DKIM einrichten

Wo SPF Server autorisiert, signiert DKIM die Nachrichten kryptografisch: Jede E-Mail trägt eine Signatur, die der Empfänger gegen einen im DNS veröffentlichten öffentlichen Schlüssel prüft. Eine gültige Signatur übersteht Weiterleitungen, wo SPF bricht — deshalb ist DKIM die robustere Ausrichtungssäule. Der Teil, der anfangs verwirrt, ist der Selektor: jenes Etikett (s1._domainkey, google._domainkey…), das einer Domain erlaubt, mehrere Schlüssel parallel zu tragen. Der DKIM-Selektor erklärt räumt damit auf; die Säule DKIM deckt die Schlüsselerzeugung und den Rest ab. Das Ziel ist ein 2048-Bit-Schlüssel.

Schritt 4 — DMARC auf `p=none` mit `rua` veröffentlichen

Erst jetzt wird DMARC veröffentlicht — und zwar auf p=none. Das ist kein Schutz, es ist ein Mikroskop: p=none blockiert nichts, es bittet lediglich darum, Berichte zu empfangen. Die entscheidende Marke in diesem Stadium ist rua, die Adresse, die die täglichen aggregierten Berichte sammelt. Ohne rua bleibt man blind; mit ihr wird endlich sichtbar, wer im Namen der Domain sendet. Ein minimaler Eintrag sieht so aus: v=DMARC1; p=none; rua=mailto:berichte@beispiel.de. Der Versuchung, schneller zu gehen, ist zu widerstehen: p=none ist der Beobachtungsschritt, und ihn zu überspringen heißt, blind durchzusetzen.

Schritt 5 — Die aggregierten Berichte lesen

Sobald die Berichte eintreffen, sind sie zu lesen — und hier geben viele auf, weil das Rohformat mit bloßem Auge unlesbares XML ist. Diese aggregierten Berichte nennen, Quelle für Quelle, wie viele Nachrichten SPF und DKIM bestanden oder nicht bestanden haben, und vor allem die Ausrichtung. Zu lernen, sie zu entschlüsseln, ist der eigentliche Wendepunkt des Projekts: Es macht aus „ich veröffentliche DMARC" ein „ich weiß, was meine Domain tut". Aggregierte DMARC-Berichte verstehen erklärt, worauf man achtet und in welcher Reihenfolge. Zwei oder drei Wochen Daten sind nötig, bevor sich irgendetwas folgern lässt.

Schritt 6 — Die Ausrichtung korrigieren, Quelle für Quelle

Das ist das Herzstück der Arbeit und der längste Schritt. Die Berichte decken legitime Quellen auf, die die Ausrichtung nicht bestehen: ein Anbieter, der unter seiner eigenen Domain (d=) signiert, ein vergessener Server, ein fehlender SPF-Include. Jede davon wird einzeln korrigiert — den DKIM-Schlüssel des Anbieters veröffentlichen, den Include hinzufügen, das Signieren einschalten. Das Ziel: 100 % der legitimen Post bestehen SPF oder ausgerichtetes DKIM. Solange eine einzige legitime Quelle noch scheitert, wird nicht durchgesetzt; genau sie würde ausfallen. Diese methodische Bereinigungsphase ist genau das, was die Checkliste von none zu reject beschreibt — jede Quelle abhaken, bevor es weitergeht.

Schritt 7 — Auf `quarantine` umsteigen

Sind die Berichte sauber — keine legitime Quelle scheitert mehr —, folgt der erste Durchsetzungsschritt: p=quarantine. Post, die DMARC nicht besteht, geht dann in den Spam, statt zugestellt zu werden. Und hier ändert DMARCbis die Methode: Das alte pct=25 ist zu vergessen, unvorhersehbar und aus dem Standard entfernt. Stattdessen kommt der Testmodus t=y, der den Empfängern sagt „ich experimentiere, melde mir Fehlschläge, ohne schon strikt zu härten". Der Hochlauf steuert sich über die Beobachtung der Berichte, nicht über einen riskanten Prozentsatz. Die DMARCbis-Marke t erläutert diesen Mechanismus; um den tieferen Unterschied zwischen den beiden Stufen zu erfassen, klärt Quarantine oder Reject, was wählen die Frage.

Schritt 8 — Auf `p=reject` umsteigen

Das ist der Schritt, auf den alles andere hingearbeitet hat. Bei p=reject wird betrügerische Post abgewiesen, bevor sie den Posteingang des Empfängers erreicht — die Domain zu fälschen wird unmöglich, nicht bloß gemeldet. Wurden die Schritte 1 bis 7 sorgfältig erledigt, ist dieser Übergang ein Nicht-Ereignis: Die Quellen sind ausgerichtet, die Berichte sind sauber, es bleiben nur noch die Betrüger zu blockieren. Die vollständige Methode, mit den Vorsichtsmaßnahmen, um keinen Fluss zu brechen, steht in p=reject erreichen, ohne die E-Mails zu brechen. Der Schalter wird erst umgelegt, wenn mehrere Wochen Quarantine-Berichte bestätigen, dass nur das Illegitime scheitert.

Schritt 9 — Die Subdomains sichern

p=reject schützt die Root-Domain, aber ein Angreifer ist schlau: Er zielt auf rechnungen.beispiel.de oder eine Subdomain, die nie existiert hat. Zwei Marken schließen diese Tür. sp setzt die Richtlinie für existierende Subdomains; np, eine DMARCbis-Neuerung, deckt nicht existierende Subdomains ab — das Lieblingsziel, weil das Fälschen eines Namens, der nicht existiert, keinen DNS-seitigen Alarm auslöst. np=reject zu setzen ist kostenlos und trägt nicht das geringste Risiko für die legitime Post. Die Subdomain-Richtlinie (sp) und die np-Marke für nicht existierende Subdomains erläutern die Rolle jeder einzelnen. Hier verrichtet der DMARCbis-DNS Tree Walk seine Arbeit hinter den Kulissen und knüpft jede Subdomain sauber an ihre Richtlinie.

Schritt 10 — Die Belohnung: BIMI

Einmal auf p=reject, öffnet sich ein sichtbarer Vorteil: BIMI zeigt das offizielle Logo der Marke neben ihren Nachrichten in unterstützenden Postfächern (Gmail, Apple Mail…). Es ist nicht bloß Zierde — es ist ein Vertrauenssignal, das die Öffnungsraten hebt und Nachahmung erschwert. BIMI verlangt p=reject oder p=quarantine: Es ist buchstäblich die Karotte am Ende des Wegs. BIMI einrichten und das Logo in Gmail zeigen zeigt, wie sich der Eintrag veröffentlichen und, wo nötig, das dazugehörige Zertifikat beschaffen lässt. Es ist die Medaille, die man sich nach dem Aufstieg verdient hat.

Was die Checkliste nicht laut genug sagt

Beim erneuten Lesen der zehn Schritte sticht eines heraus: acht von zehn sind keine Konfiguration, sondern Beobachtung und Korrektur. Drei Marken zu veröffentlichen dauert fünf Minuten; zu wissen, wann man sie härtet, dauert Wochen des Berichtelesens. Das ist das genaue Gegenteil der Intuition, und genau hier bleiben die meisten Domains stecken — nicht aus Unkenntnis, wie man einen Eintrag schreibt, sondern weil sie die Ausrichtungsdisziplin nicht lange genug durchgehalten haben. Die Lage 2026 ändert diese Wahrheit nicht: DMARCbis modernisiert das Werkzeug (Tree Walk, np, t=), es verkürzt den Aufstieg nicht. Wer nach p=reject den vollständigen Wechsel zum neuen Standard sucht, findet ihn separat kartiert, aber er ist nie die erste Dringlichkeit — die Durchsetzung ist es.

Eine Nuance, die Projekte rettet: eine Checkliste ist kein Rennen. Niemand überreicht einen Preis dafür, p=reject in einer Woche erreicht zu haben, und niemand bestraft drei Monate Arbeit daran. Was zählt, ist nicht die Geschwindigkeit des Aufstiegs — es ist seine Sicherheit. Eine Domain, die zu p=reject gehetzt wird und an einem Montagmorgen ihre eigenen Rechnungen blockiert, ist vollständiger gescheitert als eine Domain, die geduldig bei Quarantine blieb, lange genug, um ihre letzte Quelle auszurichten. Einen Schritt höher steigt man, wenn der vorige solide ist, nicht vorher. Es ist so langweilig wie das, und es ist so wirksam wie das.

Sofort prüfen, wo die Domain steht

Der erste Schritt ist kostenlos und dauert zehn Sekunden. Ein Durchlauf der Domain durch unseren kostenlosen DMARC-Analyzer liefert ein sofortiges Urteil über die aktuelle Richtlinie, die SPF- und DKIM-Einträge und den genauen Schritt der Checkliste, an dem sie steht. Um eine Haltung mit der ihres Sektors zu vergleichen — und zu sehen, wie viele Domains noch bei p=none festhängen —, gibt das DMARC-Observatorium das Panorama.

Diese Checkliste von Hand zu führen, Quelle für Quelle und Woche für Woche, ist machbar, aber mühsam. Genau das automatisiert Thomas, der virtuelle CISO: Er inventarisiert die Quellen aus den Berichten, benennt jede, generiert das genaue zu veröffentlichende DNS (DMARCbis-Marken inbegriffen: np, t), misst die Bereitschaft pro Domain und nennt den genauen Schritt, an dem sich ohne Risiko härten lässt. Eine Domain kostenlos analysieren · das Observatorium erkunden · mit Thomas beginnen.