Das np-Tag von DMARC: Subdomains verriegeln, die es nicht gibt

Von Thomas · virtueller CISO · 2026-06-29

Hier ist eine Lücke, die viele gut geschützte Organisationen unwissentlich weit offen lassen: die Subdomains, die es nicht gibt. beispiel.de ist verschärft, vielleicht ist sogar sp für die echten Subdomains eingestellt — aber ein Angreifer kann trotzdem Post von rechnung.beispiel.de oder sicherheit-paypal.beispiel.de versenden, Subdomains, die nie angelegt wurden. DMARCbis (2026) fügt genau das Tag hinzu, das diese Tür schließt: np. Dieser Leitfaden erklärt das Problem, was np tut, wie es sich von sp unterscheidet und wie es sich in einer Zeile einstellen lässt. Für den Gesamtüberblick über DMARCbis siehe DMARCbis einfach erklärt.

Das Problem: eine erfundene Subdomain fälschen

Zur Erinnerung an das Prinzip von DMARC: Es prüft, dass die authentifizierte Domain der Domain des From: entspricht (die Ausrichtung). Aber was passiert, wenn der Angreifer eine Subdomain in das From: setzt, die im DNS der Domain nicht existiert?

Ohne dedizierte Policy ist das Verhalten unklar. Viele Empfänger wissen angesichts von zahlung.beispiel.de (nicht existent) nicht, welche Policy anzuwenden ist: die der Subdomain (die nicht existiert) oder die der Root-Domain? Genau diese Mehrdeutigkeit nutzen Phishing-Kits aus: Sie fabrizieren glaubwürdige Subdomains — support., secure., login., rechnung. — gerade weil niemand sie überwacht und keine Policy sie explizit abdeckt.

Was `np` tut

Das Tag np (für non-existent policy) beantwortet diese Frage klar und deutlich: Es legt die Policy fest, die auf Post anzuwenden ist, die vorgibt, von einer Subdomain ohne DNS-Eintrag zu stammen. Es wird auf dem Root-DMARC-Eintrag gesetzt:

_dmarc.beispiel.de.  IN TXT
  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:berichte@beispiel.de"

Mit np=reject wird jede Post, die sich auf eine nicht existierende Subdomain beruft, abgewiesen. Und das ist eine völlig risikofreie Einstellung: Per Definition geht keine legitime Post von einer Subdomain aus, die nicht existiert. np=reject lässt sich also sofort setzen, selbst wenn die Root-Domain noch auf p=quarantine steht oder gerade verschärft wird.

`np` vs `sp` vs `p`: wer deckt was ab

Das ist die häufigste Verwechslung. Die drei Tags teilen sich die Fälle auf:

p — die Policy der Root-Domain selbst (beispiel.de).
sp — die Policy der Subdomains, die existieren (mail.beispiel.de, news.beispiel.de).
np — die Policy der Subdomains, die nicht existieren (rechnung-xyz.beispiel.de).

Vor DMARCbis existierten nur p und sp. Ein Angreifer, der auf eine nicht existierende Subdomain zielte, fiel in eine Grauzone. np beseitigt diese Grauzone. In der Praxis stellt man für eine gut gepflegte Domain oft alle drei auf denselben strengen Wert: p=reject; sp=reject; np=reject.

Warum das ein schneller und vorrangiger Gewinn ist

Die meisten DMARC-Verschärfungen erfordern Arbeit: Quellen inventarisieren, ausrichten, Berichte überwachen (siehe p=reject erreichen). np ist das Gegenteil: null Inventar, null Risiko, sofortige Wirkung. Da kein legitimer Dienst von einer nicht existierenden Subdomain aus versendet, lässt sich dabei nichts kaputtmachen. Deshalb empfiehlt man es früh — oft sobald die Root-Domain gesund ist, noch bevor der Anstieg zu p=reject auf dem Ganzen abgeschlossen ist.

Das gilt besonders für Organisationen mit großer Subdomain-Fläche — Banken, Großkonzerne, öffentlicher Sektor — die dutzende reale Subdomains betreiben und ebenso viele vorstellbare offen lassen. Auf diesem Terrain schließt np=reject mit einem Schlag eine ganze Angriffskategorie. Den Finanzfall behandeln wir in den Banken.

Ein paar nützliche Klarstellungen

np wird nur von Empfängern interpretiert, die auf dem DMARCbis-Stand sind. Während der Übergangsphase ignorieren es einige noch — ohne Schaden, sie fallen auf das vorherige Verhalten zurück. Nichts zu verlieren, es schon jetzt zu veröffentlichen.
np ersetzt sp nicht. Beide werden gebraucht: sp für die echten Subdomains, np für die Phantome. Eines wegzulassen lässt eine Hälfte der Fläche exponiert.
Das „nicht existent" beurteilt sich über das DNS. Eine Subdomain gilt als nicht existent, wenn sie nicht auflöst (kein Eintrag). Hier greift der DNS Tree Walk, der Mechanismus, mit dem DMARCbis die Domain-Baumstruktur ermittelt.
Geparkte Domains lieben np. Eine Domain im eigenen Besitz, von der aber nie versendet wird, sollte auf p=reject; np=reject stehen — das gilt auch für die ruhenden Domains.

Wie sich die Aktivierung prüfen lässt

Sobald np=reject veröffentlicht ist, zwei Kontrollen:

Den Eintrag noch einmal lesen mit einem Analyzer, um zu bestätigen, dass das Tag wirklich vorhanden und die Syntax gültig ist — unser kostenloser Analyzer erledigt das in wenigen Sekunden.
Die aggregierten Berichte überwachen: Eine gefälschte, nicht existierende Subdomain erscheint fortan mit einer Disposition reject, statt sich durchzuschleichen. Wie sie zu lesen sind, steht in wie man aggregierte Berichte liest.

Ein konkretes Angriffsszenario

Spielen wir einen realen Angriff durch, um np in Aktion zu sehen. Ein Unternehmen, beispiel.de, hat seine Arbeit gut gemacht: p=reject auf der Root-Domain, sp=reject für seine bekannten Subdomains (mail.beispiel.de, news.beispiel.de). Es glaubt sich geschützt.

Ein Angreifer bereitet eine Phishing-Kampagne vor. Statt beispiel.de zu fälschen (von p=reject abgewiesen) oder mail.beispiel.de (von sp=reject abgewiesen), wählt er From: rechnung@konten.beispiel.de. Diese Subdomain konten.beispiel.de existiert nicht im DNS von beispiel.de. Ohne np-Tag finden sich viele Empfänger in einer Grauzone wieder: Soll man die Root-Policy anwenden? Die der Subdomains? Nichts? Je nach Implementierung kann die Nachricht durchgehen — und mit einer perfekt glaubwürdigen Adresse im Postfach des Opfers landen.

Nun derselbe Angriff mit veröffentlichtem np=reject: Der Empfänger stellt fest, dass konten.beispiel.de keinen Eintrag hat (über den DNS Tree Walk), wendet die np-Policy an und weist die Nachricht ab. Der Angriff scheitert, ohne dass beispiel.de auch nur eine fiktive Subdomain hätte anlegen oder überwachen müssen. Das ist der ganze Wert von np: die Unendlichkeit der Subdomains abzudecken, die nie angelegt wurden.

Empfohlene Einstellungen je nach Fall

Normale Versanddomain, bereits auf p=reject: p=reject; sp=reject; np=reject. Das strenge Trio, ohne Bedenken.
Domain noch im Anstieg (p=quarantine): np=reject lässt sich schon jetzt setzen, unabhängig von p. Keine legitime Post geht von einer nicht existierenden Subdomain aus, also kein Risiko, sie sofort zu verriegeln.
Rein „corporate" Domain ohne Versand-Subdomains: np=reject ist fast obligatorisch — genau diese Art von Domain wird über erfundene Subdomains gefälscht.
Geparkte Domain (kein Versand): p=reject; sp=reject; np=reject überall. Nichts geht raus, alles muss abgewiesen werden.

Häufige Fragen zu `np`

Kann np=reject legitime Post blockieren? Nein, per Konstruktion. Das Tag gilt nur für Subdomains ohne DNS-Eintrag. Ein legitimer Dienst, der von einer Subdomain aus versendet, hat aber zwangsläufig Einträge (mindestens für SPF/DKIM). Wenn er welche hat, „existiert" die Subdomain und fällt unter sp, nicht unter np.

Was passiert, wenn ich später eine echte Subdomain anlege? Sobald sie DNS-Einträge hat, „existiert" sie und fällt unter das Regime von sp. Zu bedenken ist nur, sie zu authentifizieren (SPF/DKIM), bevor sie zum Versenden genutzt wird — wie jede Quelle.

Ist np obligatorisch? Nein, in DMARCbis ist nichts obligatorisch. Aber es ist eine der Neuerungen mit dem besten Nutzen-Risiko-Verhältnis: echte Wirkung gegen Phishing, null Risiko, ein einziges Tag.

Honorieren schon alle Empfänger np? Noch nicht alle — die Einführung von DMARCbis ist schrittweise. Diejenigen, die es nicht kennen, ignorieren es einfach (ohne Schaden). Je mehr sich das Ökosystem aktualisiert, desto stärker wird der Schutz. Kein Grund zu warten, um es zu veröffentlichen.

np und die Governance der Subdomains

Über das Tag selbst hinaus ist np die Gelegenheit für eine selten gestellte Frage: Wer legt in der Organisation Subdomains an, und wer weiß davon? In vielen Organisationen kann jedes Team sommer-kampagne.beispiel.de auf einen Dienstleister zeigen lassen, ohne die Sicherheit zu informieren. Jede reale Subdomain ist eine zu authentifizierende Fläche; jede nicht angelegte Subdomain ist eine abzuweisende Fläche. np=reject regelt die zweite Kategorie mit einem Schlag, aber die erste verlangt echte Disziplin: die Versand-Subdomains inventarisieren, ausrichten und sp kohärent halten.

Ein guter Reflex: die Liste der Subdomains als Sicherheitsasset behandeln, gleichrangig mit dem Inventar der Versandquellen. Die aggregierten Berichte helfen auch hier — sie enthüllen Post, die von vergessenen Subdomains ausgeht, legitim oder nicht. Ist diese Kartierung erst gemacht, wird das Paar sp/np einfach einzustellen: sp streng für das, was existiert und versendet, np=reject für alles Übrige.

Das gilt besonders bei einem langfristigen BIMI-Ziel: Das eigene Logo anzuzeigen setzt eine kohärente Marke und eine strenge Policy über den gesamten Namensraum voraus. Eine fälschbare Subdomain ist ein Riss in dieser Vertrauenserzählung. Nicht existierende Subdomains mit np zu verriegeln ist daher ebenso eine Anti-Phishing-Maßnahme wie ein Baustein der Markenkohärenz.

Ein häufiges Missverständnis: „das Root-p reicht doch"

Viele Verantwortliche gehen davon aus, dass ein strenges p=reject auf der Root automatisch alle Subdomains abdeckt, einschließlich der nicht existierenden. Das ist ein verbreiteter, aber gefährlicher Irrtum. Ohne explizite sp- und np-Tags erben die Subdomains zwar die Root-Policy als Fallback, aber das Verhalten bei nicht existierenden Subdomains war vor DMARCbis nie eindeutig spezifiziert — und genau diese Unschärfe ist die Lücke. Ein Empfänger, der auf eine Nachricht von konten.beispiel.de trifft, muss erst ermitteln, ob diese Subdomain existiert, und dann entscheiden, welche Policy gilt. In dieser Kette von Entscheidungen unterschieden sich die Implementierungen, und manche ließen die Nachricht durch.

np beseitigt diese Kette, indem es die Frage direkt beantwortet: Für alles, was nicht im DNS auflöst, gilt diese Policy, Punkt. Es ist deshalb kein Ersatz für ein gutes p, sondern eine Präzisierung, die die Root-Policy nach unten hin vervollständigt. Der mentale Reflex, den man sich angewöhnen sollte: „Root-Domain, existierende Subdomains, nicht existierende Subdomains — drei Fragen, drei Antworten, drei Tags." Sobald man so denkt, wird klar, dass ein Eintrag mit nur p=reject eine der drei Antworten offen lässt.

Das ist auch der Grund, warum np bei einem externen Audit oft als schnelle Empfehlung auftaucht: Es ist eine sichtbare, risikofreie Verbesserung, die die Angriffsfläche messbar verkleinert, ohne dass eine einzige legitime Quelle betroffen wäre. Wenige DMARC-Änderungen haben ein so günstiges Verhältnis von Aufwand zu Wirkung.

Kurz gesagt

Das Tag np von DMARCbis legt die Policy der Subdomains fest, die nicht existieren — eine Lücke, die sp nicht abdeckte. np=reject ist zu setzen: Es ist risikofrei (nichts Legitimes geht von einer nicht existierenden Subdomain aus) und sofort wirksam gegen eine ganze Phishing-Kategorie. Drei Tags zu unterscheiden: p (Root), sp (reale Subdomains), np (Phantom-Subdomains).

Thomas setzt die richtige Policy

np, sp, p: drei Tags, eines schlecht eingestellt reicht, um eine Tür offen zu lassen. Thomas, der virtuelle CISO, generiert den vollständigen und kohärenten DMARCbis-Eintrag für eine Domain — Root, reale und nicht existierende Subdomains — und prüft anhand der Berichte, dass keine legitime Quelle betroffen ist, bevor verschärft wird.

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

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