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

Hier ist eine Lücke, die viele gut geschützte Organisationen unwissentlich weit offen lassen: die Subdomains, die es nicht gibt. Du hast deine-domain.de verschärft, vielleicht sogar sp für deine echten Subdomains eingestellt — aber ein Angreifer kann trotzdem Post von rechnung.deine-domain.de oder sicherheit-paypal.deine-domain.de versenden, Subdomains, die du nie angelegt hast. 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 du es in einer Zeile einstellst. Für den Gesamtüberblick über DMARCbis siehe DMARCbis einfach erklärt.

Das Problem: eine erfundene Subdomain fälschen

Erinnere dich 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 in deinem DNS nicht existiert?

Ohne dedizierte Policy ist das Verhalten unklar. Viele Empfänger wissen angesichts von zahlung.deine-domain.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. Du setzt es auf deinen Root-DMARC-Eintrag:

_dmarc.deine-domain.de.  IN TXT
  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:berichte@deine-domain.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. Du kannst np=reject also sofort setzen, selbst wenn deine 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 (deine-domain.de).
• sp — die Policy der Subdomains, die existieren (mail.deine-domain.de, news.deine-domain.de).
• np — die Policy der Subdomains, die nicht existieren (rechnung-xyz.deine-domain.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, kannst du 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. Du brauchst beide: sp für deine 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, die du besitzt, von der du aber nie versendest, sollte auf p=reject; np=reject stehen — das gilt auch für die ruhenden Domains.

Wie du prüfst, dass es aktiv ist

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

1. Lies deinen Eintrag noch einmal 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.
2. Überwache deine aggregierten Berichte: Eine gefälschte, nicht existierende Subdomain erscheint fortan mit einer Disposition reject, statt sich durchzuschleichen. Lerne, sie zu lesen, 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 du nicht angelegt hast.

Empfohlene Einstellungen je nach deinem Fall

• Normale Versanddomain, bereits auf p=reject: p=reject; sp=reject; np=reject. Das strenge Trio, ohne Bedenken.
• Domain noch im Anstieg (p=quarantine): Du kannst np=reject 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. Denk einfach daran, sie zu authentifizieren (SPF/DKIM), bevor du sie zum Versenden nutzt — 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 deiner Subdomains

Über das Tag selbst hinaus ist np die Gelegenheit, dir eine selten behandelte Frage zu stellen: Wer legt bei dir 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: deine Versand-Subdomains inventarisieren, ausrichten und sp kohärent halten.

Ein guter Reflex: die Liste deiner Subdomains als Sicherheitsasset behandeln, gleichrangig mit deinem Inventar der Versandquellen. Die aggregierten Berichte helfen dir auch hier — sie enthüllen Post, die von Subdomains ausgeht, die du vergessen hattest, 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, wenn du langfristig BIMI anstrebst: dein Logo anzuzeigen setzt eine kohärente Marke und eine strenge Policy über deinen 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: „mein 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.deine-domain.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 du dir angewöhnen solltest: „Root-Domain, existierende Subdomains, nicht existierende Subdomains — drei Fragen, drei Antworten, drei Tags." Sobald du so denkst, 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. Stell np=reject ein: 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).

Lass Thomas die richtige Policy setzen

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

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