SPF, DKIM und DMARC für Cold E‑Mails: Einrichtungs-Checkliste

Warum Cold E‑Mails scheitern, wenn DNS-Authentifizierung falsch ist

E-Mail-Authentifizierung ist die Art, wie ein Postfach prüft, ob deine Nachricht wirklich von deiner Domain gesendet werden darf. Es geht nicht um besseren Text. Es geht darum, Identität nachzuweisen.

Wenn du eine Cold E‑Mail sendest, schaut der empfangende Server auf die Domain in der From‑Adresse und führt drei zentrale Prüfungen durch:

• SPF: Hat ein autorisierter Server diese Nachricht gesendet?
• DKIM: Ist die Nachricht von der Domain signiert?
• DMARC: Was soll der Empfänger tun, wenn diese Prüfungen fehlschlagen, und stimmen die Domains überein?

Neue Sendedomänen werden strenger bewertet, weil sie keine Historie haben. Eine brandneue Domain mit schwachen oder fehlerhaften DNS-Signalen wirkt riskant, selbst wenn deine Absicht in Ordnung ist. Deshalb schaden Authentifizierungsfehlern Cold Outreach schneller als etablierten Marken.

Fehlerhafte DNS-Einträge verursachen normalerweise auf drei leise Arten Probleme: Deine E‑Mail wird angenommen, landet aber im Spam; sie wird komplett abgewiesen (Hard Bounces oder Blocks); oder sie kommt manchmal an, aber deine Domain baut eine schlechte Reputation auf.

Kleine Fehler sind oft die Ursache. Zwei separate SPF-TXT-Einträge können einen Fehler auslösen. Ein DKIM-Schlüssel mit fehlendem Zeichen verifiziert nicht. DMARC mit einer zu strikten Richtlinie, bevor alles korrekt eingerichtet ist, kann normale Sends blockieren.

Diese Checkliste konzentriert sich praktisch auf SPF, DKIM und DMARC: was zu veröffentlichen ist, was zu vermeiden ist und wie du Ergebnisse prüfst, bevor du das Senden hochfährst. Sie behandelt nicht Copywriting, Listenqualität, Angebotspassung oder lokale Compliance.

Das einfache Modell: was überprüft wird, wenn du sendest

Beim Senden einer Cold E‑Mail sind meist zwei Domains beteiligt, und eine Verwechslung verursacht viele Missverständnisse.

Die sichtbare From-Domain ist die, die der Empfänger sieht ([email protected]). Die Mailbox-Domain (manchmal anders) ist die Domain, die tatsächlich im Hintergrund sendet, z. B. eine dedizierte Sendesubdomain oder eine Provider-Domain. Für gute Zustellbarkeit sollten diese konsistent oder zumindest klar verbunden sein.

Von der From-Domain zum Posteingang: die drei Prüfungen

Die meisten Postfächer folgen demselben Grundablauf:

1. SPF prüft den versteckten Return-Path (auch Envelope-Sender genannt) und fragt, ob dieser Server für diese Domain senden darf.
2. DKIM prüft die DKIM-Signatur und fragt, ob die signierende Domain mit der Nachricht übereinstimmt.
3. DMARC schaut auf die sichtbare From-Domain und prüft, ob SPF und/oder DKIM damit ausgerichtet sind, und wendet dann deine Richtlinie an.

Alignment, ohne Fachchinesisch

Alignment bedeutet einfach: Stimmen die Domains überein? Es gibt drei Stellen zu beachten:

• From: was Menschen sehen (z. B. @deinedomain.de)
• Return-Path: was SPF nutzt (kann z. B. @mail.deinedomain.de sein)
• DKIM d=: die Domain, die die Nachricht signiert (z. B. d=deinedomain.de)

DMARC besteht, wenn die From-Domain mit SPF (Return-Path-Domain) und/oder mit DKIM (d= Domain) ausgerichtet ist. Alles muss nicht identisch sein, aber es sollte bewusst so eingerichtet sein.

Was passiert, wenn Prüfungen fehlschlagen

Provider reagieren nicht alle gleich, aber die Folgen sind vorhersehbar:

• p=none (Monitoring): Mail kommt oft an und du sammelst Berichte.
• p=quarantine: Mail landet eher im Spam.
• p=reject: Mail wird blockiert.

Selbst bevor DMARC streng ist, verringern wiederholte Fehler oft die Inbox-Platzierung über die Zeit.

Beispiel: Du sendest von [email protected], aber SPF autorisiert nur eine andere Domain und DKIM signiert als d=anotherdomain.com. Die Nachricht kann „unzugeordnet“ wirken, sodass Filter vorsichtig werden.

Bevor du DNS änderst: Vorbereitung für ein sauberes Setup

Die meisten Zustellbarkeitsprobleme beginnen, bevor jemand einen DNS-Eintrag hinzufügt. Gute Vorbereitung macht das Setup schneller, sauberer und leichter zu debuggen.

Entscheide zuerst, welche Domain in der From-Adresse erscheinen soll. Viele Teams nutzen eine dedizierte Sendedomäne (oder Subdomain), damit die Hauptfirma‑Domain nicht sofort gefährdet ist, falls etwas schiefgeht.

Wähle dann aus, wie du die genauen Werte sammelst, die du brauchst. Dein E‑Mail-Provider gibt dir einen konkreten SPF‑Wert, DKIM‑Selector-Namen und Schlüssel sowie einen empfohlenen DMARC-Eintrag. Rate nicht und kopiere keine Einträge von einer anderen Domain.

Bestätige vor Änderungen vier Dinge: welche exakte From‑Domain du nutzt, welche Provider senden, wo DNS tatsächlich verwaltet wird und wer die Berechtigung hat, TXT‑ und CNAME‑Einträge zu veröffentlichen.

Stelle außerdem sicher, dass du im richtigen Dashboard arbeitest. Leute kaufen oft eine Domain an einem Ort, hosten DNS woanders und bearbeiten die falschen Records. Wenn du unsicher bist, prüfe die Nameserver der Domain und log dich beim Anbieter ein, der sie kontrolliert.

Ein einfacher Änderungsplan verhindert „wohlmeinende“ Anpassungen, die bestehende E‑Mails kaputtmachen. Typischerweise aktualisierst du SPF (vorsichtig, besonders wenn bereits vorhanden), fügst DKIM hinzu und veröffentlichst DMARC im Monitoring-Modus. Lass MX-, A‑ und Website-Records unverändert, sofern du keinen Grund hast, sie zu ändern.

SPF: die richtigen Sender hinzufügen und Lookup-Limits vermeiden

SPF ist ein DNS-TXT-Eintrag, der Postfach-Providern sagt, welche Server berechtigt sind, im Namen deiner Domain zu senden. Beim Cold Outreach ist SPF eine der ersten Prüfungen, die entscheidet, ob deine Nachricht normal oder verdächtig wirkt.

Ein guter SPF-Record ist eine kleine Allowlist, die alle Orte abdeckt, die als deine Domain senden dürfen: dein Cold‑Email-Sender, Google Workspace oder Microsoft 365 (falls du sie nutzt) und Tools wie Support- oder CRM‑Systeme, die in deinem Namen Mail senden.

Was in den SPF-Record gehört

Die meisten neuen Domains benötigen nur wenige Einträge:

• include: wenn ein Provider dir sagt, seinen SPF einzubinden. Halte Includes minimal, weil sie DNS-Lookups kosten.
• ip4:/ip6: wenn du feste sendende IPs hast. Das vermeidet Lookups, funktioniert aber nur bei stabilen IPs.
• a und mx: nur wenn der eigene Server oder Mail-Exchanger deiner Domain direkt sendet (bei vielen Cold‑Email-Setups nicht nötig).

Hier ein sauberes Beispiel (deine Werte weichen ab):

v=spf1 include:YOUR-SENDER-SPF ip4:203.0.113.10 ~all

Die richtige Endung wählen: -all vs ~all

Der letzte Teil ist die Default-Regel für alles, was nicht gelistet ist.

~all (soft fail) ist ein sicherer Start während Tests, wenn du einen legitimen Sender übersehen haben könntest. -all (hard fail) ist besser, wenn du sicher bist, denn es sagt klar: nicht autorisierte Sender ablehnen.

Für neue Outbound-Domains starte mit ~all und wechsle zu -all, nachdem du verifiziert hast, dass nichts Legitimes fehlschlägt.

Unter dem 10-Lookup-Limit bleiben

SPF hat ein hartes Limit von 10 DNS-Lookups. Zu viele includes können SPF kaputtmachen und die Zustellbarkeit still schädigen.

Halte Includes niedrig, vermeide verschachtelte Include-Ketten, entferne alte Tools, von denen du nicht mehr sendest, und veröffentliche genau einen SPF-TXT-Eintrag pro Domain. Mehrere SPF-Records führen zu einem PermError.

DKIM: Schlüssel korrekt veröffentlichen und Selector ordentlich verwalten

DKIM fügt jeder gesendeten E‑Mail eine digitale Signatur hinzu. Empfangende Server nutzen den öffentlichen Schlüssel im DNS, um zu prüfen, ob die Nachricht unverändert ist und ob deine Domain zum Signieren berechtigt ist. DKIM sorgt oft dafür, dass eine neue Domain über die Zeit konsistent wirkt.

Wie Selectors funktionieren (und warum Namen wichtig sind)

Ein DKIM-Selector ist ein Label, das auf einen bestimmten öffentlichen Schlüssel zeigt. Dein System signiert Nachrichten mit diesem Selector, und der Empfänger sucht einen DNS-Eintrag unter:

selector._domainkey.deinedomain.de

Selector erlauben Key-Rotation ohne Mail-Unterbrechung, können aber auch verwirren. Wenn du denselben Selector für immer wiederverwendest, wird Rotation riskant. Wenn du ständig neue Selector anlegst, wird das DNS unübersichtlich.

Eine einfache Herangehensweise ist ein stabiler, beschreibender Selector wie s1, mail oder 2026q1 und gezieltes Rotieren bei Bedarf.

TXT vs CNAME: was du im DNS siehst

Einige Provider veröffentlichen DKIM als TXT-Record mit dem vollständigen Schlüssel. Andere geben dir eine CNAME, die auf einen gehosteten Schlüssel zeigt. Beides funktioniert, wenn (und nur wenn) du exakt das publizierst, was dein Provider erwartet.

Die häufigsten DKIM-Probleme sind banal: falscher Record-Typ (TXT vs CNAME), zusätzliche Anführungszeichen oder versteckte Zeilenumbrüche, nur ein Teil des Schlüssels eingefügt, der Record nicht unter selector._domainkey sondern an der Root-Domain veröffentlicht, oder alte Selector, die noch aktiv sind und widersprüchliche Einträge erzeugen.

Wenn DKIM fehlschlägt, rate nicht. Kopiere den Wert erneut vom Provider, veröffentliche ihn sauber und teste nach DNS-Änderungen nochmal.

DMARC: mit Monitoring starten, dann Richtlinie verschärfen

DMARC ist die Schicht „Was sollen Empfänger bei Fehlern tun?“. SPF und DKIM sagen Gmail oder Outlook, was zu prüfen ist. DMARC fügt eine klare Richtlinie (none, quarantine, reject) hinzu und verlangt Alignment mit der sichtbaren From-Domain.

Ein praktischer Weg ist: zuerst Monitoring. Veröffentliche DMARC mit p=none, damit du siehst, was besteht und was nicht, ohne Zustellbarkeit zu riskieren. Lass es ein paar Tage laufen, während du mit kleinem Volumen sendest, und verschärfe dann in Schritten.

Hier ein sicheres Starter‑Record-Muster (passe E‑Mails und Domain an):

_dmarc.example.com TXT \"v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s; pct=100; fo=1\"

Halte die Optionen einfach. Strenges Alignment (adkim=s und aspf=s) ist ein guter Default für dedizierte Outbound‑Domains, die du komplett kontrollierst. pct=100 sorgt für konsistentes Verhalten. fo=1 ist eine sinnvolle Einstellung, um Berichte bei Fehlschlägen zu erhalten.

Sei vorsichtig mit Reporting-Adressen. Aggregierte Berichte (rua) können nützlich sein, aber nur, wenn sie auch ausgewertet werden. Forensische Berichte (ruf) werden oft blockiert und können Datenschutz- und Lärmprobleme erzeugen — daher meist besser weglassen.

Schritt-für-Schritt: eine brandneue Sendedomäne authentifizieren

Behandle eine frische Domain wie einen sauberen Raum. Deine DNS-Einträge müssen zu deinem tatsächlichen Sender passen — entscheide vorher, wo du senden wirst.

1) Bereinige die DNS-Zone zuerst

Suche im DNS-Host nach bestehenden TXT-Einträgen, die SPF, DKIM oder DMARC erwähnen. Neue Domains haben manchmal Starter-Records, alte Tests oder Duplikate. Entferne Unbekanntes und vergewissere dich, dass nur ein SPF-TXT-Eintrag für die Root-Domain existiert.

2) Authentifizierung in sicherer Reihenfolge hinzufügen

Füge jeweils einen Eintragstyp hinzu und bestätige seine Sichtbarkeit, bevor du weitermachst:

1. SPF: Veröffentliche einen einzelnen SPF-TXT-Record, der nur die Services enthält, die für diese Domain senden.
2. DKIM: Füge die DKIM-Records hinzu, die dein Sender bereitstellt (oft CNAMEs, manchmal ein TXT-Record). Achte darauf, dass der Selector zu den Signatur-Einstellungen deines Senders passt.
3. DMARC: Veröffentliche einen DMARC-TXT-Record unter _dmarc.yourdomain mit p=none als Start.

3) Warten und Werte erneut prüfen

DNS-Änderungen sind nicht immer sofort aktiv. Nachdem du Records veröffentlicht hast, prüfe, was tatsächlich live ist. Bestätige, dass genau ein SPF-Record existiert, DKIM exakt übereinstimmt und DMARC auf der _dmarc-Subdomain steht.

4) Sende echte E‑Mails und prüfe "pass" in den Headern

Sende ein paar schlichte E‑Mails (keine Anhänge, kein schweres HTML) an Accounts, die du kontrollierst, z. B. Gmail und Outlook. Öffne die Nachrichtendetails und suche nach Authentication-Results. Du möchtest spf=pass, dkim=pass und dmarc=pass sehen.

Wenn SPF fehlschlägt, liegt es meist an falschem include oder mehreren SPF-Records. Wenn DKIM fehlschlägt, ist oft ein Selector-Mismatch oder ein Tippfehler im DNS-Wert die Ursache.

Wenn du konsistente Passes erhältst, beginne mit Warm-up und vorsichtigem Versandvolumen.

Häufige DNS-Fehler, die die Inbox-Platzierung leise schädigen

Die meisten Probleme mit einer neuen Domain sind nicht dramatische Fehler. Es sind kleine DNS-Details, die das Senden erlauben, aber Empfänger dazu bringen, dir weniger zu vertrauen.

Zwei Probleme treten ständig auf:

Erstens: Zwei SPF-Records auf derselben Domain. Es sollte nur einen SPF-TXT-Record geben. Wenn du Google und ein Sendetool brauchst, führe alles in einem einzigen v=spf1-Record zusammen und verwende nur ein Abschluss-Mechanismus (~all oder -all).

Zweitens: SPF-Permerror wegen zu vieler Lookups. includes erhöhen Lookups, verschachtelte includes machen es schlimmer. Schraube ungenutzte Tools zurück, halte den Record kurz und vermeide mehrere Provider „nur zur Sicherheit“.

Bei DKIM ist der häufigste Fehler ein Selector-Mismatch. Dein Provider signiert mit einem bestimmten Selector (z. B. s1 oder default). Wenn dein DNS einen anderen Selector publiziert, kann der Empfänger DKIM nicht verifizieren, obwohl ein Record existiert.

DMARC-Fehlschläge verwirren oft, weil SPF passen kann und DMARC trotzdem fehlschlägt. DMARC verlangt Alignment mit der sichtbaren From-Domain. Wenn du von [email protected] sendest, der Return-Path aber brand-mail.com ist und DKIM als d=brand-mail.com signiert, kann SPF passen und DMARC dennoch fehlschlagen.

Schnell-Checkliste: 10-Minuten-Finalprüfung

Bevor du echtes Volumen sendest, mache einen kurzen Check, ob Records sauber sind und deine Nachrichten wirklich authentifiziert werden.

Bestätige: genau ein SPF-TXT-Record auf der Root-Domain. Bestätige: DKIM ist für die Domain veröffentlicht, von der du sendest, und der Selector stimmt mit dem Sender-Tool überein. Bestätige: genau ein DMARC-Record unter _dmarc.example.com, starte mit p=none.

Wenn du gerade Einträge geändert hast, warte etwas. Viele "es funktioniert immer noch nicht"-Momente sind DNS-Caching.

Sende dann eine echte Test-E-Mail an ein Postfach, das du inspizieren kannst, und prüfe Authentication-Results. Ziel: spf=pass, dkim=pass, dmarc=pass.

Schnelle Fehlerbehebungen:

• SPF fail: falsches include, falsche Domain (Root vs Subdomain) oder zwei SPF-Records.
• DKIM fail: Selector-Mismatch, zusätzliche Leerzeichen/Anführungszeichen oder Signieren deaktiviert.
• DMARC fail: DMARC fehlt, auf der Root statt unter _dmarc veröffentlicht oder SPF/DKIM nicht auf die From-Domain ausgerichtet.

Beispiel und nächste Schritte für eine neue Cold-Email-Domain

Ein einfaches Setup: Du kaufst eine frische Domain nur fürs Outbound und legst ein paar Postfächer an (alex@, sam@, info@). Halte die Hauptfirma‑Domain getrennt, damit ein Fehler nicht den Tagesbetrieb stört.

Ein realistischer Zeitplan:

• Tag 0: Veröffentliche SPF, DKIM und DMARC im Monitoring-Modus (p=none).
• Tag 1: Sende Test-E-Mails und verifiziere SPF/DKIM/DMARC. Behebe Tippfehler und falsche Hostnamen.
• Tag 2–3: Starte mit sehr niedrigem Volumen während des Warm-ups.
• Ende Woche 1: Prüfe DMARC-Berichte und Bounces, behebe Misalignments.
• Woche 2+: Wenn alles stabil ist, wechsle zu p=quarantine und später zu p=reject.

Wenn du SPF-Pass siehst, aber DMARC fail, ist meist Alignment gebrochen, nicht das DNS komplett falsch. Die schnellste Lösung ist oft, DKIM zu aktivieren und mit deiner Sendedomäne zu signieren, weil DKIM-Alignment stabiler ist als SPF, wenn Tools sich ändern.

Nach korrekter Authentifizierung kommen die Ergebnisse von deinem Verhalten, nicht nur von Records. Warmup langsam, Anfangsvolumen niedrig halten, DNS-Änderungen dokumentieren, Providerwechsel im ersten Monat vermeiden und Bounces sowie Abmeldungen genau beobachten.

Wenn du die Anzahl der eingesetzten Tools reduzieren willst: LeadTrain (leadtrain.app) kombiniert Domain-Setup, SPF/DKIM/DMARC-Konfiguration, Warm-up, mehrstufige Sequenzen und Reply-Klassifikation in einer Plattform, was helfen kann, Alignment konsistent zu halten, wenn du Domains und Postfächer hinzufügst.