Viele Marken, viele Domains: DMARC-Governance im großen Maßstab

Von Thomas · virtueller CISO · 30. August 2026

Ein Konzern mit dreißig Marken, zweihundert Domains und autonomen Marketingteams, die ihre Werkzeuge auswählen, ohne irgendjemanden zu fragen: In dieser Größenordnung ändert die E-Mail-Authentifizierung ihre Natur. Auf einer einzelnen Domain ist DMARC ein technisches Projekt — einige Wochen Beobachtung, eine Remediation, eine verschärfte Policy. Über einen ganzen Bestand hinweg ist es ein Governance-Programm: Ohne Inventar, ohne benannte Verantwortliche, ohne Eingangsprozess zerfällt jede korrekte Konfiguration genau in dem Tempo, in dem die Marken neue Versandverträge unterschreiben.

Die Symptome sind leicht zu erkennen. Ein vorbildliches p=reject auf der historischen Domain und gar nichts auf den Domains der Tochtergesellschaften; defensive Domains, gekauft, um die Marken zu schützen, und sperrangelweit offen gelassen; eine E-Mail-Plattform, an einem Freitag von einer Agentur angeschlossen, die das Alignment einer ganzen Marke bricht; ein zentrales Sicherheitsteam, das von der Existenz einer Domain an dem Tag erfährt, an dem diese gefälscht wird. Keines dieser Probleme ist kryptografischer Natur. Alle sind organisatorisch.

Dieser Leitfaden entfaltet die Methode, die im großen Maßstab trägt: eine Typologie des Bestands mit einer Ziel-Policy pro Kategorie, ein organisatorisches Fundament — Register, Verantwortliche, Prozess —, ein industrialisiertes DNS, eine p=reject-Trajektorie in Wellen, Steuerungskennzahlen, und was DMARCbis nebenbei für die Subdomains vereinfacht.

Das Skalenproblem: Authentifizierung überlebt keine Improvisation

Die Schwierigkeit wächst nicht linear mit der Anzahl der Domains; sie wächst mit der Anzahl der dezentralen Entscheidungen. Jede Marke hat ihre Agentur, ihr CRM, ihre Marketingplattform, manchmal einen eigenen Registrar aus einer früheren Übernahme. Zweihundert Domains, multipliziert mit jeweils einer Handvoll Versanddienstleister, ergeben ein Ökosystem, das niemand vollständig kennt — und DMARC bestraft genau das, was die Organisation nicht weiß: Eine legitime Quelle, die in SPF fehlt oder ohne ausgerichtete DKIM-Signatur versendet, wird in dem Moment zum falschen Positiv, in dem die Policy verschärft wird.

Das Inventar der Drittversender ist der Gründungsakt auf der Ebene einer einzelnen Domain. Auf Konzernebene ist ein einmaliges Inventar schon im Folgemonat veraltet: Es muss zu einem dauerhaften Prozess werden, gestützt auf ein Register und auf Eingangsregeln. Genau das ist der Unterschied zwischen einem Audit und einer Governance — das eine fotografiert, die andere verhindert die Drift. Der Rest der Methode folgt aus dieser Feststellung.

Die Typologie des Bestands: vier Kategorien, vier Ziel-Policies

Zweihundert Domains einzeln zu behandeln ist unbeherrschbar. Werden sie in Kategorien sortiert, wird das Problem endlich, denn jede Kategorie verlangt eine einzige Ziel-Policy — und die Entscheidung fällt dann einmal pro Kategorie, nicht zweihundertmal.

Aktive Versanddomains. Diejenigen, die tatsächlich Post tragen: die Hauptmarke, Newsletter, Transaktionsflüsse, Rechnungsstellung. Oft eine Minderheit des Bestands, und die einzige Kategorie, die echte Remediationsarbeit verlangt. Ziel: SPF und DKIM für jeden Dienstleister ausgerichtet, dann p=reject.
Defensive Markendomains. Tippfehlervarianten, andere Endungen, eingetragene Marken ohne Website: registriert, damit kein Dritter zugreift, und niemals für den Versand vorgesehen. Sofortiges Ziel: vollständige Sperrung, ohne Beobachtungsphase — es gibt nichts zu beobachten.
Geparkte oder ruhende Domains. Beendete Kampagnen, aufgegebene Projekte, Namen „für alle Fälle". Dieselbe Sperrung wie bei den defensiven, mit einer Nuance: eine dokumentierte Reaktivierungsprozedur für den Tag, an dem das Marketing einen Namen wieder aus der Schublade holt.
Technische Domains. Bounce-Domains, Tracking-Domains, Infrastruktur-Subdomains: gelegentlich versendend, aber unter der Kontrolle eines identifizierten Dienstleisters. Ziel: explizit abgedeckt, entweder durch die Policy der Organisationsdomain oder durch eigene Einträge — niemals „vergessen, weil technisch".

Die Sperrung einer Domain, die nichts versendet, passt in drei Einträge:

beispiel.net.          MX    0 .
beispiel.net.          TXT   "v=spf1 -all"
_dmarc.beispiel.net.   TXT   "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:berichte@beispiel.de"

Die vollständige Begründung — warum ausgerechnet eine Domain, die nichts versendet, die strengste Policy verdient — wird in dem Schutz geparkter Domains entwickelt. Auf Bestandsebene ist diese Kategorie ein Glücksfall: Ein großer Teil des Weges zu einem „alles auf reject"-Bestand lässt sich ohne jedes Risiko zurücklegen, denn es gibt nichts, was kaputtgehen könnte.

Das organisatorische Fundament: ein Register, Verantwortliche, ein Prozess

Das Herzstück der Governance ist kein DNS-Eintrag, sondern ein zentrales Domain-Register. Für jeden Eintrag: der Name, die Kategorie aus der Typologie, der Registrar, die DNS-Zone, die ihn hostet, die aktuelle Policy, die Ziel-Policy, die Liste der autorisierten Versanddienstleister und das Datum der letzten Überprüfung. Das Werkzeug ist zweitrangig — eine Tabelle genügt für den Anfang —, solange es einzigartig, aktuell und verbindlich ist: Was nicht im Register steht, existiert offiziell nicht, und was existiert, ohne im Register zu stehen, ist eine zu behandelnde Anomalie.

Zweite Säule: ein benannter Verantwortlicher pro Domain. Eine Person, nicht „das Marketingteam" — Teams werden umorganisiert, Personen beantworten E-Mails. Der Verantwortliche genehmigt eine Reaktivierung, bestätigt, dass ein Dienstleister noch unter Vertrag steht, und beantwortet innerhalb von vierundzwanzig Stunden die Frage „ist diese Quelle legitim?", wenn eine unbekannte IP in den Berichten auftaucht.

Dritte Säule: der Prozess „neues Versandwerkzeug". Niemand — keine Marke, keine Agentur, keine eilige Tochtergesellschaft — schließt eine E-Mail-Plattform an, ohne durch das Register zu gehen. Die Sequenz ist kurz: das Werkzeug anmelden, die DKIM-Schlüssel und das SPF-Include veröffentlichen, das Alignment an einer Stichprobe testen, den Eintrag im Register anlegen, und erst dann echten Verkehr senden. Mailchimp, Brevo und SendGrid dokumentieren alle die DKIM-Delegation: Der Schritt kostet wenige Tage, wenn er eingeplant ist, und Wochen an falschen Positiven, wenn er erst im Nachhinein entdeckt wird. Dieser Prozess ist die einzige dauerhafte Antwort auf die Schatten-IT des Marketings.

Das Register lebt außerdem im Takt des Bestands: Eine Fusion oder Übernahme bringt Domains im Dutzend, samt Geschichte und Überraschungen; ein schlecht überwachtes Auslaufen überlässt einen Markennamen dem Erstbesten; eine Reaktivierung ohne Prozedur öffnet eine sorgfältig verriegelte Tür wieder. Jedes Lebenszyklusereignis läuft über das Register — oder die Governance verkommt zu toter Dokumentation.

Industrialisiertes DNS: zentrale Zonen, kontrollierte Delegation

Eine Governance, die auf zweihundert manuellen Änderungen bei fünf verschiedenen Registraren beruht, überlebt ihr zweites Jahr nicht. Die Industrialisierung beginnt mit der Zentralisierung der Zonen: ein primärer DNS-Hoster, Änderungen als Code verwaltet (Infrastructure as Code, Peer-Review, Änderungsjournal), und das Ende der über die Marken verstreuten Registrar-Zugänge.

Zentralisierung verbietet keine Autonomie: Die kontrollierte Delegation lässt den Marken die Hand über ihren Webauftritt — delegierte Subdomains, die A- und CNAME-Einträge ihrer Websites —, während die Authentifizierungseinträge (_dmarc, DKIM-Selektoren, SPF-Includes) in der Kontrollzone des Konzerns bleiben. Die Grenze ist sauber: Das Web wird delegiert, die Absenderidentität nicht.

Das mächtigste Werkzeug von allen ist der CNAME auf eine Kontrollzone. Statt zweihundert individuelle Policies zu veröffentlichen, zeigt jeder _dmarc-Eintrag auf eine kleine Zahl von Standard-Policies, die an einem einzigen Ort gepflegt werden:

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

Die Sammeladresse der Berichte zu ändern oder eine ganze Domainklasse auf einen Schlag zu verschärfen, wird zu einer einzigen Änderung in einer einzigen Zone. Der Mechanismus ist von den DKIM-Schlüsseln der Dienstleister längst vertraut (ein CNAME in die Zone des ESP); ihn auf die DMARC-Policies auszudehnen ist seine logische Fortsetzung — und genau das macht einen Bestand von zweihundert Domains durch ein kleines Team steuerbar.

Die p=reject-Trajektorie: in Wellen, niemals als Urknall

Zweihundert Domains auf einmal zu verschärfen garantiert einen Vorfall; sie einzeln und ohne Ordnung zu verschärfen garantiert, niemals fertig zu werden. Die vernünftige Trajektorie verläuft in Wellen, jede klein genug, um eng überwacht zu werden, und repräsentativ genug, um die Methode voranzubringen.

Pilotwelle. Zwei oder drei Versanddomains mit überschaubarem Einsatz, getragen von einem willigen Team. Das Ziel ist nicht das geschützte Volumen, sondern der Probelauf: das Werkzeug, die Berichte, die Entscheidungsschleife mit den Verantwortlichen.
Hauptmarken. Der höchste Fälschungswert, aber auch die meisten Dienstleister und damit die längste Remediation. Die im Pilot erprobte Methode wird Domain für Domain angewendet, mit dem bereits geltenden Prozess „neues Werkzeug", damit kein Sand nachrieselt, während das Meer leergeschöpft wird.
Lange Schleppe. Die verbleibenden kleinen Versanddomains, in Serie abgearbeitet mit einer inzwischen erprobten Checkliste.

Parallel dazu, und vom ersten Tag an, gehen die defensiven und geparkten Domains direkt in die Sperrung — es gibt keinen Grund zu warten. Jede Welle folgt demselben Zyklus: p=none und Beobachtung, Alignment-Korrekturen, Testmodus per t=y-Tag (der die alte schrittweise Steigerung über pct ersetzt), dann p=reject. Auf einer sauberen Domain ist der Zyklus kurz, auf einer geschichtsträchtigen lang; diese Varianz fängt die Welle auf, nicht der Gesamtkalender.

Die Steuerungskennzahlen

Ein mehrjähriges Programm ohne Kennzahlen stirbt beim ersten Prioritätenwechsel. Wenige Messgrößen genügen, sofern sie regelmäßig verfolgt werden.

Der Anteil des Bestands auf p=reject — die Leitkennzahl, für einen Vorstand ohne eine einzige Zeile technischer Erklärung lesbar. Der Quartalsverlauf dieser Kennzahl erzählt das ganze Programm.
Die Registerabdeckung: die Lücke zwischen deklarierten und entdeckten Domains (periodische Scans der Zonen, der Zertifikate, der Markenanmeldungen). Eine wachsende Lücke signalisiert eine umgangene Governance.
Nicht ausgerichtete Dritte: die Zahl der Dienstleister, die ohne SPF- oder DKIM-Alignment versenden, pro Marke. Das ist das direkte Maß der verbleibenden Remediationsarbeit.
Unbekannte Quellen: Alarme zu IPs, die für eine gegebene Domain nie zuvor gesehen wurden, und die Zeit, die der Verantwortliche für die Einordnung braucht.
Wellengeschwindigkeit: die mediane Zeit von p=none bis p=reject pro Domain, die eine ehrliche Hochrechnung des Programmendes erlaubt.

Der klassische Fehler ist, nach E-Mail-Volumen statt nach Domainzahl zu steuern: Ein Bestand, dessen drei volumenstarke Domains auf p=reject stehen, während hundertsiebzig andere offen bleiben, ist nicht geschützt — der Fälscher wählt immer die offene Tür.

Was DMARCbis für die Subdomains vereinfacht

Der aktuelle Standard, DMARCbis, bringt zwei Änderungen mit, die gerade auf Bestandsebene zählen. Die erste ist der DNS Tree Walk: Die Policy-Ermittlung steigt nun den DNS-Baum hinauf, statt sich auf die Public Suffix List zu stützen. Zwischengeschaltete Policy-Punkte werden möglich — ein Konzern kann eine Policy auf Markenebene veröffentlichen und die darunterliegenden Subdomains sauber abdecken, ohne Einträge zu duplizieren und ohne von einer externen Liste abzuhängen, die von der internen Struktur des Konzerns nichts wusste.

Die zweite ist das np-Tag, die Policy für nicht existierende Subdomains. Damit lässt sich der Phantom-Namensraum sofort schließen — die Subdomains, die niemand je angelegt hat, die aber jeder in einem From:-Header beschwören kann —, ohne zu warten, bis die realen Subdomains für die Verschärfung bereit sind:

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

Zusammen mit dem Testmodus t=y als Ersatz für pct ergibt sich eine feinere und lesbarere Kontrolle über die Nachkommenschaft jeder Domain als zuvor. Das vollständige Zusammenspiel zwischen der Policy der Organisationsdomain, sp und np wird in dem Leitfaden zur Subdomain-Policy ausgeführt — nützliche Lektüre, bevor die Standard-Policies der Kontrollzone festgelegt werden.

Fazit

Auf der Ebene eines Konzerns mit vielen Marken hört DMARC auf, ein technisches Projekt zu sein, und wird zu einem Governance-Programm. Die Typologie des Bestands — aktiv, defensiv, geparkt, technisch — liefert eine Ziel-Policy pro Kategorie; das zentrale Register, die benannten Verantwortlichen und der Prozess „neues Versandwerkzeug" verhindern die Drift; das zentralisierte DNS und die CNAMEs auf eine Kontrollzone machen den Bestand steuerbar; die Trajektorie in Wellen erreicht p=reject ohne Urknall; der Anteil des verschärften Bestands und die nicht ausgerichteten Dritten messen den Fortschritt; und DMARCbis vereinfacht mit dem Tree Walk und dem np-Tag, was auf der Subdomain-Seite mühsam geblieben war.

Der Einstiegspunkt verlangt seinerseits gar kein Programm: Ein Durchlauf der Schlüsseldomains des Bestands durch eine kostenlose DMARC-Analyse stellt in Minuten den Anfangszustand des Registers fest — veröffentlichte Policies, sichtbare Quellen, Löcher im Netz. Die Eröffnung eines Kontos erlaubt anschließend, alle zweihundert Domains an einem Ort zu verfolgen und die Wellen auszurollen, bis zu dem Tag, an dem die Leitkennzahl einen Bestand vollständig auf p=reject anzeigt.