DMARCbis bringt eine neue Verteidigung gegen Subdomain-Spoofing

DMARCbis, die erste vollständige Überarbeitung des DMARC-Standards seit 2015, ist jetzt offiziell. Die Spezifikation wurde am 19. Mai 2026 als drei neue RFCs veröffentlicht (9989, 9990 und 9991), ersetzt RFC 7489 und hebt DMARC auf den IETF-Standards-Track. Der größte Teil der Änderung erfordert keine sofortige Reaktion, aber es gibt eine Ergänzung, bei der sich Handeln lohnt: einen neuen Tag namens np=, der eine Lücke beim Subdomain-Spoofing schließt, die der alte Standard offenließ.

DMARC ist der Standard, der empfangenden Servern sagt, wie sie mit Mails umgehen sollen, die die Authentifizierungsprüfungen nicht bestehen. Wenn Sie DMARC bereits auf p=quarantine oder p=reject betreiben, beschädigt die Verabschiedung von DMARCbis nichts, was Sie veröffentlicht haben. Die leiseren Änderungen, darunter die Entfernung des pct-Tags und die Abkehr von der Public Suffix List, behandelt unser verständlicher Leitfaden dazu, was DMARCbis für Sie bedeutet. In diesem Artikel geht es um die eine Ergänzung, bei der sich Handeln heute lohnt.

Klicken Sie auf die Links, um direkt zu einem Abschnitt zu springen.

• Was DMARCbis offiziell gemacht hat
• Wo der sp=-Tag zu kurz greift
• Was leistet der np=-Tag?
• Was hat sich mit der Verabschiedung von DMARCbis sonst geändert?
• Was sollten Sie jetzt tun?
• Das Fazit

Was DMARCbis offiziell gemacht hat

DMARCbis ist kein einzelnes Dokument. Es wurde als drei getrennte RFCs veröffentlicht, von denen jeder einen Teil des Standards abdeckt:

• RFC 9989 definiert das Kernprotokoll: wie Policies veröffentlicht werden, wie die Ausrichtung bewertet wird und wie ein Empfänger einen DMARC-Eintrag verarbeitet.
• RFC 9990 definiert das Format der aggregierten Berichte, also die täglichen XML-Zusammenfassungen, die Ihre Domain erhält.
• RFC 9991 definiert das Failure-Reporting (forensische Berichte pro Nachricht).

Zusammen ersetzen diese RFCs RFC 7489, die Spezifikation von 2015, die DMARC bis jetzt definiert hat. Sie heben außerdem den Status des Standards an, und an diesem Punkt lohnt sich Genauigkeit. RFC 7489 war als Informational eingestuft, was bedeutet, dass es DMARC dokumentierte, ohne die Standards-Track-Bestätigung der IETF zu tragen. DMARCbis wird als Proposed Standard veröffentlicht, der benannte Reifegrad, den die IETF einem verabschiedeten Standards-Track-Dokument zuweist. Trotz des Wortes "Proposed" ist dies ein fertiger, offizieller Standard und kein Entwurf oder Work in Progress, und es ist die Einstiegsstufe des Standards-Tracks, über die viele weitverbreitete Internetprotokolle nie hinausgehen. In der Praxis signalisiert dies Reife, nicht eine neue Pflicht. Es gibt dem Standard festeren Boden in Beschaffungs- und Compliance-Kontexten, in denen ein Informational-Dokument Fragen aufwarf, verlangt aber noch nicht, dass Sie einen Eintrag anfassen, der bereits funktioniert.

Wo der sp=-Tag zu kurz greift

Mit DMARC können Sie eine Policy für Ihre Hauptdomain (der p=-Tag) und eine separate Policy für Ihre Subdomains (der sp=-Tag) festlegen. Der Haken: sp= regelt nur Subdomains, die in Ihrem DNS existieren. Über Subdomains, die nie angelegt wurden, sagt der Tag nichts aus.

Genau das ist die Lücke, die Angreifer nutzen. Ein Betrüger kann Mails von accounting.yourbrand.com oder payroll.yourbrand.com versenden, also von Adressen, die Sie nie eingerichtet haben und für die es überhaupt keine DNS-Einträge gibt. Weil diese Subdomain das zurückgibt, was die DNS-Welt eine NXDOMAIN-Antwort nennt (kein solcher Name), behandelten manche Empfänger das Fehlen eines Eintrags früher als das Fehlen einer Policy und ließen die Nachricht durch.

Die meisten Domains lassen diese Lücke offen. Im DMARCeye-Branchenbericht Q1 2026 deklarieren selbst Domains mit voller Durchsetzung (p=reject) zu 65,15 % keinerlei Subdomain-Policy. Bei p=none liegt der Wert bei 86,67 %. Eine Domain kann auf der obersten Ebene abgeriegelt sein und Angreifern trotzdem eine offene Tür eine Beschriftung weiter links bieten.

Die vollständige Aufschlüsselung der Subdomain-Policies findet sich neben dem Rest des Q1-2026-Datensatzes im Bericht:

Was leistet der np=-Tag?

Der np=-Tag legt eine DMARC-Policy speziell für nicht existierende Subdomains fest, also für jede Subdomain, die keine DNS-Einträge zurückgibt. Er ist die fehlende Hälfte von sp=.

Ist np= veröffentlicht, folgt ein Empfänger, der eine Mail von einer erfundenen Subdomain bewertet, einer klaren Reihenfolge. Er prüft zuerst auf eine np=-Policy. Ist keine gesetzt, fällt er auf sp= zurück. Fehlt auch diese, fällt er auf die Haupt-Policy p= zurück. Der neue Tag beseitigt die Mehrdeutigkeit, die zuvor gefälschte Subdomain-Mails durchschlüpfen ließ.

Für die meisten Domains ist np=reject der richtige Wert. Eine Subdomain, die nicht existiert, versendet keine legitimen Mails, also kostet es Sie nichts, alles abzulehnen, was angeblich von ihr kommt, und es verschließt einer ganzen Klasse von Impersonation die Tür. Ein Eintrag, der bereits v=DMARC1; p=reject; lautet, wird mit einer einzigen Ergänzung zu v=DMARC1; p=reject; np=reject;. Dieselbe Logik gilt über sp= für existierende Subdomains, und unser Leitfaden zum sp=-Subdomain-Policy-Tag erklärt, wann Sie welchen setzen.

np= hilft allerdings erst, wenn ein Empfänger den Tag berücksichtigt. Als brandneuer Tag wird seine Unterstützung erst nach und nach über die Mailbox-Anbieter ausgerollt, daher ist die Veröffentlichung jetzt eher eine vorausschauende Absicherung als eine sofortige Lösung.

Geben Sie Ihre Domain ein, um den DMARC-Eintrag zu sehen, den Sie heute veröffentlichen, einschließlich eines eventuell bereits gesetzten sp=- oder np=-Tags:

Was hat sich mit der Verabschiedung von DMARCbis sonst geändert?

Zwei weitere Änderungen runden die Aktualisierung ab, auch wenn keine von beiden heute viel von Ihnen verlangt.

Der pct-Tag ist weggefallen. Er sollte es Ihnen ermöglichen, eine Policy schrittweise auf einen Teil Ihrer Mails anzuwenden, doch Empfänger setzten ihn uneinheitlich um. Im DMARCeye-Datensatz Q1 2026 ignorierten ihn bereits 94,11 % der p=quarantine-Domains und 93,51 % der p=reject-Domains und setzten von Tag eins an mit voller Stärke durch. DMARCbis ersetzt ihn durch einen einfacheren t=-Flag (Testing). Die vollständige Erklärung, warum der gestaffelte Dimmer nie funktionierte, steht in unserem Leitfaden dazu, was DMARCbis für Sie bedeutet.

DMARC stützt sich außerdem nicht mehr auf die Public Suffix List, um zu bestimmen, wo die Domain-Grenze einer Organisation liegt. Es geht jetzt direkt das DNS durch. Inhaber einzelner Domains werden den Unterschied nicht bemerken. Betreiber großer Subdomain-Bestände sollten prüfen, dass ihre Einträge weiterhin so aufgelöst werden, wie sie es erwarten.

Was sollten Sie jetzt tun?

Wie wichtig np= für Sie ist, hängt davon ab, was Sie betreiben.

Wenn Sie eine einzelne Domain betreiben oder ein kleines Unternehmen führen: np=reject hinzuzufügen ist eine einzeilige Änderung ohne Nachteil, und sie schließt einen Impersonation-Weg, der nicht davon abhängt, dass Sie sich an jede Subdomain erinnern, die Sie je angelegt haben. Wenn Sie Ihr DNS nicht selbst verwalten, ist das eine Aufgabe für die zuständige Stelle: meist Ihr Domain-Registrar (das Unternehmen, bei dem Sie die Domain gekauft haben, etwa GoDaddy oder Namecheap), Ihr Webhoster oder der IT-Dienstleister oder die Agentur, die Ihre E-Mail eingerichtet hat. Schicken Sie ihnen den Eintrag, der veröffentlicht werden soll, v=DMARC1; p=reject; np=reject;, und bitten Sie sie, ihn auf Ihrer Domain hinzuzufügen oder zu aktualisieren.

Wenn Sie einen E-Commerce-Shop oder Marketing-Domains betreiben: Gefälschte Subdomains sind ebenso ein Problem für das Markenvertrauen wie für die Sicherheit, denn eine überzeugende billing.yourbrand.com landet in Kundenpostfächern und sieht genau wie Sie aus. Kombinieren Sie np=reject mit aktivem Monitoring, damit Sie sehen, welche Quellen unter Ihrer Domain senden, bevor Sie irgendetwas verschärfen. Der kostenlose Plan von DMARCeye deckt eine Domain mit vollständiger Berichtsverarbeitung ab, und das reicht für den Anfang.

Wenn Sie eine Agentur oder ein MSP sind: np=reject ist ein schneller, gut begründbarer Gewinn, den Sie über jede von Ihnen verwaltete Kundendomain ausrollen können. DMARCeye trennt jedes Kundenkonto strikt voneinander, sodass Ihr Team den Subdomain-Status über ein ganzes Portfolio hinweg aus einer Konsole verfolgen kann, während jeder Kunde nur seine eigenen Daten sieht.

Wenn Sie eine Unternehmens-Mailinfrastruktur betreiben: Behandeln Sie np= als Teil der Subdomain-Governance. Erfassen Sie, welche Geschäftsbereiche welche Subdomains besitzen, setzen Sie sp= für die, die legitim senden, und setzen Sie np=reject für alles andere, während Sie die Änderung in Ihren nächsten DMARC-Review aufnehmen.

Das Fazit

Dass DMARCbis zum offiziellen Standard wird, erzwingt keine Änderung an einem DMARC-Eintrag, der bereits funktioniert. Was es leistet, ist die Formalisierung einer Lösung für eine Lücke, die die meisten Domains noch offenlassen: die gefälschte, nie angelegte Subdomain. Der np=-Tag ist der neue Hebel, und np=reject ist für die meisten Domains der sichere Standardwert. Der einzige Weg, um zu wissen, ob Sie ihn brauchen, ist, sich anzusehen, was Ihre Domain heute veröffentlicht.

Genau für diese Sichtbarkeit ist DMARCeye gebaut. Es liest die DMARC-Berichte aus, die Ihre Domain erhält, und zeigt Ihnen in klarer Sprache, welche Quellen unter Ihrem Namen senden und wo Ihre Policy Sie angreifbar lässt.