Der _dmarc-Eintrag als CNAME: Falle oder legitime Praxis?

Von Thomas · virtueller CISO · 25. August 2026

Die Frage taucht in jedem ernsthaften DMARC-Projekt früher oder später auf, und sie spaltet die Runde: Muss der _dmarc-Eintrag ein TXT sein, direkt in der Zone hinterlegt, oder darf er ein CNAME sein, der woandershin zeigt? Die offiziellen Anleitungen sprechen nur von TXT; trotzdem zeigen völlig funktionierende Zonen an genau dieser Stelle einen Alias, die Post fließt, und die Berichte kommen an. Daher zwei Lager unter DNS-Administratoren: für die einen eine elegante Technik der Bündelung, für die anderen eine Zeitbombe mitten in der Authentifizierung der Domain.

Die ehrliche Antwort hat zwei Teile. Auf der Seite des Standards verbietet nichts den Alias: DMARC stützt sich auf die gewöhnliche DNS-Auflösung, und ein Resolver folgt einem CNAME ohne Zögern — das TXT am Ende der Kette ist maßgeblich, genau so, als wäre es direkt veröffentlicht. Auf der Betriebsseite bringt der Alias dagegen ganz eigene Ausfallmodi mit: keine Koexistenz mit irgendeinem anderen Eintrag am selben Namen, ein Ziel, das lautlos verschwinden kann, Caches, die sich stapeln, und — der strukturell schwerste Punkt — eine Policy, deren Kontrolle in andere Hände übergeht als die des Domain-Inhabers.

Dieser Leitfaden geht zuerst durch die DNS-Mechanik, dann durch die zwei Einsätze, die die Technik wirklich rechtfertigen, durch die dokumentierten Fallen, durch die erhellende Parallele zu den DKIM-Selektoren — wo dieselbe Konstruktion völlige Routine ist — und schließlich durch die Prüfung einer delegierten Kette mit dig.

Was das DNS sagt: ein Alias delegiert den ganzen Namen

Ein CNAME ist nicht „ein Eintrag unter vielen": Er ist eine Erklärung vollständiger Gleichwertigkeit. _dmarc.beispiel.de. CNAME dmarc.gruppe-beispiel.de. zu veröffentlichen heißt, dass der Name _dmarc.beispiel.de selbst keinerlei Daten mehr trägt — für alle Eintragstypen, TXT eingeschlossen, kommt die Antwort vom Ziel. Ein Resolver, der an diesem Namen ein TXT sucht, erhält den Alias, folgt der Kette, fragt dmarc.gruppe-beispiel.de ab und liefert das dort gefundene TXT zurück. Der empfangende Server sieht eine Antwort mit beiden Gliedern, und gelesen wird am Ende die Policy vom Ende der Kette.

Von der DMARC-Seite spricht nichts dagegen. Die aktuelle Spezifikation (DMARCbis, RFC 9989) weist die Empfänger an, per Standard-DNS-Auflösung ein TXT unter _dmarc.<domain> abzufragen — und die Standard-Auflösung folgt nun einmal den Aliassen. Gmail, Microsoft 365 oder jeder korrekt geschriebene MTA wendet die am Kettenende gefundene Policy also genau so an, als stünde sie direkt in der Zone. Unverändert bleibt allein die Anforderung an den finalen Inhalt: ein einziges TXT v=DMARC1; p=…, dessen Syntax denselben strengen Regeln gehorcht wie bei einem ohne Umweg veröffentlichten Eintrag — ein fehlerhaftes Tag am Ende eines Alias bleibt ein fehlerhaftes Tag.

Noch eine Invariante: Die Grenze liegt nicht dort, wo die Intuition sie vermutet. Das DNS toleriert Alias-Ketten (einen CNAME, der auf einen weiteren CNAME zeigt), aber jedes zusätzliche Glied fügt eine Abfrage, einen Cache und eine mögliche Bruchstelle hinzu. In der Praxis ist ein einziger Sprung die vernünftige Norm; darüber hinaus geben manche vorsichtigen Resolver unterwegs auf, und die Fehlersuche wird mühsam.

Zwei legitime Einsätze: delegierter Kollektor und zentrale Flotte

Die Delegation an einen Berichtskollektor. Manche Analyseplattformen bieten an, _dmarc auf einen Namen unter ihrer eigenen Kontrolle zeigen zu lassen. Der Nutzen ist operativ: Die Plattform veröffentlicht die Policy, justiert die rua-Adresse, an die die aggregierten Berichte gehen, korrigiert ein Tag und führt p=none im Takt der Remediation über p=quarantine zu p=reject — ohne je wieder ein DNS-Ticket beim Kunden zu eröffnen. Für eine Organisation, deren DNS-Team überlastet oder ausgelagert ist, verändert der Wegfall dieser Schleifen das Tempo des ganzen Projekts. Ein technisches Detail erledigt sich nebenbei: Da die Berichte an die Domain des Kollektors gehen, liegt die Freigabe des externen Ziels (beispiel.de._report._dmarc.kollektor.example) beim Kollektor selbst, der sie in der Regel als Wildcard veröffentlicht.

Eine Domain-Flotte aus einer zentralen Zone. Ein Konzern mit fünfzig Domains — Marken, Tochtergesellschaften, defensive Varianten, die nie eine einzige Nachricht versenden werden — kann jedes _dmarc auf einen kleinen Satz zentraler Einträge zeigen lassen: einen für versendende Domains, einen für geparkte (v=DMARC1; p=reject; rua=mailto:berichte@gruppe-beispiel.de). Die Verschärfung der gesamten Flotte wird damit zu einer einzigen Änderung in einer einzigen Zone, statt fünfzig Tickets in fünfzig verschiedenen Oberflächen. Das Prinzip gleicht einer internen PKI: Die sensible Angabe lebt an genau einem Ort, und die Konsumenten referenzieren sie. Vorlagen für Domains, die nichts versenden, finden sich unter den kommentierten Beispielen.

Die Fallen: Exklusivität, verschwundenes Ziel, gestapelte Caches, störrische Oberflächen

Ein CNAME koexistiert mit nichts. Die DNS-RFCs sind kategorisch: Ein Name, der einen Alias trägt, darf keinen weiteren Eintrag tragen. Ein zweites TXT auf _dmarc — ein Verifizierungstoken eines Drittanbieter-Tools, ein temporärer Testeintrag — ist damit schlicht unmöglich. Gute Oberflächen verweigern das Anlegen; schlechte akzeptieren es und erzeugen eine Zone, deren Verhalten davon abhängt, welcher Server gerade antwortet. An dem Tag, an dem ein Dienstleister „ein TXT auf _dmarc" zur Validierung verlangt, erzwingt der Alias den Umweg über das Ziel.

Das Ziel, das verschwindet. Das heimtückischste Szenario. Ein gekündigtes Abonnement beim Kollektor, eine bei einer Migration gelöschte zentrale Zone, ein Tippfehler im Ziel: _dmarc.beispiel.de löst fortan zu NXDOMAIN auf, und die Policy verdunstet — ohne jede Warnung, denn sichtbar bricht nichts. Die legitime Post fließt weiter; es gibt nur schlicht keine Policy mehr, die die Empfänger anwenden könnten, Spoofing wird wieder möglich, und die Anforderungen der großen Anbieter an Massenversender sind nicht mehr erfüllt. Eine Nuance aus DMARCbis: Bei einer Subdomain steigt der Tree Walk die Hierarchie hinauf und landet auf der Policy der organisatorischen Domain — ein teilweises Sicherheitsnetz. Für die organisatorische Domain selbst fängt nichts den Sturz auf. Das sichtbare Symptom kommt oft erst Wochen später, wenn jemandem auffällt, dass die Berichte plötzlich ausbleiben.

TTLs stapeln sich. Eine delegierte Kette hält zwei Einträge am Leben, also zwei TTLs und zwei unabhängige Caches. Eine am Ziel vorgenommene Policy-Änderung verbreitet sich nach dem TTL des Ziels, aber der Alias selbst bleibt bei den Resolvern im Cache: Die reale Verzögerung wird schwerer vorhersagbar als bei einem direkten TXT, und ein sehr langes TTL an einem der Glieder kann eine Verschärfung ausbremsen — oder, gravierender, einen Notfall-Rollback.

Störrische Oberflächen. Das letzte Hindernis ist prosaisch: Manche DNS-Verwaltungen für Endkunden verweigern einen CNAME auf einem Namen mit führendem Unterstrich oder validieren _dmarc ausschließlich als TXT. Der Ausweg führt über den rohen Zoneneditor oder die API, wo es sie gibt — und wo nicht, ist die Konstruktion bei diesem Anbieter schlicht nicht verfügbar.

Eine Policy in fremden Händen

Die bisherigen Fallen waren technischer Natur; diese ist eine Frage der Governance, und sie wiegt schwerer. Ein Alias auf einen Namen unter fremder Kontrolle bedeutet, diesem Dritten die Befugnis zu übergeben, die DMARC-Policy der Domain zu schreiben. Was das Ziel veröffentlicht, wenden die Empfänger an: ein stillschweigend auf p=none gelockertes p=reject, eine umgeleitete rua-Adresse, ein geändertes sp=-Tag — all das wird möglich, ohne dass in der Zone des Domain-Inhabers auch nur eine einzige Änderung sichtbar würde. Die Zone des Dienstleisters wird zugleich zur Angriffsfläche: ihre Kompromittierung ist die Kompromittierung der Policy aller seiner Kunden auf einen Schlag.

Das Raster ist einfach. Ein Alias auf eine Zone derselben Organisation (die zentrale Zone des Konzerns) bündelt, ohne Souveränität abzugeben: Die Kontrolle bleibt im Haus, nur der Ort ändert sich. Ein Alias auf einen Dritten ist dagegen eine echte Delegationsentscheidung und verdient dieselbe Behandlung wie jedes Outsourcing: eine Vertragsklausel zur Reversibilität, eine unabhängige Überwachung dessen, was das Ziel tatsächlich veröffentlicht, und ein getesteter Ausstieg — denn am Tag des Abschieds besteht die Rückeroberung darin, den Alias durch ein direktes TXT zu ersetzen, und dafür muss der richtige Inhalt bekannt sein.

Die DKIM-Parallele: Routine bei Selektoren, umstritten bei _dmarc

Die Ironie der Debatte: Dieselbe Konstruktion wird täglich praktiziert, ohne dass irgendjemand die Stirn runzelt — auf der DKIM-Seite. Das Anbinden eines E-Mail-Routers läuft fast immer über Selektor-CNAMEs: s1._domainkey.beispiel.de zeigt auf einen Namen bei SendGrid, Mailjet, Brevo oder Amazon SES, der den öffentlichen Schlüssel veröffentlicht und ihn ohne Zutun des Kunden rotiert. Diese delegierte Rotation gilt sogar als Sicherheitsargument: Die Schlüssel wechseln öfter, als wenn jeder Kunde seine eigene Zone editieren müsste.

Warum geht dieselbe Technik dort ohne Debatte durch und sorgt hier für gerunzelte Stirnen? Weil die Tragweite nicht vergleichbar ist. Ein DKIM-Selektor ist technisches Material, an einen einzelnen Versandfluss gebunden, einzeln widerrufbar und einer unter mehreren: Sein Ausfall oder seine Kompromittierung beschädigt einen Fluss, nicht die Domain. Der _dmarc-Eintrag ist dagegen einzigartig und regelt die Behandlung der gesamten Post der Domain — und über sp und den Tree Walk auch die ihrer Subdomains. Einen Selektor zu delegieren heißt, einen Wohnungsschlüssel auszuhändigen; _dmarc zu delegieren heißt, den Generalschlüssel des Gebäudes zu übergeben. Gleiche Technik, anderes Gewicht — daher andere Anforderungen an das Vertrauen.

Wann das direkte TXT die bessere Wahl bleibt

Die praktische Schlussfolgerung ergibt sich von selbst. Das direkte TXT bleibt in den meisten Lagen der Standard: eine oder zwei Domains, eine stabile Policy, die sich dreimal im Leben einer Domain ändert, ein Team, das seine Konfiguration in der eigenen Zone lesen will, ohne einer Kette folgen zu müssen. Der Alias brächte dort keine echte Ersparnis und fügte nur ein weiteres bewegliches Teil hinzu.

Der CNAME verdient seinen Platz in zwei bewusst gewählten Fällen: die große Flotte, gesteuert aus einer zentralen Zone derselben Organisation — der operative Gewinn ist massiv, die Souveränität bleibt intakt — und die bewusste, als solche dokumentierte Delegation an einen Dienstleister, mit Überwachung und Ausstiegstür. Dazwischen passt die Regel in einen Satz: Der Alias ist ein Werkzeug für Skalierung und Delegation, keine Standardeinstellung; im kleinen Maßstab und ohne Delegationsbedarf hat er nur Nachteile.

Eine delegierte Kette mit dig prüfen

Die Prüfung passt in zwei Befehle. Der erste folgt der Kette so, wie ein Empfänger es täte:

$ dig +short _dmarc.beispiel.de TXT
dmarc.gruppe-beispiel.de.
"v=DMARC1; p=reject; rua=mailto:berichte@gruppe-beispiel.de"

Die erste Zeile zeigt den Alias, die zweite das am Ende gelesene TXT: Genau diesen Wert wenden die Empfänger an. Der zweite Befehl isoliert jedes Glied: dig +short _dmarc.beispiel.de CNAME bestätigt das exakte Ziel, dann fragt dig +short dmarc.gruppe-beispiel.de TXT das Ziel direkt ab. Die Kontrollpunkte: eine Kette mit einem einzigen Sprung, ein Ziel, das mit genau einem TXT antwortet, das mit v=DMARC1 beginnt, kein Fremdeintrag am selben Namen und vernünftige TTLs auf beiden Seiten. Ein NXDOMAIN an irgendeinem Glied bedeutet verdunstete Policy — ein Fall für sofortige Korrektur, nicht für gemächliche Analyse. Und weil die Kette auf der Zielseite brechen kann, ohne dass sich in der eigenen Zone der Domain irgendetwas geändert hätte, schlägt eine automatisierte, periodische Prüfung jede einmalige Kontrolle zum Zeitpunkt der Einrichtung.

Fazit

Ein _dmarc als CNAME ist weder Ketzerei noch eine harmlose Einstellung. Das DNS erlaubt es vollständig: Der Alias delegiert den ganzen Namen, die Auflösung folgt der Kette, und das am Ende gelesene TXT ist für jeden Empfänger maßgeblich. Zwei Einsätze rechtfertigen es — die Delegation an einen Berichtskollektor und die Verwaltung einer Flotte aus einer zentralen Zone. Dem stehen vier dokumentierte Fallen gegenüber: die Exklusivität des CNAME, die jeden weiteren Eintrag am selben Namen verbietet; das Ziel, das verschwinden und die Policy ohne Alarm mitnehmen kann; die TTLs, die sich stapeln; und DNS-Oberflächen, die die Konstruktion ablehnen. Entscheidend bleibt die Governance: Ein Alias auf die eigene zentrale Zone bündelt, ohne etwas abzugeben; ein Alias auf einen Dritten delegiert die Befugnis, die Policy zu schreiben, und gehört wie ein Outsourcing behandelt. Im kleinen Maßstab behält das direkte TXT alle seine Vorteile.

Um die Frage für eine konkrete Domain zu klären, folgt die kostenlose DMARC-Analyse den CNAME-Ketten genau so, wie es ein empfangender Server täte, und zeigt die am Ende tatsächlich gelesene Policy — Alias inklusive, Glied für Glied. Und wenn eine ganze Flotte auf dieser Konstruktion ruht, hält ein neu angelegtes Konto jedes Glied unter dauerhafter Beobachtung: Ein verdunstendes Ziel fällt dann innerhalb von Stunden auf, nicht erst in dem Moment, in dem die erste gefälschte Nachricht den Namen der Domain trägt.