SPF, DKIM, DMARC einfach erklärt

Ihre Kaltakquise-E-Mails landen im Spam, obwohl der Text stimmt und die Zielgruppe passt? In neun von zehn Fällen liegt das nicht am Inhalt, sondern an der technischen Absender-Authentifizierung Ihrer Domain. SPF, DKIM und DMARC sind die drei Standards, die E-Mail-Anbieter wie Google und Microsoft prüfen, bevor sie entscheiden, ob eine Nachricht im Posteingang oder im Spam-Ordner landet.

Für Vertriebsteams, die täglich E-Mails an neue Kontakte verschicken, ist das kein IT-Detail, sondern eine Voraussetzung für messbare Antwortquoten. Dieser Artikel erklärt SPF, DKIM und DMARC einfach und ohne technischen Ballast — inklusive konkreter Beispiele, wie die Einträge aussehen.

Was bedeuten SPF, DKIM und DMARC?

SPF, DKIM und DMARC sind drei DNS-basierte Standards, die belegen, dass eine E-Mail wirklich von der angegebenen Domain stammt und unterwegs nicht verändert wurde. SPF listet, welche Server im Namen einer Domain E-Mails versenden dürfen. DKIM signiert jede E-Mail digital, um Manipulation auszuschließen. DMARC legt fest, was passiert, wenn SPF oder DKIM fehlschlagen, und liefert Berichte an den Domain-Inhaber.

SPF: Wer darf für Ihre Domain versenden?

SPF (Sender Policy Framework) ist ein einzelner TXT-Eintrag im DNS Ihrer Domain, der alle autorisierten Versand-Server auflistet. Empfangende Server prüfen bei jeder eingehenden E-Mail, ob der absendende Server auf dieser Liste steht.

Ein typischer SPF-Eintrag sieht so aus:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Das bedeutet: E-Mails über Google Workspace und SendGrid sind autorisiert, alles andere wird als verdächtig markiert (~all, "soft fail") oder abgelehnt (-all, "hard fail"). Häufigster Praxisfehler: Ein Unternehmen nutzt mehrere Tools zum Versenden (Google Workspace, ein CRM, ein Marketing-Tool, ein Kaltakquise-Tool) und vergisst, jedes davon im SPF-Eintrag zu ergänzen — die Folge sind SPF-Fehlschläge und schlechtere Zustellbarkeit, sobald ein neues Tool dazukommt.

DKIM: Wie wird eine E-Mail signiert?

DKIM (DomainKeys Identified Mail) fügt jeder ausgehenden E-Mail eine kryptografische Signatur im Header hinzu, die auf einem privaten Schlüssel beim Versender basiert. Der passende öffentliche Schlüssel liegt als weiterer DNS-Eintrag bei Ihrer Domain. Der empfangende Server prüft die Signatur gegen diesen öffentlichen Schlüssel — stimmt sie überein, ist sicher, dass die Nachricht seit dem Versand nicht verändert wurde und tatsächlich von einem autorisierten Server stammt.

Ein DKIM-DNS-Eintrag hat meist diese Form, mit einem Selector-Präfix, das vom E-Mail-Anbieter vergeben wird:

selector._domainkey.ihredomain.de TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

Anders als SPF, das nur den sendenden Server prüft, bestätigt DKIM die Integrität der Nachricht selbst — das macht die Kombination beider Standards deutlich robuster als jeden einzeln.

DMARC: Was passiert bei einem fehlgeschlagenen Check?

DMARC (Domain-based Message Authentication, Reporting and Conformance) baut auf SPF und DKIM auf und definiert eine Richtlinie: Was soll passieren, wenn eine E-Mail keinen der beiden Checks besteht? Drei Policy-Stufen sind möglich:

• p=none: Nichts blockieren, nur Berichte sammeln — der übliche Startpunkt, um zu beobachten, welche Server in Ihrem Namen versenden.
• p=quarantine: Verdächtige E-Mails landen im Spam-Ordner des Empfängers.
• p=reject: Verdächtige E-Mails werden komplett abgelehnt, kommen also gar nicht erst an.

Ein einfacher DMARC-Eintrag:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@ihredomain.de

Der rua-Parameter legt fest, wohin aggregierte Berichte über fehlgeschlagene Zustellversuche gesendet werden — ein wichtiges Werkzeug, um Missbrauch der eigenen Domain (Spoofing) frühzeitig zu erkennen.

Wie hängen die drei Standards zusammen?

Standard	Prüft	Speicherort	Ohne diesen Standard
SPF	Welcher Server darf senden	TXT-Eintrag im DNS	Jeder Server kann sich als Ihre Domain ausgeben
DKIM	Ob die Nachricht unverändert ist	TXT-Eintrag im DNS (mit Selector)	Keine Garantie gegen Manipulation
DMARC	Was bei einem Fehlschlag passiert + Reporting	TXT-Eintrag im DNS	SPF/DKIM-Fehler bleiben folgenlos und unsichtbar

Alle drei sind reine DNS-Einträge — es braucht keine Software-Installation, nur Zugriff auf die DNS-Verwaltung der Domain (meist beim Domain-Registrar oder Hosting-Provider). Der übliche Aufbau folgt dieser Reihenfolge: zuerst SPF einrichten, dann DKIM beim jeweiligen Versand-Tool aktivieren, zum Schluss DMARC mit p=none starten und die Policy nach ein paar Wochen sauberer Berichte auf p=quarantine oder p=reject verschärfen.

Warum das für B2B-Vertrieb und Kaltakquise besonders wichtig ist

Google und Microsoft haben ihre Anforderungen an Massen-Versender verschärft: Wer täglich mehrere Tausend E-Mails über dieselbe Domain verschickt, ohne gültiges SPF, DKIM und DMARC zu hinterlegen, riskiert, dass die gesamte Domain als Spam-Quelle eingestuft wird — nicht nur einzelne Kampagnen. Für Teams, die Kaltakquise über eine Haupt-Domain fahren, empfiehlt sich zusätzlich eine separate Sending-Domain oder Subdomain, um die Reputation der Hauptdomain zu schützen, falls eine Kampagne fehlschlägt.

Technisch sauber authentifizierte E-Mails lösen aber nur einen Teil des Zustellbarkeitsproblems. Der andere Teil ist die Empfängerliste selbst: Veraltete oder falsch geschriebene E-Mail-Adressen erzeugen Bounces, und eine hohe Bounce-Rate schadet der Domain-Reputation genauso wie ein fehlendes DMARC. Eine verifizierte E-Mail-Datenbasis reduziert dieses Risiko, bevor die erste Nachricht überhaupt verschickt wird — Authentifizierung und Datenqualität wirken hier zusammen, nicht gegeneinander.

FAQ

Reicht SPF allein aus? Nein. SPF prüft nur, ob der sendende Server autorisiert ist, aber nicht, ob der Inhalt der E-Mail unterwegs verändert wurde. Ohne DKIM und DMARC bleibt eine Lücke, die viele E-Mail-Anbieter inzwischen aktiv als Risikosignal werten.

Was ist der Unterschied zwischen p=none, p=quarantine und p=reject bei DMARC? p=none sammelt nur Berichte, ohne E-Mails zu blockieren. p=quarantine schickt nicht-authentifizierte E-Mails in den Spam-Ordner. p=reject lehnt sie vollständig ab. Der übliche Weg ist, mit p=none zu starten und die Policy schrittweise zu verschärfen, sobald alle legitimen Versand-Quellen im SPF-Eintrag erfasst sind.

Wie lange dauert die Einrichtung von SPF, DKIM und DMARC? Das Anlegen der DNS-Einträge selbst dauert meist unter einer Stunde. DNS-Änderungen brauchen aber Zeit, um sich zu verbreiten (bis zu 48 Stunden), und eine sinnvolle DMARC-Policy-Verschärfung sollte erst nach einigen Wochen Beobachtung der Berichte erfolgen.

Kann eine falsch konfigurierte DMARC-Policy legitime E-Mails blockieren? Ja. Wenn nicht alle genutzten Versand-Tools im SPF-Eintrag stehen oder DKIM nicht korrekt aktiviert ist, kann eine zu strenge DMARC-Policy (p=reject) auch eigene, legitime E-Mails blockieren. Deshalb ist die schrittweise Verschärfung über p=none und p=quarantine der sicherere Weg.

---

Saubere Zustellbarkeit beginnt bei der DNS-Konfiguration, hängt aber genauso von der Qualität der Empfängerliste ab. Enrich-CRM reichert Ihre CRM-Kontakte um verifizierte E-Mail-Adressen an und lässt sich mit HubSpot, Zapier, Make, n8n, Clay sowie per REST-API oder CSV verbinden. Mehr zur CRM-Datenanreicherung — oder direkt kostenlos starten mit 100 Credits/Monat, ohne Kreditkarte: jetzt registrieren.