SPF, DKIM und DMARC verstehen
Was jeder der drei E-Mail-Authentifizierungsstandards technisch tatsächlich prüft, wo die Grenzen liegen, und was sie gemeinsam nicht verhindern.
E-Mail wurde in den 1970er- und 1980er-Jahren entwickelt, zu einer Zeit, in der Absenderadressen grundsätzlich als vertrauenswürdig galten. Diese fehlende eingebaute Authentifizierung wird bis heute für Spoofing und Phishing ausgenutzt. Drei ergänzende Standards adressieren dieses Problem gemeinsam - aber jeder prüft etwas anderes, und keiner davon prüft, was viele Nutzer intuitiv annehmen.
1. SPF: Wer darf senden?
SPF (Sender Policy Framework) definiert per DNS-TXT-Eintrag, welche Server berechtigt sind, E-Mails im Namen einer Domain zu versenden. Empfangende Server prüfen bei eingehender Post, ob der sendende Server auf dieser Liste steht. Entscheidend dabei: SPF prüft technisch den sogenannten Envelope-From (die Absenderadresse auf Protokollebene, die für die Zustellung verwendet wird), nicht zwingend die im E-Mail-Programm sichtbare Absenderadresse im From-Header. Beide können auseinanderfallen, ohne dass SPF das erkennt - dafür ist erst die Alignment-Prüfung von DMARC zuständig.
2. SPF-Grenzen: Weiterleitungen und Lookup-Limit
SPF hat zwei praktische Schwachstellen, die regelmäßig für Probleme sorgen. Erstens bricht SPF häufig bei klassischen E-Mail-Weiterleitungen: Leitet ein Server eine E-Mail unverändert an eine andere Adresse weiter, erscheint dieser weiterleitende Server als Absender-IP - steht er nicht in der SPF-Liste der ursprünglichen Domain, schlägt die Prüfung fehl, obwohl die E-Mail ursprünglich legitim war. Zweitens begrenzt SPF die Anzahl verschachtelter DNS-Lookups (etwa durch include-Verweise auf andere Domains) auf maximal zehn; wird dieses Limit überschritten, gilt die SPF-Prüfung als fehlgeschlagen, selbst wenn der eigentliche Eintrag inhaltlich korrekt aufgebaut ist. Gerade Unternehmen mit vielen verschiedenen Versanddiensten (Newsletter-Tool, CRM, Support-System) stoßen an dieses Limit, ohne es zu bemerken, bis Zustellprobleme auftreten.
3. DKIM: Wurde die Nachricht verändert?
DKIM (DomainKeys Identified Mail) signiert E-Mails kryptografisch beim Versand. Der Empfänger kann anhand eines öffentlichen Schlüssels aus dem DNS prüfen, ob die signierten Kopfzeilen und Teile der Nachricht seit dem Versand unverändert sind und tatsächlich von der im Signatur-Header genannten Domain (dem d=-Wert) stammen. Wichtig: Diese signierende Domain muss nicht zwingend mit der sichtbaren Absenderadresse im From-Header übereinstimmen. Ein Angreifer kann eine eigene, korrekt signierte Domain verwenden und trotzdem eine davon abweichende, gefälschte Adresse im From-Header anzeigen lassen - eine gültige DKIM-Signatur bestätigt also für sich allein nicht, dass die sichtbare Absenderadresse vertrauenswürdig ist.
4. DKIM-Grenzen: Mailinglisten und Body-Änderungen
Da DKIM Kopfzeilen und Nachrichteninhalt signiert, invalidiert jede nachträgliche Änderung an diesen signierten Teilen die Signatur. Das betrifft in der Praxis vor allem Mailinglisten und manche Weiterleitungsdienste, die typischerweise Betreffzeilen ergänzen oder Fußzeilen an den Nachrichtentext anhängen - die ursprüngliche DKIM-Signatur wird dadurch ungültig, selbst wenn die Nachricht inhaltlich weiterhin vom legitimen Absender stammt. Manche solcher Dienste signieren die E-Mail deshalb selbst erneut mit ihrer eigenen Domain (ARC ist ein ergänzender Standard, der genau für dieses Weiterleitungsproblem entwickelt wurde).
5. DMARC: Was passiert bei einem Fehlschlag, und was gehört zusammen?
SPF und DKIM allein legen nicht fest, was mit E-Mails geschehen soll, die eine oder beide Prüfungen nicht bestehen - genau das regelt DMARC über eine Richtlinie (p=none, p=quarantine oder p=reject). Zusätzlich verlangt DMARC sogenanntes Alignment: Die bei SPF oder DKIM erfolgreich geprüfte Domain muss mit der sichtbaren From-Domain übereinstimmen (bei striktem Alignment exakt, bei entspanntem Alignment reicht eine gemeinsame Hauptdomain). Erst diese Alignment-Prüfung schließt die Lücke, die SPF und DKIM einzeln offenlassen: Eine E-Mail kann SPF oder DKIM technisch bestehen und trotzdem am DMARC-Alignment scheitern, wenn die geprüfte Domain nicht zur sichtbaren Absenderdomain passt.
6. DMARC-Berichte: aggregiert und forensisch
DMARC unterstützt zwei Arten von Berichten an den Domaininhaber: aggregierte Berichte (rua), die periodisch zusammenfassen, welche Server im Namen der Domain E-Mails versendet haben und ob sie SPF/DKIM/Alignment bestanden haben, sowie forensische Berichte (ruf) zu einzelnen fehlgeschlagenen Nachrichten. Aggregierte Berichte sind in der Praxis das wichtigere Werkzeug, um systematisch zu erkennen, welche legitimen und welche potenziell missbräuchlichen Quellen im Namen der eigenen Domain senden.
7. Rollout-Strategie in der Praxis
Ein typischer Aufbau: Zunächst werden SPF und DKIM für alle genutzten Versanddienste korrekt eingerichtet und die DMARC-Richtlinie auf reine Beobachtung gesetzt (p=none), während die aggregierten Berichte über einige Wochen ausgewertet werden. Zeigen die Berichte, dass alle legitimen Quellen korrekt erfasst sind, wird die Richtlinie schrittweise verschärft - zunächst auf Quarantäne (p=quarantine), später auf vollständige Ablehnung nicht authentifizierter E-Mails (p=reject). Der Parameter pct= erlaubt zusätzlich, eine Richtlinie zunächst nur auf einen Prozentsatz der E-Mails anzuwenden, um das Risiko eines abrupten Wechsels weiter zu reduzieren, und sp= erlaubt eine eigene Richtlinie für Subdomains, die von der Hauptdomain abweichen kann.
8. Häufige Fehler
Der häufigste Fehler ist, direkt auf p=reject zu springen, ohne vorher die aggregierten Berichte ausgewertet zu haben - legitime, aber noch nicht korrekt im SPF-Eintrag erfasste Quellen (etwa ein neu eingeführtes Marketing-Tool) werden dadurch abrupt blockiert. Ein zweiter häufiger Fehler ist, DKIM nur für die Hauptdomain einzurichten, aber Subdomains oder einzelne Versanddienste (etwa einen separaten Newsletter-Versender) zu vergessen, sodass deren E-Mails am Alignment scheitern. Ein dritter Fehler ist die Annahme, eine gültige DKIM-Signatur oder ein bestandener SPF-Check allein bedeute automatisch, dass die sichtbare Absenderadresse vertrauenswürdig sei - das stimmt erst, wenn DMARC-Alignment tatsächlich geprüft und durchgesetzt wird.
9. Was diese drei Standards zusammen nicht verhindern
Auch mit korrekt konfiguriertem SPF, DKIM und einer strikten DMARC-Richtlinie bleiben Angriffsvektoren offen, die keiner dieser Standards adressiert: Look-alike-Domains (etwa beispiel-support.de statt beispiel.de) bestehen alle drei Prüfungen problemlos, da es sich technisch um eine andere, eigenständig registrierte Domain handelt. Ebenso ungeschützt bleibt die Manipulation des angezeigten Namens (Display Name Spoofing), sofern die tatsächliche Absenderadresse dahinter nicht verändert wird, sowie kompromittierte, aber legitime Konten, die technisch korrekt authentifizierte E-Mails versenden. SPF, DKIM und DMARC verhindern Domain-Spoofing im technischen Sinne - sie ersetzen keine Wachsamkeit gegenüber Phishing-Inhalten oder Nutzerschulung.
10. Wie prüfst du das
Der eigene SPF-Eintrag lässt sich per DNS-TXT-Abfrage der Domain einsehen, der DKIM-Eintrag über den domain- und dienstspezifischen Selector-Namen (selector._domainkey.domain.tld). Ob eine konkrete eingehende E-Mail SPF, DKIM und DMARC-Alignment tatsächlich bestanden hat, zeigen die meisten Mailserver in den vollständigen, sonst ausgeblendeten E-Mail-Headern (Feld Authentication-Results). Für den eigenen Versand ist die systematische Auswertung der aggregierten DMARC-Berichte der zuverlässigste Weg, um zu erkennen, welche Quellen tatsächlich im Namen der eigenen Domain senden - inklusive solcher, die man selbst noch nicht auf dem Schirm hatte.
11. Warum das auch für nicht sendende Domains relevant ist
Auch Domains, die selbst nie aktiv E-Mails versenden, sollten einen SPF-Eintrag mit -all (keine Server autorisiert) und eine strikte DMARC-Richtlinie setzen - sonst können Angreifer die Domain ungehindert für Phishing-Kampagnen missbrauchen, ohne dass der eigentliche Inhaber der Domain jemals selbst eine E-Mail verschickt.
12. Entscheidungsrahmen
- Noch kein SPF/DKIM/DMARC eingerichtet? → SPF und DKIM für alle bekannten Versandquellen einrichten, DMARC mit
p=nonestarten. - DMARC läuft bereits mit
p=none? → Aggregierte Berichte mehrere Wochen auswerten, bis alle legitimen Quellen erfasst sind. - Alle legitimen Quellen bestätigt erfasst? → Schrittweise auf
p=quarantine, dannp=rejectverschärfen, optional überpct=gestaffelt. - Domain versendet selbst keine E-Mails? → SPF mit
-allund DMARC mitp=rejecttrotzdem setzen. - SPF-Prüfung schlägt unerwartet fehl? → Zuerst auf Überschreitung des Zehn-Lookup-Limits und auf Weiterleitungen als Ursache prüfen, bevor der Eintrag weiter verändert wird.