SPF, DKIM und DMARC: Der komplette Leitfaden zur E-Mail-Authentifizierung

Jeden Tag versenden Angreifer Milliarden von E-Mails, die vorgeben, von Marken zu stammen, die sie nicht sind. Gefälschte Rechnungen, gefälschte Passwort-Zurücksetzungen, gefälschte CEO-Anfragen — all das funktioniert, weil standardmäßig jeder eine beliebige Adresse in das Von-Feld einer E-Mail eintragen kann. SPF, DKIM und DMARC existieren, um genau diese Lücke zu schließen. Zusammen ermöglichen sie es Postfachanbietern, zu überprüfen, ob eine Nachricht tatsächlich von der Domain stammt, die sie vorgibt zu vertreten, und sie sind still und leise zum Eintrittspreis für den Posteingang geworden: Seit Februar 2024 verlangen Gmail und Yahoo eine Authentifizierung von jedem Absender und vollständiges SPF, DKIM und DMARC von Massenversendern. Dieser Leitfaden erklärt, wie jedes Protokoll funktioniert, welche exakten DNS-Records Sie benötigen, welche Fehler sie stillschweigend außer Kraft setzen, und liefert einen Rollout-Plan, den Sie diese Woche umsetzen können.

Warum E-Mail-Authentifizierung wichtig ist

Das Kernproblem ist, dass SMTP, das Protokoll, das E-Mails im Internet transportiert, in einer Ära des Vertrauens entwickelt wurde. Es führt keine Identitätsprüfung der sichtbaren Von-Adresse durch. Diese eine Design-Lücke befeuert Phishing und Business E-Mail Compromise (BEC) in industriellem Maßstab: Das Internet Crime Complaint Center des FBI bezifferte die gemeldeten BEC-Verluste allein für 2023 auf rund 2,9 Milliarden US-Dollar. Wenn Kriminelle Ihre Domain fälschen, werden Ihre Kunden betrogen und Ihre Zustellbarkeit leidet — Postfachanbieter können Ihre echten Kampagnen nicht von den Fälschungen unterscheiden.

Authentifizierung löst dieses Problem mit drei sich ergänzenden, DNS-basierten Protokollen:

• SPF legt fest, welche Server E-Mails im Namen Ihrer Domain versenden dürfen
• DKIM signiert jede Nachricht kryptografisch, sodass Manipulation und Fälschung erkennbar werden
• DMARC verknüpft beides mit der sichtbaren Von-Adresse und teilt Empfängern mit, was bei fehlgeschlagenen Prüfungen zu tun ist

Das Gmail- und Yahoo-Mandat

Im Februar 2024 machten Google und Yahoo aus einer seit Langem bewährten Praxis eine harte Anforderung. Alle Absender müssen sich mit mindestens SPF oder DKIM authentifizieren. Absender, die etwa 5.000 Nachrichten pro Tag an einen Anbieter überschreiten, müssen sowohl SPF als auch DKIM sowie eine DMARC-Richtlinie (mindestens p=none) vorweisen, eine mit der Authentifizierung ausgerichtete Von-Domain, eine innerhalb von zwei Tagen befolgte Ein-Klick-Abmeldung und eine Spam-Beschwerderate unter 0,3%. Nicht konforme E-Mails werden zunächst mit temporären Fehlern gedrosselt und anschließend vollständig abgelehnt. Microsoft kündigte 2025 gleichwertige Anforderungen für Massenversender bei Outlook.com an, sodass die Richtung der Branche eindeutig ist.

Die Verbreitung nimmt zu, ist aber noch längst nicht universell: Die Analyse von EasyDMARC der 1,8 Millionen wichtigsten Domains weltweit ergab, dass 2025 nur 47,7% einen DMARC-Record hatten — und Branchenstudien zeigen durchgängig, dass ein großer Teil der veröffentlichten Records noch auf der reinen Überwachungsrichtlinie p=none verharrt, die keinerlei echten Spoofing-Schutz bietet. Dies richtig umzusetzen ist nach wie vor ein Wettbewerbsvorteil.

SPF: Sender Policy Framework

Wie SPF funktioniert

SPF ist ein DNS-TXT-Record, der alle Server auflistet, die im Namen Ihrer Domain E-Mails versenden dürfen. Wenn ein empfangender Server eine Verbindung akzeptiert, prüft er die Return-Path-Domain (auch envelope from oder MAIL-FROM-Adresse genannt — nicht der Von-Header, den Ihre Empfänger sehen), ruft den SPF-Record dieser Domain ab und überprüft, ob die verbindende IP auf der Liste steht. Ist das der Fall, besteht SPF die Prüfung; wenn nicht, schlägt SPF fehl oder schlägt je nach Ihrer Richtlinie teilweise fehl (soft fail).

Record-Syntax im Detail

Ein typischer SPF-Record für ein Unternehmen, das Google Workspace, eine Marketing-Plattform und eine dedizierte Versand-IP nutzt, sieht so aus:

yourdomain.com.  IN  TXT  "v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:203.0.113.10 ~all"

Von links nach rechts gelesen:

• v=spf1 — das Versions-Tag; jeder SPF-Record beginnt damit
• include:_spf.google.com — autorisiert die Versandserver von Google Workspace, indem auf Googles eigenen SPF-Record verwiesen wird
• include:servers.mcsv.net — autorisiert eine Marketing-Plattform (in diesem Beispiel Mailchimp)
• ip4:203.0.113.10 — autorisiert eine bestimmte IPv4-Adresse, zum Beispiel Ihren eigenen SMTP-Server
• ~all — der Catch-all: Jeder nicht gelistete Server soll teilweise fehlschlagen. Der Qualifier ist entscheidend: -all ist ein vollständiger Fehlschlag (empfohlen, sobald Ihr Record vollständig ist), ~all ist ein teilweiser Fehlschlag, und +all autorisiert das gesamte Internet — verwenden Sie das niemals

Das Limit von 10 DNS-Abfragen

RFC 7208 begrenzt die SPF-Auswertung auf 10 DNS-Abfragen. Jeder include-, a-, mx-, ptr- und exists-Mechanismus zählt — und Includes zählen rekursiv, sodass allein das Include einer einzigen Marketing-Plattform drei oder vier Abfragen verbrauchen kann. Überschreiten Sie das Limit, geben Empfänger permerror zurück, was viele Anbieter als SPF-Fehlschlag werten. Reine ip4- und ip6-Mechanismen kosten nichts, bevorzugen Sie sie daher, wo praktikabel, entfernen Sie nicht mehr genutzte Dienste, und ziehen Sie eine SPF-Flattening in Betracht, wenn Sie wirklich viele Anbieter benötigen.

Häufige SPF-Fehler

• Mehrere SPF-Records veröffentlichen. Eine Domain darf genau einen Record besitzen, der mit v=spf1 beginnt. Zwei Records erzeugen einen permanenten Fehler, der die Validierung scheitern lässt. Fassen Sie alle Mechanismen in einem einzigen Record zusammen.
• +all verwenden. Das teilt der Welt mit, dass jeder Server in Ihrem Namen senden darf — SPF wird dadurch praktisch deaktiviert, und Ihre Domain wird als falsch konfiguriert markiert.
• Einen Versanddienst vergessen. Ihr Helpdesk, Ihr Abrechnungssystem und Ihr CRM versenden allesamt E-Mails. Stehen sie nicht im Record, schlagen ihre Nachrichten teilweise fehl.
• Den Record verrotten lassen. Abgeschaltete Dienste hinterlassen verwaiste Includes, die Abfragen verschwenden und ein Sicherheitsrisiko darstellen können.
• Annehmen, SPF decke die sichtbare Von-Adresse ab. Es prüft ausschließlich den Return-Path. Das Alignment mit dem Von-Header ist Aufgabe von DMARC, weshalb SPF allein nur sehr wenig Spoofing verhindert.

DKIM: DomainKeys Identified Mail

Wie die DKIM-Signatur funktioniert

DKIM fügt jeder ausgehenden Nachricht eine kryptografische Signatur hinzu. Ihr Versandserver hält einen privaten Schlüssel und signiert einen Hash des Nachrichtentexts sowie ausgewählter Header (Von, Betreff, Datum und weitere). Der passende öffentliche Schlüssel wird in Ihrem DNS veröffentlicht, und der empfangende Server nutzt ihn, um die Signatur zu überprüfen. Eine gültige Signatur belegt zwei Dinge: Die Nachricht wurde von der Domain autorisiert, die sie signiert hat, und der signierte Inhalt wurde während der Übertragung nicht verändert. Anders als SPF übersteht eine DKIM-Signatur eine Weiterleitung, was sie zum robusteren der beiden Mechanismen macht.

Selektoren und der DNS-Record

Der öffentliche Schlüssel liegt unter einem DNS-Namen, der aus einem Selektor gebildet wird: selector._domainkey.yourdomain.com. Selektoren erlauben es, mehrere Schlüssel nebeneinander zu betreiben — einen pro Versanddienst, oder alte und neue Schlüssel während der Rotation. Ein veröffentlichter Schlüssel-Record sieht so aus:

s1._domainkey.yourdomain.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0Zx8...IDAQAB"

Und jede signierte Nachricht trägt einen Header, der darauf verweist:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=s1;
  h=from:subject:date:to:mime-version; bh=Kx9c1...; b=HqTf3...

Das d=-Tag benennt die signierende Domain und das s=-Tag den Selektor — zusammen sagen sie dem Empfänger genau, wo der öffentliche Schlüssel abzurufen ist.

Schlüssellänge und Rotation

• Verwenden Sie 2048-Bit-RSA-Schlüssel. 1024-Bit-Schlüssel gelten als schwach, und manche Anbieter bestrafen sie; 2048 Bit ist der aktuelle Standard und wird von Google empfohlen.
• Rotieren Sie Schlüssel regelmäßig. Die Best Practice von M3AAWG sieht vor, DKIM-Schlüssel mindestens alle sechs Monate zu rotieren. Veröffentlichen Sie den neuen Schlüssel unter einem neuen Selektor, wechseln Sie die Signatur und deaktivieren Sie den alten Record erst nach einigen Tagen.
• Signieren Sie mit Ihrer eigenen Domain. Viele Plattformen signieren standardmäßig mit ihrer eigenen Domain (was die E-Mail authentifiziert, aber nicht mit Ihrer Von-Adresse aligned). Schließen Sie die Custom-Domain-DKIM-Einrichtung der Plattform ab, damit d= mit Ihrer Domain übereinstimmt.

DMARC: Richtlinie, Berichte und Alignment

SPF und DKIM prüfen jeweils etwas, aber keines von beiden kontrolliert die Adresse, die Ihre Empfänger tatsächlich sehen. DMARC schließt diese Lücke: Eine Nachricht besteht DMARC nur, wenn SPF oder DKIM besteht und die bestandene Domain mit der sichtbaren Von-Domain aligned ist. DMARC erlaubt es Ihnen außerdem, eine Richtlinie zu veröffentlichen, die Empfängern mitteilt, was bei Fehlschlägen zu tun ist, und liefert Ihnen Berichte, damit Sie sehen, wer als Ihre Domain versendet — ob legitim oder nicht.

Der DMARC-Record und die Verschärfung der Richtlinie

DMARC ist ein TXT-Record unter _dmarc.yourdomain.com. Ein sinnvoller Einstiegs-Record:

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100"

Das p=-Tag ist das Herzstück des Records und ist darauf ausgelegt, stufenweise verschärft zu werden:

• p=none — nur Überwachung. Fehlgeschlagene E-Mails werden normal zugestellt, aber Sie erhalten Berichte. Jede Einführung beginnt hier.
• p=quarantine — fehlgeschlagene E-Mails wandern in den Spam. Nutzen Sie pct=, um schrittweise hochzufahren, zum Beispiel wendet p=quarantine; pct=25 die Richtlinie auf ein Viertel der fehlgeschlagenen Nachrichten an.
• p=reject — fehlgeschlagene E-Mails werden von vornherein abgelehnt. Das ist das Ziel: vollständiger Spoofing-Schutz und Voraussetzung für BIMI.

Ein durchgesetzter (enforcement) Record sieht am Ende so aus:

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; sp=reject; adkim=s; aspf=s"

rua- und ruf-Berichte

Das rua=-Tag fordert aggregierte Berichte an: tägliche XML-Zusammenfassungen jedes empfangenden Anbieters, die zeigen, welche IPs als Ihre Domain versendet haben, was bestanden hat und was fehlgeschlagen ist. Sie enthalten keinen Nachrichteninhalt und sind das wichtigste Werkzeug, um vergessene Versanddienste aufzudecken. Das ruf=-Tag fordert Fehlerberichte (forensische Berichte) an — Stichproben einzelner fehlgeschlagener Nachrichten. Nur wenige Anbieter versenden sie, und sie können personenbezogene Daten enthalten, weshalb sich die meisten Teams allein auf rua verlassen, verarbeitet über ein DMARC-Reporting-Tool statt roh gelesen.

Alignment: Relaxed vs. Strict

Beim Alignment treten die meisten realen DMARC-Fehlschläge auf. Die Tags aspf= und adkim= steuern, wie genau die authentifizierte Domain mit der Von-Domain übereinstimmen muss. Im relaxed-Modus (r, der Standard) besteht bereits eine Subdomain-Übereinstimmung — E-Mails von news.yourdomain.com sind mit yourdomain.com aligned. Im strict-Modus (s) müssen die Domains exakt übereinstimmen. Beginnen Sie relaxed; wechseln Sie erst zu strict, wenn Ihre Berichte zeigen, dass dadurch keine legitimen E-Mails ausfallen. Denken Sie daran: Das SPF-Alignment vergleicht die Return-Path-Domain, das DKIM-Alignment vergleicht die d=-Domain, und es genügt, wenn eines der beiden mit Alignment besteht, damit DMARC insgesamt besteht.

Die drei Protokolle auf einen Blick

Schritt-für-Schritt-Rollout-Plan

1. Jeden Versanddienst prüfen (Woche 1). Erstellen Sie ein Inventar von allem, was als Ihre Domain versendet: E-Mail-Suite, Marketing-Plattform, CRM, Helpdesk, Abrechnung, Monitoring-Alerts. Übersehen Sie einen, brechen Sie später dessen E-Mail-Versand.
2. SPF veröffentlichen oder korrigieren (Woche 1). Ein Record, alle legitimen Quellen, unter 10 Abfragen, endend auf ~all (später auf -all verschärfen).
3. DKIM überall aktivieren (Wochen 1-2). Aktivieren Sie das Custom-Domain-DKIM-Signing mit 2048-Bit-Schlüsseln auf jeder Plattform aus Ihrem Inventar und verifizieren Sie jede einzelne mit einer Testnachricht.
4. DMARC mit p=none und rua-Reporting veröffentlichen (Woche 2). Keine Auswirkung auf die Zustellung — Sie sammeln nur Daten.
5. 4-6 Wochen überwachen. Überprüfen Sie die aggregierten Berichte wöchentlich. Beheben Sie jede legitime Quelle, die beim Alignment scheitert; was weiterhin fehlschlägt, ist Spoofing.
6. Schrittweise verschärfen. Wechseln Sie zu p=quarantine; pct=25, steigern Sie auf pct=100, halten Sie das ein paar Wochen und wechseln Sie dann zu p=reject. Überwachen Sie weiter — neue Tools und Anbieter werden immer wieder auftauchen.

Jenseits von DMARC: Ein Wort zu BIMI

Sobald Sie die Durchsetzung (enforcement) erreicht haben, ermöglicht BIMI (Brand Indicators for Message Identification) teilnehmenden Postfachanbietern, Ihr verifiziertes Logo neben Ihren Nachrichten anzuzeigen. Es setzt DMARC bei p=quarantine oder p=reject mit pct=100 voraus, ein SVG-Logo und — für das blaue verifizierte Häkchen von Gmail — ein Verified Mark Certificate, das an eine eingetragene Marke gebunden ist (Google akzeptiert für die Logo-Anzeige auch Common Mark Certificates). BIMI ändert das Filtering nicht direkt, aber das sichtbare Vertrauenssiegel hilft nachweislich beim Wiedererkennungswert und beim Engagement — eine schöne Belohnung dafür, die DMARC-Reise zu Ende zu bringen.

Authentifizierung + Listenvalidierung: Der vollständige Stack

Hier kommt der Teil, den viele Leitfäden auslassen: Authentifizierung belegt, wer Sie sind, nicht dass Ihre E-Mail erwünscht ist. Postfachanbieter kombinieren beide Signale. Ein perfekt authentifizierter Absender, der eine veraltete Liste zuballert, erzeugt trotzdem Bounces und Spam-Beschwerden, und Gmails eigener Schwellenwert von 0,3% Beschwerden gilt unabhängig von Ihrer DMARC-Richtlinie. Hohe Bounce-Raten schädigen genau die Absender-Reputation, die Authentifizierung eigentlich schützen soll.

Deshalb sind Authentifizierung und Listenhygiene die zwei Hälften einer einzigen Zustellbarkeitsstrategie. AT Valid führt mehr als 20 Prüfungen durch — darunter Syntax, MX, SMTP, Wegwerf- und Catch-all-Erkennung — mit 99,5% Genauigkeit, sodass für jede Nachricht, die Sie mit DKIM signieren, tatsächlich ein echter Posteingang wartet. Validieren Sie direkt bei der Erfassung über die API, oder bereinigen Sie bestehende Listen im großen Stil mit nativen Integrationen für Salesforce, HubSpot, Mailchimp, RD Station, Pipedrive, Zapier und Webhooks. Unser vollständiger Leitfaden zur E-Mail-Zustellbarkeit erklärt, wie sich beide Disziplinen gegenseitig verstärken.

Fazit

SPF, DKIM und DMARC bilden ein mehrschichtiges Identitätssystem: SPF autorisiert Server, DKIM signiert Inhalte, DMARC gleicht beides mit der Adresse ab, die Ihre Empfänger sehen, und setzt das Ergebnis durch. Seit dem Gmail- und Yahoo-Mandat sind sie Grundanforderungen, keine fortgeschrittenen Optionen — und der Weg ist klar vorgezeichnet: prüfen Sie Ihre Absender, veröffentlichen Sie SPF, aktivieren Sie 2048-Bit-DKIM, überwachen Sie bei p=none und verschärfen Sie dann auf p=reject.

Tun Sie dies zusammen mit fortlaufender Listenvalidierung, und Sie decken beide Fragen ab, die sich ein Postfachanbieter stellt: Ist dieser Absender echt, und ist diese E-Mail erwünscht? Bereit, Ihren Zustellbarkeits-Stack zu vervollständigen? Starten Sie mit 200 kostenlosen Validierungs-Credits und erleben Sie den Unterschied, den authentifizierte, validierte E-Mails machen.