Die DMARC-Subdomain-Policy: sp und np

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@beispiel.de

Das Tag np: die nicht existierenden Subdomains verriegeln

Das ist der nützlichste Beitrag von DMARCbis im Bereich der Subdomains. Das Tag np (non-existent subdomain policy) legt die Policy der Subdomains fest, die nicht im DNS existieren — das heißt, die keinen A-, AAAA- oder MX-Eintrag haben.

Warum ist das entscheidend? Weil ein Angreifer nicht braucht, dass rechnung.beispiel.de existiert, um es in ein From: zu schreiben. Er fälscht die Adresse, versendet sie und setzt darauf, dass die Policy diesen Fall nicht abdeckt. Mit np=reject lautet die Erklärung: „Jede Mail, die vorgibt von einer nicht existierenden Subdomain zu kommen, ist abzuweisen."

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@beispiel.de

Der große Vorteil von np: Es ist ein sofortiger und risikoloser Gewinn. Keine legitime Mail geht von einer Subdomain aus, die nicht existiert, per Definition. np=reject lässt sich also sehr früh im Rollout setzen, noch bevor alle echten Quellen ausgerichtet sind — es gibt nichts zu beobachten, nichts zu zerbrechen. Das Tag hat seinen eigenen detaillierten Leitfaden: das np-Tag (nicht existierende Subdomain).

Wie der Empfänger den richtigen Eintrag wählt

Um sp oder np anzuwenden, muss der Empfänger zuerst bestimmen, welcher DMARC-Eintrag eine gegebene Nachricht regiert und ob die Subdomain existiert. Historisch stützte sich diese Bestimmung der Organisationsdomain auf die Public Suffix List (PSL). DMARCbis ersetzt sie durch den DNS Tree Walk: eine Folge von DNS-Abfragen (höchstens acht), die den Namensbaum hinaufsteigt, bis der anwendbare DMARC-Eintrag gefunden ist.

In der Praxis sucht der Empfänger für eine Nachricht, die vorgibt von a.b.beispiel.de zu kommen, einen DMARC-Eintrag auf diesem Namen, steigt dann Ebene für Ebene bis zur Organisationsdomain hinauf und wendet die spezifischste gefundene Policy an — wobei er zwischen existierender Subdomain (sp oder ihr eigener Eintrag) und nicht existierender (np) unterscheidet. Der Mechanismus ist im Detail erklärt in der DNS Tree Walk. Für den Tree Walk selbst ist nichts zu konfigurieren; es genügt, kohärente sp/np zu veröffentlichen.

Das Angriffsszenario, das das blockiert

Man nehme eine Bank, deren Root bank.de in p=reject ist, ohne np. Ein Betrüger versendet eine Phishing-Kampagne von sicherheit.bank.de — einer Subdomain, die nicht existiert. Da sie nicht existiert, hat sie keinen eigenen Eintrag; und je nach Implementierung kann die Vererbung von p uneinheitlich auf einen nicht existierenden Namen angewandt werden. Die Nachricht kann also durchkommen, mit einer glaubwürdigen Absenderadresse, die dem Opfer Vertrauen einflößt.

Mit np=reject bricht dieses Szenario zusammen: Der Empfänger sieht eine nicht existierende Subdomain, wendet np an, weist die Nachricht ab. Das ist genau die Art von Usurpation „über die Seite", die große Marken erleiden und die sp/np für nahezu keine Konfigurationskosten neutralisieren. Das Thema der stark angegriffenen Marken wird ausgeführt in DMARC für Banken.

Empfohlene Einstellungen

Für die Mehrheit der Domains ist die Ziel-Konfiguration einfach und symmetrisch:

• p=reject auf der Root, sobald die Quellen ausgerichtet sind.
• sp=reject, damit die existierenden Subdomains ohne eigenen Eintrag ebenfalls geschützt sind.
• np=reject, um die nicht existierenden Subdomains zu schließen — früh zu setzen, ohne zu warten.

Hat eine legitime Subdomain besondere Bedürfnisse (noch nicht ausgerichteter Dienstleister), bekommt sie ihren eigenen DMARC-Eintrag, statt sp auf der gesamten Root zu schwächen. Das ist chirurgischer und bewahrt den globalen Schutz.

Wann eine Subdomain ihren eigenen Eintrag verdient

Die Vererbung über sp deckt den allgemeinen Fall ab, aber manche Subdomains haben ein Eigenleben, das einen dedizierten DMARC-Eintrag rechtfertigt — direkt auf _dmarc.die-subdomain.beispiel.de veröffentlicht. Drei typische Situationen:

• Ein eigenständiger und umfangreicher Versandfluss. Dient mail.beispiel.de ausschließlich der Marketing-Plattform, erlaubt ein eigener Eintrag eine separate rua-Adresse und die Verfolgung dieses Flusses unabhängig von der Root. Dedizierte Berichte zeigen auf einen Blick, ob diese präzise Quelle gesund ist.
• Ein anderer Härtungsrhythmus. Eine Subdomain, deren Quellen noch nicht alle ausgerichtet sind, kann in quarantine bleiben, während die Root auf reject wechselt. Statt sp für die gesamte Organisation abzusenken, bleibt die Verzögerung auf die einzige betroffene Subdomain isoliert.
• Eine Delegation an eine dritte Einheit. Tochtergesellschaft, Zweitmarke, Dienstleister, der eine komplette Subdomain verwaltet: Der Subdomain einen eigenen DMARC-Eintrag anzuvertrauen klärt die Verantwortlichkeiten und verhindert, dass ein Fehler ihrerseits die Policy der Root beeinträchtigt.

Die mentale Regel ist einfach: Der spezifischste Eintrag gewinnt. Ein auf die Subdomain gesetztes _dmarc gewinnt immer über das von der Root geerbte sp. Diese Spezifität dient dazu, die Ausnahmen lokal zu behandeln, ohne jemals den globalen Schutz auf Ebene der Organisationsdomain zu schwächen.

Der Fall der geparkten und mailfreien Domains

Ein häufiger blinder Fleck: die Domains (oder Subdomains) im eigenen Besitz, von denen aus aber keine E-Mail versandt wird — defensive Marken, alte Namen, „für alle Fälle" reservierte Domains. Viele Organisationen lassen sie ohne DMARC, in dem Glauben, dass eine Domain, die nichts versendet, nichts riskiert. Das Gegenteil ist der Fall: Eine Domain ohne DMARC-Policy ist eine Domain, die jeder ohne Widerstand usurpieren kann. Die bewährte Praxis ist, ihnen von Anfang an die strengste Policy zu setzen — p=reject; sp=reject; np=reject — da per Konstruktion keine legitime Mail von ihnen ausgeht. np bekommt hier seinen vollen Sinn: Auf einer geparkten Domain sind alle Subdomains nicht existierend.

Häufige Fehler

• Die Root härten und die Subdomains vergessen. Das ist die häufigste Lücke nach einer gelungenen Migration: p=reject auf der Root, nichts auf sp/np, und eine weit offene Seitentür.
• sp und np verwechseln. sp deckt die Subdomains ab, die existieren; np jene, die nicht existieren. Beide sind nötig; das eine ersetzt das andere nicht.
• Warten, np zu setzen. Da es risikolos ist, verlängert das Aufschieben von np=reject nur unnötig die Exposition.
• Glauben, die Subdomain-Policy regle das Alignment. sp und np sagen, was mit der scheiternden Mail zu tun ist; sie richten die echten Subdomain-Quellen deswegen nicht aus — das bleibt eine separate Arbeit.

Wie sich prüfen lässt, ob die Subdomains wirklich abgedeckt sind

Zu wissen, dass sp und np existieren, ist eine Sache; sicherzugehen, dass sie im konkreten Fall greifen, eine andere. Der Reflex vieler Administratoren ist, den DMARC-Eintrag der Root zu betrachten, sp=reject; np=reject darin zu lesen und die Sache für erledigt zu halten. Das reicht nicht ganz, denn der eigentliche Test ist, was ein Empfänger tatsächlich sieht, wenn eine Nachricht von einer Subdomain vorgibt zu kommen. Zwei Kontrollen sind hier aufschlussreich. Erstens ist zu prüfen, ob irgendeine Subdomain einen eigenen, womöglich vergessenen DMARC-Eintrag trägt — denn dieser eigene Eintrag gewinnt über sp, und wenn er zu schwach ist (etwa ein altes p=none, das dort seit Jahren steht), reißt er ein Loch in den Schutz, das die Root-Policy nicht stopfen kann. Zweitens ist für eine typische nicht existierende Subdomain zu prüfen, ob sie wirklich auf keiner Ebene DNS-Einträge (A, AAAA, MX) besitzt — denn np gilt nur für wirklich inexistente Namen, und ein vergessener Platzhalter-Eintrag kann eine Subdomain für DMARC „existent" machen, sodass sp statt np greift.

Diese beiden Kontrollen von Hand über dig durchzuführen ist mühsam, besonders in einer Organisation mit Dutzenden von Subdomains. Genau hier zeigt ein Analyzer seinen Wert: Er spielt die Perspektive des Empfängers nach, folgt der Vererbung und den eigenen Einträgen und nennt die effektive Policy für jede Ebene des Namensraums. Der Unterschied zwischen „np=reject ist auf der Root veröffentlicht" und „jede Subdomain, existent wie inexistent, ist tatsächlich geschützt" ist genau der Unterschied, den ein Angreifer ausnutzt, wenn nur der erste Satz für wahr gehalten wird.

Zusammengefasst

Die Root auf reject zu bringen, ohne die Subdomains zu regeln, heißt die Eingangstür zu verriegeln und das Fenster offen zu lassen. sp schützt die existierenden Subdomains, np schließt die nicht existierenden — und np ist ein kostenloser Gewinn, den man von Beginn des Rollouts an ergreifen sollte. Zusammen beseitigen sie den Angriffswinkel „über die Seite", der eine ansonsten gelungene DMARC-Migration zu oft überlebt. Der Reflex, den man sich merken sollte, ist einfach: Bei jeder Härtung einer Root werden sp und np gleich mitgesetzt, wie zwei untrennbare Handgriffe — die Root allein ist nie ein vollständiger Schutz.

Um zu prüfen, dass Root und Subdomains korrekt abgedeckt sind — einschließlich der nicht existierenden Fälle —, genügt die Eingabe der Domain in den kostenlosen DMARC-Analyzer: Er zeigt die effektive Policy von außen betrachtet, genau so, wie ein Empfänger (oder ein Angreifer) sie entdecken würde.