SPF vs. DKIM vs. DMARC: Was jedes Einzelne wirklich tut

Veröffentlicht am 3. Juni 2026 · 6 Min. Lesezeit · spFlat! Blog

Wenn Sie jemals die E-Mail-Authentifizierung für eine Domain eingerichtet haben, sind Sie auf drei Akronyme gestoßen: SPF, DKIM und DMARC. Sie werden oft im selben Atemzug genannt, aber sie tun grundlegend unterschiedliche Dinge.

Die Verwirrung ist verständlich. Sie alle leben im DNS, sie alle schützen Ihre E-Mail-Reputation und sie alle müssen zusammenarbeiten. Aber sie miteinander zu verwechseln ist, als würde man ein Schloss, einen Schlüssel und eine Überwachungskamera verwechseln — sie funktionieren als System, aber sie sind nicht dasselbe.

Hier ist, was jedes Einzelne wirklich tut, in einfacher Sprache.

Die Kurzversion

Sie benötigen mindestens SPF oder DKIM, das bestanden wird, damit DMARC funktioniert. Und wenn Sie eine zuverlässige E-Mail-Zustellung wollen, brauchen Sie alle drei.

SPF: Die Besucherliste

Das Sender Policy Framework ist ein DNS-Eintrag, der auflistet, welche IP-Adressen E-Mails für Ihre Domain senden dürfen. Es ist das älteste der drei (RFC 4408, 2006) und am einfachsten zu verstehen.

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Wenn ein empfangender Server eine E-Mail erhält, die behauptet, von yourdomain.com zu stammen, schlägt er Ihren SPF-Eintrag nach und prüft, ob die IP-Adresse des sendenden Servers auf der Liste steht.

Was SPF gut macht:

• Stoppt einfaches Domain-Spoofing (Vortäuschen der Domain)
• Schnell zu überprüfen — Empfänger können auf SMTP-Ebene ablehnen
• Gut verstanden und weithin unterstützt

Was SPF nicht tut:

• Es signiert oder verschlüsselt die Nachricht nicht
• Es verhindert nicht, dass die E-Mail eines legitimen Absenders weitergeleitet wird und dann fehlschlägt (dies wird als "SPF-Bruch bei Weiterleitung" bezeichnet)
• Es sagt den Empfängern nicht, was sie tun sollen, wenn die Prüfung fehlschlägt

DKIM: Das Wachssiegel

DomainKeys Identified Mail verwendet Public-Key-Kryptografie, um Ihre ausgehenden E-Mails zu signieren. Sie generieren ein Schlüsselpaar, legen den öffentlichen Schlüssel in einem DNS-Eintrag ab (selector._domainkey.yourdomain.com), und Ihr Mailserver signiert jede ausgehende Nachricht mit dem privaten Schlüssel.

default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G..."

Wenn ein Empfänger Ihre E-Mail erhält, sucht er den öffentlichen Schlüssel in Ihrem DNS, entschlüsselt die Signatur und prüft, ob der Nachrichtentext und die Header übereinstimmen. Ist dies der Fall, ist die E-Mail DKIM-verifiziert.

Was DKIM gut macht:

• Beweist, dass die E-Mail beim Transport nicht verändert wurde
• Überlebt E-Mail-Weiterleitungen (SPF bricht, DKIM nicht)
• Bietet eine kryptografische Ebene, mit der SPF nicht mithalten kann

Was DKIM nicht tut:

• Es verifiziert nicht den Absender — nur die Signatur. Ein Angreifer kann DKIM für seine eigene Domain einrichten und E-Mails signieren, die immer noch behaupten, von Ihrer zu stammen (obwohl sie die DMARC-Ausrichtung nicht bestehen würden)
• Es verhindert nicht, dass jemand unsignierte E-Mails mit Ihrer Domain sendet
• Es sagt den Empfängern nicht, was sie bei einem Fehlschlag tun sollen

DMARC: Der Richtlinien-Macher

Domain-based Message Authentication, Reporting & Conformance ist die Schicht, die auf SPF und DKIM aufbaut. Sie sagt den empfangenden Mailservern: "Wenn eine E-Mail, die behauptet, von meiner Domain zu stammen, SPF und DKIM nicht besteht, hier ist, was Sie damit tun sollen."

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100

DMARC führt auch das Konzept des Alignments (Ausrichtung) ein: Selbst wenn SPF oder DKIM einzeln bestehen, muss die Domain im From:-Header mit der Domain übereinstimmen, die in der SPF-Prüfung oder DKIM-Signatur verwendet wurde. Dies verhindert einen ausgeklügelten Angriff, bei dem jemand mit seinem eigenen authentifizierten Server von yourdomain.com sendet.

Drei DMARC-Richtlinien:

• p=none — nur beobachten. Keine Aktion wird unternommen. Wird verwendet, um Daten zu sammeln, bevor man es erzwingt
• p=quarantine — fehlgeschlagene E-Mails als Spam markieren
• p=reject — fehlgeschlagene E-Mails komplett ablehnen. Die strengste Richtlinie

Was DMARC gut macht:

• Gibt Ihnen die Kontrolle darüber, wie Empfänger mit nicht authentifizierten E-Mails umgehen
• Bietet tägliche/wöchentliche Berichte (rua), die zeigen, wer E-Mails über Ihre Domain versendet
• Unerlässlich für den Markenschutz gegen exaktes Domain-Spoofing

Was DMARC nicht tut:

• Es authentifiziert die E-Mail nicht selbst — es verlässt sich auf SPF- und DKIM-Ergebnisse
• Es repariert keine fehlerhaften SPF- oder DKIM-Konfigurationen
• Es hilft nicht, wenn SPF PermErrors Ihre SPF-Prüfungen im Hintergrund ungültig machen

Wie sie zusammenarbeiten

Stellen Sie sich das als ein Drei-Schichten-System vor:

1. SPF prüft, wer sie gesendet hat (Server-IP)
2. DKIM prüft, was gesendet wurde (Nachrichtenintegrität)
3. DMARC entscheidet, was zu tun ist, wenn etwas nicht stimmt

Damit DMARC bestanden wird, muss eine E-Mail mindestens eines von SPF oder DKIM bestehen und auf die Domain im From:-Header ausgerichtet (aligned) sein.

Dies ist der Grund, warum E-Mails manchmal DMARC bestehen, selbst wenn SPF fehlschlägt — DKIM war gültig und ausgerichtet, was ausreicht. Und umgekehrt kann eine E-Mail SPF bestehen, aber bei DMARC durchfallen, wenn es keine DKIM-Signatur gibt und die SPF-Domain nicht mit der From:-Domain übereinstimmt.

Die häufigsten Fehler

1. SPF ist kaputt, aber Sie wissen es nicht.
   Das passiert ständig. Der Eintrag validiert syntaktisch, also melden DNS-Tools "OK", aber verschachtelte Includes treiben ihn über 10 Lookups. Jede SPF-Prüfung liefert einen PermError. Ihre DMARC-Berichte zeigen eine schockierende Menge an SPF-Fehlern, von denen Sie nichts wussten.
2. DMARC auf p=reject ohne Monitoring.
   Wenn Sie auf reject umschalten, bevor Sie bestätigt haben, dass alle Ihre legitimen Absender die Authentifizierung bestehen, werden Sie unbemerkt E-Mails verlieren. Starten Sie bei p=none, lesen Sie Ihre Berichte und steigern Sie sich dann.
3. DKIM-Selektor-Verfall (Rot).
   DKIM-Schlüssel können ablaufen oder rotiert werden, ohne Ihr DNS zu aktualisieren. Ein Selektor, der letztes Jahr funktioniert hat, kann heute NXDOMAIN zurückgeben, was die DKIM-Überprüfung für jede E-Mail unterbricht, die noch mit dem alten Schlüssel signiert ist.
4. Drittanbieter-Absender nicht abgedeckt.
   Sie richten DMARC für Ihre Domain ein, aber Ihr CRM versendet Marketing-E-Mails über eine andere Subdomain ohne SPF oder DKIM. Diese E-Mails schlagen bei der Authentifizierung komplett fehl.

Wo Sie anfangen sollten

Wenn Sie dies zum ersten Mal einrichten oder eine bestehende Konfiguration überprüfen:

1. Überprüfen Sie Ihren SPF-Eintrag — holen Sie sich die volle Lookup-Anzahl einschließlich verschachtelter Includes
2. Verifizieren Sie DKIM — stellen Sie sicher, dass es für jeden von Ihnen genutzten E-Mail-Dienst korrekt veröffentlicht wird
3. Starten Sie DMARC bei p=none mit einer Berichts-Adresse (rua), die Sie tatsächlich abrufen
4. Überprüfen Sie die Berichte 2-4 Wochen lang, bevor Sie zu p=quarantine oder p=reject wechseln
5. Kontinuierliche Überwachung — IP-Änderungen von Anbietern, Schlüsselrotationen und neue Dienste beeinflussen alle Ihre Authentifizierungskette