SPF, DKIM und DMARC: Wie die drei zusammenarbeiten

Oft wird gefragt, ob man SPF, DKIM oder DMARC braucht — als müsste man wählen. Nein. Alle drei sind Schichten, die sich stapeln, jede füllt eine Lücke, die die anderen offen lassen. Versteh, wie sie zusammenspielen, und E-Mail-Authentifizierung hört auf, ein Kürzelbrei zu sein, und wird glasklar. Dieser Leitfaden geht jede Schicht durch und zeigt, wie sie sich zu echtem Schutz kombinieren.

Ein schnelles Modell der Reise einer E-Mail

Jede E-Mail hat zwei „Von"-Absenderidentitäten, und sie zu verwechseln ist die Wurzel der meisten Missverständnisse:

• Der Envelope-Absender (auch MAIL FROM oder Return-Path genannt) — während des SMTP-Zustelldialogs verwendet, für den Leser unsichtbar.
• Der Header From: — die freundliche Adresse, die im Posteingang angezeigt wird.

SPF prüft die erste. DKIM signiert die Nachricht. DMARC verbindet alles mit der zweiten — der, die Menschen sehen. Behalte diese Unterscheidung im Kopf, und der Rest klärt sich.

SPF: wer versenden darf

SPF (Sender Policy Framework) ist eine in deinem DNS veröffentlichte Liste der Server, die für deine Domain versenden dürfen. Beim Empfang vergleicht der Server die sendende IP mit dieser Liste — bewertet auf der Envelope-Domain.

ton-domaine.fr.  IN TXT
  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

SPF hat zwei bekannte Grenzen. Erstens authentifiziert es den Envelope, nicht das sichtbare From:: Für sich allein verhindert es also nicht, dass dem Leser deine Domain angezeigt wird. Zweitens bricht es beim Weiterleiten: Wird eine Nachricht relayt, ändert sich die sendende IP und SPF scheitert. Und es hat eine harte Obergrenze — nicht mehr als zehn DNS-Lookups während der Bewertung, sonst Fehler. SPF ist notwendig, aber nicht ausreichend.

DKIM: die Signatur, die Integrität beweist

DKIM (DomainKeys Identified Mail) wählt einen anderen Ansatz. Der versendende Server signiert jede Nachricht mit einem privaten Schlüssel; der Empfänger holt sich den passenden öffentlichen Schlüssel aus deinem DNS und prüft die Signatur. Ist sie gültig, sind zwei Dinge bewiesen: Die Nachricht wurde beim Transport nicht verändert, und sie wurde vom Inhaber des Schlüssels dieser Domain signiert.

selector1._domainkey.ton-domaine.fr.  IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkq... (clé publique)"

DKIM übersteht Weiterleitungen deutlich besser als SPF, denn die Signatur reist mit der Nachricht. Aber — und das ist die Falle, die DMARC behebt — eine gültige DKIM-Signatur beweist nur, dass irgendeine Domain die Nachricht signiert hat. Sie verlangt für sich allein nicht, dass diese Domain die deines From: ist.

Die Lücke, die beide offen lassen

Hier der Angriff, den SPF und DKIM einzeln nicht stoppen. Ein Angreifer registriert mechant.com, konfiguriert dafür ein tadelloses SPF und DKIM und versendet Mail, die beide Prüfungen besteht — für mechant.com. Dann setzt er From: pdg@ton-entreprise.com in den Header. SPF bestanden (für den Envelope, mechant.com). DKIM bestanden (signiert von mechant.com). Und doch sieht der Leser die Adresse deines Geschäftsführers. Beide Schichten sind grün, und die Usurpation kommt durch. Es braucht etwas, das die Authentifizierung mit der sichtbaren Domain verbindet. Dieses Etwas ist DMARC.

DMARC: das Alignment verbindet alles

DMARC fügt über SPF und DKIM eine entscheidende Regel hinzu: das Alignment. Eine Nachricht besteht DMARC nur, wenn sie SPF oder DKIM besteht und die authentifizierte Domain der Domain des From: entspricht.

Spiel den Angriff mit eingerichtetem DMARC noch einmal durch. Die Mail des Angreifers besteht SPF und DKIM für mechant.com — aber mechant.com entspricht nicht ton-entreprise.com im From:: Das Alignment scheitert, also scheitert DMARC, und deine Policy (idealerweise p=reject) weist die Nachricht ab. Genau diese Alignment-Prüfung macht DMARC stärker als die Summe seiner Teile. Für den grundlegenden Überblick lies was ist DMARC.

Es gibt zwei Formen des Alignments:

• SPF-Alignment — die Domain des Return-Path entspricht der Domain des From:.
• DKIM-Alignment — die signierende Domain (d=) entspricht der Domain des From:.

DMARC braucht nur ein einziges Alignment (und Bestehen), um die Nachricht zu authentifizieren. In der Praxis ist das DKIM-Alignment das zuverlässigste Ziel, denn es übersteht Weiterleitungen dort, wo SPF scheitert.

Warum du alle drei willst

Eine robuste Konfiguration nutzt jede Schicht für das, was sie am besten kann:

• SPF deklariert deine legitimen Versandserver und gibt dem Empfänger eine erste schnelle Prüfung.
• DKIM beweist Integrität und Herkunft und funktioniert auch über Weiterleitungen und Verteilerlisten hinweg.
• DMARC verbindet beides mit der sichtbaren Domain, sagt den Empfängern, was sie bei einem Fehlschlag tun sollen, und — vor allem — schickt dir die Berichte, die jede Quelle offenlegen, die sich auf dich beruft.

Nimm eine weg und du hast ein Loch: SPF ohne DMARC schützt das From: nicht; DKIM ohne DMARC erzwingt kein Alignment; DMARC ohne funktionierendes SPF/DKIM hat nichts auszurichten.

Sie in der richtigen Reihenfolge einrichten

Die richtige Deployment-Sequenz folgt den Abhängigkeiten. Veröffentliche zuerst SPF und DKIM und stelle sicher, dass deine legitimen Quellen bestehen und sich ausrichten. Veröffentliche dann DMARC mit p=none, um die Berichte zu sammeln, korrigiere die nicht ausgerichteten Quellen, die sie offenlegen, und hebe schließlich die Policy auf quarantine und dann reject. Diesen Fortschritt gehen wir Schritt für Schritt in p=reject erreichen, ohne deine E-Mails zu zerbrechen durch.

Ein konkretes Beispiel: einer Nachricht folgen

Die Theorie klärt sich schneller mit einem konkreten Fall. Stell dir vor, dein CRM versendet eine Quittung als facturation@ton-entreprise.com von den Servern des CRM-Dienstleisters. So bewerten die drei Schichten diese Nachricht:

1. SPF prüft die Envelope-Domain (Return-Path) gegen deinen veröffentlichten Eintrag. Die meisten Drittplattformen verwenden ihre eigene Bounce-Domain für den Envelope: SPF besteht also — aber für die Domain des CRM, nicht deine. Das ist ein technisch gültiges SPF-Bestehen, das für DMARC nichts bewirkt, weil es nicht mit deinem From: ausgerichtet ist.
2. DKIM prüft die Signatur. Hast du das CRM so konfiguriert, dass es mit d=ton-entreprise.com signiert — meist über einen vom Dienstleister bereitgestellten CNAME — verifiziert sich die Signatur gegen den öffentlichen Schlüssel deines DNS, und die signierende Domain ist deine.
3. Das Alignment ist der entscheidende Schritt. Hat sich SPF ausgerichtet? Nur wenn die Envelope-Domain ton-entreprise.com entsprach, was bei einem Dritten meist nicht der Fall ist. Hat sich DKIM ausgerichtet? Ja — d=ton-entreprise.com entspricht der Domain des From:.
4. DMARC-Urteil. DMARC braucht nur ein einziges ausgerichtetes Bestehen. DKIM ausgerichtet und bestanden: Die Nachricht besteht DMARC — selbst wenn SPF sich gar nicht ausgerichtet hat. Die Quittung wird zugestellt und ist vertrauenswürdig.

Dieses Beispiel erklärt eine Regel, die viele Teams überrascht: Das DKIM-Alignment ist das Arbeitspferd realer Deployments. Drittabsender richten SPF selten aus (ihr Envelope ist ihrer), können aber fast immer dazu gebracht werden, DKIM über eine Signaturdomain in deinem Namen auszurichten. Wenn du also deine aggregierten Berichte liest, ist eine Quelle, die DKIM ausgerichtet zeigt, eine geregelte Quelle; eine Quelle, die bei beiden Alignments scheitert, ist deine nächste Aufgabe.

Drei Fehler, die den Stapel zerbrechen

Selbst mit allen drei veröffentlichten Einträgen sind es immer dieselben Details, die das Gebäude zum Einsturz bringen:

• SPF, das zehn DNS-Lookups überschreitet. Zu viele gestapelte include: und SPF gibt einen PermError zurück — über der Grenze hört die Bewertung auf und die Prüfung scheitert als Ganzes. Wenn du diesen Fehler siehst, sieh unseren eigenen Leitfaden zum Limit der zehn SPF-Lookups und denk daran, deine include: zu konsolidieren.
• Schlecht ausgerichtetes DKIM. Eine gültige Signatur reicht nicht: Die signierende Domain (d=) muss deinem From: entsprechen. Die Standardsignatur einer geteilten Plattform (d=plateforme.com) besteht DKIM, aber richtet sich nicht aus — das ist die Ursache Nr. 1 für ein scheiterndes DMARC, obwohl „alles grün ist".
• Strict und relaxed verwechseln. Bei relaxed-Alignment (adkim=r/aspf=r) reicht eine Versand-Subdomain; bei strict (s) braucht es eine exakte Übereinstimmung. Wechsle zu strict, ohne geprüft zu haben, dass deine Quellen wirklich auf der Root-Domain signieren, und du zerbrichst legitime Mail.

Und DMARCbis in all dem?

Im Mai 2026 hat DMARCbis (RFC 9989) DMARC modernisiert — ohne das hier beschriebene Alignment-Prinzip anzutasten. SPF und DKIM behalten exakt dieselbe Rolle. Auf DMARC-Seite verschwindet der pct-Tag (ersetzt durch t=y für den Testmodus), ein neuer Tag np deckt nicht existierende Subdomains ab, und der DNS Tree Walk ersetzt die Public Suffix List zur Bestimmung der organisatorischen Domain. Mit anderen Worten: Dein Stapel SPF + DKIM + DMARC bleibt so gültig wie er ist — DMARCbis präzisiert ihn, es schreibt ihn nicht neu. Für die Details der Neuerungen siehe was ist DMARC.

Was passiert, wenn eine Schicht fehlt

Es hilft, sich konkret vorzustellen, was jede fehlende Schicht in der Praxis bedeutet, denn die theoretische Erklärung wird erst greifbar, wenn man die Lücke sieht. Nimm eine Domain mit SPF allein, ohne DKIM und ohne DMARC. Sie ist gegen einige plumpe Fälschungen geschützt, aber sobald eine Nachricht weitergeleitet wird — etwa über eine Verteilerliste oder eine automatische Weiterleitung —, bricht SPF, und da nichts das sichtbare From: bindet, kann ein Angreifer trotzdem deine Domain im Anzeigenamen führen. Nimm nun eine Domain mit DKIM allein: Die Integrität ist geschützt und die Signatur übersteht Weiterleitungen, aber ohne DMARC verlangt niemand, dass die signierende Domain deine ist — ein Angreifer signiert mit seiner eigenen Domain und der Leser sieht trotzdem deine Adresse. Und eine Domain mit DMARC allein, ohne funktionierendes SPF oder DKIM, hat schlicht nichts auszurichten: Die Policy verlangt ein bestandenes und ausgerichtetes SPF oder DKIM, und wenn keines davon existiert, scheitert legitime Mail an deiner eigenen Policy.

Diese drei Szenarien zeigen, warum keine Schicht die anderen ersetzt. Sie sind nicht drei Wege zum selben Ziel, sondern drei Teile eines einzigen Mechanismus. Man kann die Analogie eines Schlosses bemühen: SPF sagt, wer einen Schlüssel besitzen darf, DKIM beweist, dass der Schlüssel echt ist und die Tür seit dem Abschließen nicht aufgebrochen wurde, und DMARC prüft, dass der Schlüssel auch wirklich zu diesem Haus gehört und nicht zu einem Nachbargebäude. Fehlt einer dieser Prüfschritte, gibt es einen Weg hinein.

Die Reihenfolge der Fehlersuche

Wenn dein DMARC scheitert, obwohl du meinst, alles richtig konfiguriert zu haben, folge einer festen Diagnosereihenfolge, statt wahllos an den Einträgen zu drehen. Prüfe zuerst, ob SPF oder DKIM überhaupt besteht — reicht schon eines von beiden nicht, gibt es nichts auszurichten. Prüfe dann, ob das bestandene Protokoll auch ausgerichtet ist: Ein bestandenes SPF für die Bounce-Domain eines Drittanbieters hilft nicht, wenn diese Domain nicht deine ist. Prüfe zuletzt den Alignment-Modus (strict oder relaxed): Ein zu strikt gesetztes Alignment bricht Quellen, die auf einer Subdomain signieren. Diese Reihenfolge — Bestehen, dann Alignment, dann Modus — löst die überwältigende Mehrheit der „aber alles ist doch grün"-Fälle, weil sie den einen Punkt isoliert, an dem die Kette tatsächlich reißt.

Sieh deine drei Schichten auf einen Blick

Willst du wissen, wie deine Domain jetzt bei allen dreien steht? Unser kostenloser Analyzer prüft SPF, DKIM und DMARC gemeinsam und zeigt genau, wo die Lücken sind — einschließlich, ob deine Quellen sich wirklich ausrichten, nicht nur, ob die Einträge existieren. Du kannst deine Aufstellung auch mit der einer ganzen Branche im DMARC-Observatorium vergleichen, wo man sieht, dass das Alignment — nicht die Existenz der Einträge — das ist, was die wirklich geschützten Domains auszeichnet.

Und wenn es an der Zeit ist, diese Lücken zu füllen, identifiziert Thomas, dein virtueller CISO, jede Versandquelle, generiert die genauen SPF-, DKIM- und DMARC-Einträge zum Veröffentlichen (DMARCbis-Tags inbegriffen) und führt deine Domain bis zur vollständigen Durchsetzung. Analysiere deine Domain → oder fang hier an.