Bei DKIM vs. SPF vs. DMARC geht es nicht um eine Wahl zwischen Alternativen: Die drei Standards beantworten unterschiedliche Fragen und funktionieren nur gemeinsam. SPF listet auf, welche Server E-Mails für die Envelope-Domain senden dürfen; DKIM hängt eine Signatur an, die mit einem unter einer Domain veröffentlichten Schlüssel erstellt wurde; DMARC verlangt, dass mindestens eines der beiden Verfahren für eine Domain besteht, die zur sichtbaren Adresse in From: passt, und veröffentlicht die Richtlinie des Domaininhabers sowie die Adressen für Berichte.
Auf einen Blick
| SPF | DKIM | DMARC | |
|---|---|---|---|
| Spezifikation | RFC 7208 (2014) | RFC 6376 (2011), RFC 8301, RFC 8463 | RFC 9989, 9990, 9991 (Mai 2026), lösen RFC 7489 ab |
| Beantwortete Frage | Darf diese IP für die Envelope-Domain senden? | Hat diese Domain diesen Inhalt signiert, und ist er unverändert? | Passt eine authentifizierte Domain zur Domain in From:, und was gilt, wenn nicht? |
| Geprüfte Identität | MAIL FROM (Return-Path) und HELO | Die Domain d= in DKIM-Signature | Die Domain im Header From: |
| Veröffentlicht als | TXT-Eintrag auf der Domain | TXT-Eintrag unter selector._domainkey.domain | TXT-Eintrag unter _dmarc.domain |
| Übersteht einfache Weiterleitung | Nein (die IP des weiterleitenden Servers ist nicht aufgeführt) | Ja, wenn die Nachricht nicht verändert wird | Ja, über DKIM |
| Übersteht Mailinglisten, die Nachrichten bearbeiten | Nein | Nein (Nachrichtentext oder signierte Header ändern sich) | Nur wenn die Liste From: umschreibt oder der Empfänger ARC vertraut |
| Feste Grenzen | 10 Terme mit DNS-Abfrage pro Auswertung, 2 leere Abfragen (Void Lookups) | RSA mindestens 1024 Bit (2048 empfohlen); rsa-sha1 verboten | DNS-Tree-Walk mit höchstens 8 Abfragen |
| Wirkung für sich allein | Nur ein Ergebnis; Empfänger entscheiden | Nur ein Ergebnis; Empfänger entscheiden | Richtlinie des Domaininhabers: none, quarantine, reject |
| Berichte | Keine | Keine | Aggregate Reports im XML-Format (rua), Fehlerberichte (ruf) |
So funktionieren die drei
SPF wird während der SMTP-Sitzung ausgewertet: Der Empfänger nimmt die Domain des Envelope-Absenders (bei Bounces die aus HELO), ruft ihren TXT-Eintrag ab und gleicht die IP, von der die Verbindung kommt, mit den aufgeführten Termen ip4, ip6, a, mx und include ab. Das Ergebnis lautet pass, fail (-all), softfail (~all), neutral oder none, oder es ist ein Fehler. Jedes include, a, mx, ptr, exists und redirect kostet eine DNS-Abfrage, und bei mehr als 10 lautet das Ergebnis permerror (RFC 7208 §4.6.4) – damit ist SPF für sämtliche E-Mails der Domain unwirksam.
DKIM bildet Hashwerte über den kanonisierten Nachrichtentext (bh=) und die aufgeführten Header (h=) und signiert sie mit dem privaten Schlüssel der Domain. Der Empfänger ruft den öffentlichen Schlüssel aus einem TXT-Eintrag ab, dessen Name sich aus dem Selektor s= und der Domain d= ergibt (zum Beispiel google._domainkey.github.com), und prüft die Signatur. RFC 8301 verbietet rsa-sha1 und verlangt Schlüssel mit mindestens 1024 Bit; RFC 8463 ergänzt ed25519-sha256, das meist parallel zu einer RSA-Signatur eingesetzt wird, weil Verifizierer es noch nicht durchgängig unterstützen.
DMARC wird nach beiden ausgewertet: Es besteht, wenn SPF für eine an From: ausgerichtete Domain besteht oder eine DKIM-Signatur für eine an From: ausgerichtete Domain erfolgreich geprüft wird. Das Alignment ist standardmäßig locker (relaxed: dieselbe Organisationsdomain, sodass mail.example.com an example.com ausgerichtet ist) oder mit aspf=s und adkim=s strikt (strict).
Das folgende Skript liest echte Einträge (20. Oktober 2026, dig 9.10.6 und OpenSSL 3.6.5).
echo "== SPF: google.com and its include"
dig +short TXT google.com | grep "v=spf1"
dig +short TXT _spf.google.com
echo "== DMARC: google.com and github.com"
dig +short TXT _dmarc.google.com
dig +short TXT _dmarc.github.com
echo "== DKIM: key size behind two github.com selectors"
for sel in google pf2023; do
printf '%s: ' "$sel"
dig +short TXT "$sel._domainkey.github.com" | tr -d '" \n' | sed 's/.*p=//' \
| openssl base64 -d -A | openssl pkey -pubin -inform DER -noout -text | head -1
done
== SPF: google.com and its include
"v=spf1 include:_spf.google.com ~all"
"v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17 ip6:2001:4860:4864::/56 ip6:2404:6800:4864::/56 ip6:2607:f8b0:4864::/56 ip6:2800:3f0:4864::/56 ip6:2a00:1450:4864::/56 ip6:2c0f:fb50:4864::/56 ~all"
== DMARC: google.com and github.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"
"v=DMARC1; p=quarantine; sp=reject; pct=100; rua=mailto:dmarc@github.com; ruf=mailto:dmarc@github.com; fo=1"
== DKIM: key size behind two github.com selectors
google: Public-Key: (2048 bit)
pf2023: Public-Key: (1024 bit)
Drei Details fallen auf. Der SPF-Eintrag von Google endet auf ~all (softfail), während die DMARC-Richtlinie reject lautet: Wird DMARC durchgesetzt, entscheidet das DMARC-Ergebnis, der SPF-Qualifier spielt also kaum eine Rolle. GitHub veröffentlicht noch pct=100, ein Tag, das RFC 9989 entfernt hat; Empfänger ignorieren unbekannte Tags, und 100 war der Standardwert, daher schadet es nicht. Und einer der Selektoren von GitHub nutzt noch einen 1024-Bit-Schlüssel, das Minimum, das RFC 8301 zulässt. Der E-Mail-Authentifizierungs-Analyzer führt dieselben Prüfungen für jede beliebige Domain aus.
Das Alignment entscheidet über das Ergebnis
Die Tabelle zeigt typische Abläufe für eine Nachricht mit From: news@example.com.
| Ablauf | SPF | DKIM | DMARC |
|---|---|---|---|
Eigener Server, signiert als example.com | pass, ausgerichtet | pass, ausgerichtet | pass |
E-Mail-Dienstleister mit eigener Bounce-Domain, signiert als example.com | pass für die Domain des Dienstleisters, nicht ausgerichtet | pass, ausgerichtet | pass (DKIM) |
| Dienstleister, der nur mit seiner eigenen Domain signiert | pass, nicht ausgerichtet | pass, nicht ausgerichtet | fail |
| Unverändert weitergeleitet durch eine Postfachregel | fail (IP des weiterleitenden Servers) | pass, ausgerichtet | pass (DKIM) |
| Mailingliste fügt eine Fußzeile oder ein Tag im Betreff hinzu | fail oder nicht ausgerichtet | fail (Body-Hash) | fail, außer From: wird umgeschrieben oder ARC gilt als vertrauenswürdig |
Gefälschtes From: von einem fremden Server | fail oder none | none | fail, Richtlinie wird angewendet |
Die dritte Zeile zeigt den häufigsten Fehler bei der Einrichtung: Ein Absender besteht SPF und DKIM, fällt aber bei DMARC durch, weil keine der beiden authentifizierten Domains deine ist. Richte jeden Dienstleister so ein, dass er mit einem Schlüssel unter deiner Domain signiert (meist per CNAME auf den Schlüssel des Dienstleisters), und nutze eine eigene Bounce-Domain, wenn auch SPF ausgerichtet sein soll.
Weiterleitung, Mailinglisten und ARC
SPF authentifiziert den letzten Hop, daher scheitert SPF bei jeder Weiterleitung; mit einem Sender Rewriting Scheme besteht SPF zwar wieder für die eigene Domain des weiterleitenden Servers, ist damit aber nie ausgerichtet. DKIM authentifiziert den Inhalt, übersteht also Relays, die die Nachricht unangetastet lassen, und scheitert, wenn Listen Fußzeilen oder Tags hinzufügen. ARC (RFC 8617, experimentell) erlaubt einer Zwischenstation, die Authentifizierungsergebnisse, die sie gesehen hat, zu versiegeln, und Empfänger, die dieser versiegelnden Stelle vertrauen, können die Nachricht trotz des DMARC-Fehlschlags annehmen; der ARC-Ketten-Viewer zeigt die Kette. Die verbleibende Schwachstelle ist DKIM-Replay: Eine gültig signierte Nachricht lässt sich erneut an neue Empfänger versenden; eine IETF-Arbeitsgruppe geht das in ihren DKIM2-Entwürfen an.
Was Postfachanbieter verlangen
Seit dem 1. Februar 2024 verlangt Gmail von jedem Absender SPF oder DKIM, gültiges Forward- und Reverse-DNS, TLS und eine gemeldete Spamrate unter 0,3 %. Absender, die 5.000 oder mehr Nachrichten pro Tag an private Gmail-Konten senden, brauchen außerdem SPF und DKIM, einen DMARC-Eintrag (p=none genügt), ein an SPF oder DKIM ausgerichtetes From: und für Marketing-E-Mails eine Abmeldung mit einem Klick (RFC 8058). Yahoo hat zur selben Zeit entsprechende Regeln eingeführt. Microsoft wendet dieselben Schwellenwerte seit dem 5. Mai 2025 auf Outlook.com an und lehnt nicht konforme E-Mails mit 550 5.7.515 ab. BIMI-Logos setzen zusätzlich DMARC mit quarantine oder reject voraus.
RFC 9989 (Mai 2026) hat DMARC auf den Standards Track gehoben und den Eintrag geändert: pct, rf und ri entfallen, t=y ersetzt pct=0 zum Testen, np legt eine Richtlinie für nicht existierende Subdomains fest, psd kennzeichnet Public-Suffix-Domains, und ein DNS-Tree-Walk ersetzt die Public Suffix List bei der Ermittlung der Organisationsdomain.
Wofür jedes Verfahren gedacht ist
- SPF: Autorisiere deine eigenen ausgehenden Server und die Dienstleister, die deine Domain als Bounce-Adresse verwenden; veröffentliche
v=spf1 -allauf Domains und Subdomains, die nie E-Mails senden. - DKIM: Signiere alle ausgehenden E-Mails mit deiner eigenen Domain, auch die, die über Dienstleister verschickt werden; rotiere die Selektoren mindestens jährlich und ersetze 1024-Bit-Schlüssel durch 2048-Bit-Schlüssel.
- DMARC: Sammle zuerst Berichte und setze die Richtlinie erst dann durch; ergänze
np=reject(odersp=reject), damit Angreifer keine erfundenen Subdomains nutzen können. - Geparkte Domains:
v=spf1 -all,v=DMARC1; p=reject;und keine DKIM-Selektoren. - Transport- und Inhaltsschutz sind getrennte Probleme: Nutze MTA-STS für TLS zwischen Servern und S/MIME oder OpenPGP für Ende-zu-Ende-Signaturen.
Hinweise zur Migration
- Erfasse die Absender anhand der DMARC-Aggregate-Reports bei
p=noneüber zwei bis vier Wochen; jede legitime Quelle muss ausgerichtetes DKIM, ausgerichtetes SPF oder beides aufweisen. - Bring zuerst DKIM in Ordnung: Aktiviere bei jedem Dienstleister das Signieren mit deiner eigenen Domain, veröffentliche 2048-Bit-Schlüssel (der DKIM-Eintragsgenerator teilt sie in Strings mit 255 Zeichen auf) und prüfe sie mit dem DKIM-Debugger.
- Kürze SPF auf unter 10 Abfragen, indem du ungenutzte Includes entfernst; löse Includes nur dann in IP-Bereiche auf, wenn du diese automatisch aktuell halten kannst.
- Setze die Richtlinie schrittweise durch: zuerst
p=quarantinemitt=yzum Beobachten, dannp=quarantine, dannp=reject; sorge dafür, dass weiterhin Berichte anruaeingehen. - Schütze Subdomains mit
spodernpund veröffentliche Null-Einträge auf jeder Domain, die keine E-Mails senden soll.
Quellen
- RFC 7208, SPF (§4.6.4, Grenzen für DNS-Abfragen)
- RFC 6376, DKIM, RFC 8301, kryptografische Aktualisierung von DKIM, RFC 8463, Ed25519 für DKIM
- RFC 9989, DMARC, RFC 9990, Aggregate Reports, RFC 9991, Fehlerberichte
- RFC 8617, ARC
- RFC 8058, Abmeldung mit einem Klick
- Google: Richtlinien für E-Mail-Absender
- Microsoft: strengere Anforderungen im E-Mail-Ökosystem für Absender mit hohem Volumen