DMARC, SPF und DKIM in Cloudflare DNS einrichten

Von Thomas · virtueller CISO · 2026-07-25

„DMARC in Cloudflare hinzufügen" — die Suchanfrage taucht ständig auf, und sie trifft einen wahren Kern. Bei einem DMARC-Rollout liefert der Postfachanbieter die Werte, aber veröffentlicht werden sie beim Betreiber der DNS-Zone — und für einen riesigen Teil des Webs liegt diese Zone bei Cloudflare. Die Postfächer können bei Microsoft 365 oder Google Workspace liegen, die Kampagnen über Brevo, Mailchimp oder Amazon SES laufen: Es spielt keine Rolle. SPF, DKIM und DMARC sind DNS-Einträge, und sie gehören dorthin, wo das DNS autoritativ ist.

Die gute Nachricht: Alles passt in eine Handvoll TXT-Einträge, ergänzt je nach Anbieter um ein oder zwei CNAMEs für die DKIM-Selektoren. Die weniger gute: Cloudflare hat seine Eigenheiten — eine orangefarbene Wolke, die auf einem Selektor-CNAME nichts verloren hat, ein TTL „Auto", dessen tatsächlicher Wert bekannt sein sollte, ein „Flattening", das den Namen mit einer SPF-Technik teilt, mit der es nichts zu tun hat, und ein integriertes DMARC-Werkzeug, das vor dem ersten Klick verstanden sein will.

Dieser Leitfaden geht die Anlage der drei Einträge in der Cloudflare-Oberfläche durch, die plattformspezifischen Einstellungen, die häufigsten Fehler und die abschließende Prüfung — unabhängig davon, welches Mailsystem hinter der Domain steht.

Cloudflare macht das DNS, nicht die E-Mail

Eine Verwirrung kehrt immer wieder: „Die E-Mail liegt bei Microsoft — warum an Cloudflare schrauben?" Weil Authentifizierungseinträge zur Zone gehören, nicht zum Mailserver. Sobald die Nameserver der Domain auf Cloudflare zeigen — was ab der Aktivierung einer Domain dort der Fall ist, auch im Gratis-Tarif — spielt sich alles im Dashboard ab, im Reiter DNS. Der Mailanbieter liefert die Werte (das SPF-include:, den DKIM-Schlüssel oder die CNAMEs); Cloudflare veröffentlicht sie; die empfangenden Server lesen sie.

Ein Zweifel an der Zuständigkeit klärt sich in zehn Sekunden:

dig NS beispiel.de +short

Endet die Antwort auf ns.cloudflare.com, liegt die Zone tatsächlich bei Cloudflare, und jede Änderung anderswo — beim Registrar, bei einem früheren DNS-Hoster — läuft ins Leere. Das hier beschriebene Vorgehen lässt sich übrigens fast unverändert auf andere DNS-Hoster übertragen: Die Einrichtung von SPF und DKIM bei OVHcloud oder bei Gandi folgt exakt derselben Logik; nur die Oberfläche und zwei, drei Handgriffe unterscheiden sich.

DMARC: ein TXT-Eintrag auf `_dmarc`

Die Anlage läuft über DNS → Records → Add record:

Typ     : TXT
Name    : _dmarc
Inhalt  : v=DMARC1; p=none; rua=mailto:berichte@beispiel.de
TTL     : Auto

Zwei Oberflächendetails zählen. Das Feld Name erwartet den relativen Teil des Namens: _dmarc einzutragen genügt, die Plattform ergänzt automatisch zu _dmarc.beispiel.de (der vollständige Name wird ebenfalls akzeptiert und normalisiert). Und der Unterstrich gehört zum Namen: Ein Eintrag auf dmarc, ohne Unterstrich, wird nie von irgendjemandem abgefragt. Der Inhalt wird unverändert eingefügt, ohne Anführungszeichen — darum kümmert sich die Oberfläche.

Inhaltlich ist p=none der gesunde Ausgangspunkt: Die Domain blockiert nichts, beginnt aber, aggregierte Berichte an die in rua hinterlegte Adresse zu erhalten. Die Verschärfung — p=quarantine, dann p=reject — kommt nach der Bestandsaufnahme der Quellen, nie davor. Eine Notiz für ältere Erinnerungen: Der aktuelle Standard, DMARCbis, hat das Tag pct gestrichen (der schrittweise Rollout läuft nun über den Testmodus t=y) und np für nicht existierende Subdomains ergänzt; v=DMARC1 bleibt der erwartete Wert, die Rückwärtskompatibilität ist vollständig. Für die passende Policy und die passenden Optionen je Situation — aktive Domain, geparkte Domain, Versand-Subdomain — liefern kommentierte DMARC-Eintragsbeispiele fertige Vorlagen zum Anpassen.

SPF an der Wurzel, DKIM im Format des Anbieters

Zuerst SPF. Es ist ein TXT an der Zonenwurzel: Im Namensfeld steht @ für die Domain selbst.

Typ     : TXT
Name    : @
Inhalt  : v=spf1 include:spf.protection.outlook.com include:_spf.brevo.com -all

Der Wert bündelt alle legitimen Versender, jeden über sein include:. Eine absolute Regel: ein einziger Eintrag, der mit v=spf1 beginnt, pro Name. Ein neuer Versender kommt in den bestehenden Eintrag, nie als zweites TXT.

Dann DKIM — und hier diktiert der Anbieter das Format. Zwei Schulen existieren nebeneinander:

Direktes TXT: Der Anbieter liefert einen öffentlichen Schlüssel zum Einfügen. Google Workspace etwa: Name google._domainkey, Inhalt v=DKIM1; k=rsa; p=MIIBIjANBg….
Delegations-CNAME: Der Anbieter liefert einen oder mehrere Aliasse, die auf seine eigenen Server zeigen, wo der Schlüssel lebt — und ohne Zutun rotiert. Microsoft 365 verlangt zwei: selector1._domainkey und selector2._domainkey, zeigend auf selector1-beispiel-de._domainkey.beispiel.onmicrosoft.com und seinen Zwilling. SendGrid, Mailjet oder Brevo verfahren genauso mit eigenen Namen (s1._domainkey, s2._domainkey …).

Beide Formate entstehen an derselben Stelle, mit Typ TXT oder CNAME. Die CNAME-Delegation hat einen echten Vorteil — die Schlüsselrotation wird zur Sache des Anbieters —, wirft bei Cloudflare aber eine spezifische Frage auf, die zwei Abschnitte weiter behandelt wird.

Was Cloudflare-spezifisch ist

Drei Eigenheiten unterscheiden die Plattform von klassischen DNS-Oberflächen.

Der Proxy-Status ist für TXT gegenstandslos. Die berühmte orangefarbene Wolke — der Proxy, der Webverkehr durch das Cloudflare-Netz leitet — betrifft nur A-, AAAA- und CNAME-Einträge. TXT-Einträge (_dmarc, SPF, ein eingefügter DKIM-Schlüssel) tragen diesen Schalter schlicht nicht: keine Entscheidung zu treffen, kein Fehler möglich. Die Frage stellt sich nur bei Selektor-CNAMEs — dazu gleich mehr.

Das TTL „Auto" beträgt 300 Sekunden. Für einen nicht proxierten Eintrag bedeutet „Auto" fünf Minuten. Für Authentifizierungseinträge ist das eine ausgezeichnete Einstellung: Eine Korrektur verbreitet sich schnell, ein Fehler ist schnell behoben. Nichts zwingt zu einer Änderung, und die Suche nach einem langen TTL „zur Entlastung der Server" ist auf einem Anycast-Netz dieser Größe sinnlos.

Ein Werkzeug „DMARC Management" ist eingebaut. Im E-Mail-Bereich der Zone bietet die Plattform ein Modul, das den _dmarc-Eintrag veröffentlicht und aggregierte Berichte an einer von Cloudflare gehosteten rua-Adresse sammelt, mit grafischer Auswertung im Dashboard. Es ist eine Funktion der DNS-Plattform, kostenlos, und kann als erster Kontakt mit aggregierten Berichten dienen. Ein Punkt sollte vor jeder Aktivierung bekannt sein: Das Tag rua akzeptiert mehrere Adressen, durch Kommas getrennt. Die Cloudflare-Sammeladresse kann also neben einem anderen Ziel bestehen — und die Wahl der Empfangsadresse für DMARC-Berichte verdient ihre eigene Überlegung, denn sie bestimmt die gesamte spätere Auswertung.

Selektor-CNAMEs: graue Wolke Pflicht, „Flattening" gut zu kennen

Die E-Mail-Falle Nummer eins bei Cloudflare passt in eine Farbe. Beim Anlegen eines CNAME bietet die Oberfläche bereitwillig den Proxy an (orangefarbene Wolke). Für eine Website ist das oft die richtige Wahl; für einen DKIM-Selektor ist es fatal. Ein proxierter CNAME verschwindet aus der öffentlichen Sicht: Cloudflare antwortet an seiner Stelle mit eigenen IP-Adressen, um Webverkehr zu bedienen, und eine TXT-Abfrage auf selector1._domainkey.beispiel.de liefert gar nichts mehr. Der Schlüssel ist unauffindbar, die DKIM-Signaturen scheitern, und die DMARC-Ausrichtung hängt nur noch an SPF. Jeder Selektor-CNAME muss deshalb auf „DNS only" bleiben — graue Wolke. Das typische Symptom eines Versäumnisses: Der Mailanbieter meldet „Eintrag nicht gefunden", während der CNAME gut sichtbar im Dashboard steht.

Zweite Feinheit: das CNAME-Flattening. An der Zonenwurzel glättet Cloudflare CNAMEs grundsätzlich — das Protokoll verbietet einen CNAME an der Wurzel, also löst die Plattform ihn selbst auf und liefert direkt das Ergebnis. Eine Option dehnt dieses Glätten auf alle CNAMEs der Zone aus. Auf einen DKIM-Selektor angewandt, bricht das Flattening die Validierung nicht: Die Auflösung bleibt dynamisch, der endgültige Inhalt wird ausgeliefert, die Schlüsselrotation des Anbieters wird mitvollzogen. Aber die Kette wird in Diagnosen unsichtbar, was die Fehlersuche erschwert, wenn eines Tages etwas hakt. Ohne konkreten Bedarf bleiben Selektoren ungeglättet besser lesbar. Die Namensgleichheit schließlich stiftet Verwirrung: Dieses CNAME-Flattening hat nichts mit dem „SPF-Flattening" zu tun, bei dem include:-Mechanismen durch IP-Adressen ersetzt werden, um das Limit von zehn DNS-Lookups zu umgehen — eine Notlösung mit gut dokumentierten Nachteilen.

Die häufigen Fehler

Der Eintrag am falschen Ort. Ein _dmarc ohne seinen Unterstrich, ein SPF auf www statt an der Wurzel, oder — subtiler — eine Policy, die auf einer dedizierten Versand-Subdomain erwartet, aber auf der Zone abgelegt wurde. Unter DMARCbis erbt eine Subdomain ohne eigenen Eintrag die Policy der organisatorischen Domain über den DNS Tree Walk; damit news.beispiel.de eine eigene Policy bekommt, gehört der Eintrag auf _dmarc.news. Umgekehrt wird ein Eintrag, der auf einem Fantasienamen gestrandet ist, schlicht nie gelesen.

Die Duplikate. Cloudflare akzeptiert anstandslos zwei v=spf1-TXT auf demselben Namen — und dieses Duplikat macht SPF bei allen Empfängern ungültig (permerror). Dieselbe Strafe für zwei Einträge auf _dmarc: Vor mehreren Policies wenden die Server keine an. Vor jeder Anlage lohnt der Blick in die Liste der vorhandenen Einträge, besonders nach einem Anbieterwechsel, bei dem der alte Eintrag noch herumliegt.

Die duplizierte Zone. Zwei Spielarten desselben Übels. Erstens die Domain, die zu Cloudflare hinzugefügt wurde, ohne dass die Nameserver beim Registrar umgestellt wurden: Die Cloudflare-Zone existiert, lässt sich fleißig bearbeiten … und niemand fragt sie ab — die Änderungen bleiben wirkungslos, während die alte Zone weiter antwortet. Zweitens die eingehende Migration: Beim Import einer Domain scannt Cloudflare die Ursprungszone, um deren Einträge zu übernehmen, und dieser Scan übersieht gern die weniger üblichen TXT-Einträge — _dmarc, Selektoren unter _domainkey. Eine migrierte Domain kann so über Nacht ihr DKIM verlieren, ohne dass irgendetwas bewusst „gelöscht" wurde. Nach jeder Migration gehört ein zeilenweiser Vergleich mit der alten Zone dazu.

Prüfen, dann beobachten

Die Verbreitung ist bei Cloudflare schnell — fünf Minuten Auto-TTL, Anycast-Netz —, die Prüfung kann der Anlage also im Minutenabstand folgen. Auf der Kommandozeile:

dig TXT _dmarc.beispiel.de +short
dig TXT beispiel.de +short
dig TXT selector1._domainkey.beispiel.de +short

Die erste Abfrage muss die DMARC-Policy liefern, die zweite den SPF-Eintrag (neben eventuellen weiteren TXT), die dritte den DKIM-Schlüssel — auch durch einen CNAME hindurch, dem dig stillschweigend folgt. Eine leere Antwort auf einen Selektor, der sichtbar im Dashboard steht, deutet fast immer auf eine vergessene orangefarbene Wolke.

Die DNS-Prüfung ist allerdings nur die halbe Strecke. Der endgültige Beweis sind die aggregierten Berichte, die an der rua-Adresse eintreffen und Quelle für Quelle bestätigen, dass SPF und DKIM bestehen und ausgerichtet sind. Auf dieser Grundlage — Daten statt Vermutungen — kann die Policy von p=none über p=quarantine zu p=reject aufsteigen.

Fazit

Cloudflare betreibt die Zone, die E-Mail lebt anderswo, und alles gehört in den DNS-Reiter: ein _dmarc-TXT mit p=none und einer rua-Adresse, ein einziges v=spf1-TXT an der Wurzel, DKIM-Selektoren als TXT oder CNAME je nach Anbieter. Die plattformspezifischen Reflexe passen in vier Punkte: graue Wolke Pflicht auf Selektor-CNAMEs, Auto-TTL unangetastet lassen, Flattening auf die Zonenwurzel beschränkt, Wachsamkeit bei Duplikaten und bei Geisterzonen nach einer Migration. Das eingebaute DMARC-Werkzeug kann die Sammlung anstoßen; das rua-Tag mit mehreren Adressen hält alle Türen offen.

Zur Validierung des Ergebnisses in einem Durchgang — DMARC-Eintrag, SPF, Selektoren, Ausrichtung — zeichnet eine kostenlose DMARC-Analyse der Domain in Sekunden das Gesamtbild. Und sobald die ersten Berichte eintreffen, öffnet die Erstellung eines Kontos die nächste Etappe: Bestandsaufnahme der Quellen, Alarme bei Neuzugängen und der schrittweise Aufstieg zu p=reject, in dem Tempo, das das Ökosystem der Domain zulässt.

DMARC anwenden — konkret

Thomas, der virtuelle CISO von DMARC.com, identifiziert jede legitime Versandquelle, schreibt die exakten DNS-Einträge und bringt eine Domain sicher von p=none zu p=reject — ohne den Mailverkehr zu stören.

Zu p=reject — kostenlos