Stand: August 2026
TLDR-Box
SPF, DKIM und DMARC bilden das Drei-Säulen-Modell der E-Mail-Authentifizierung. SPF prüft IP-basiert, ob der versendende Server für die Domain autorisiert ist. DKIM signiert den Mail-Inhalt kryptografisch, sodass Empfänger die Unversehrtheit verifizieren können. DMARC verknüpft beide Mechanismen über eine Policy (p=none/quarantine/reject) und fordert Alignment: Die Domain im sichtbaren From-Header muss mit der SPF-Return-Path-Domain oder der DKIM-Signatur-Domain (d=) übereinstimmen. Nur bei Erfüllung greift die DMARC-Regel. Reporting-Adressen (rua/ruf) liefern tägliche XML-Berichte, mit denen Fehlkonfigurationen erkannt und legitime Absender nachgepflegt werden. Die Implementierungsreihenfolge ist bindend: erst SPF, dann DKIM, zuletzt DMARC – weil die Policy auf funktionierenden Checks aufbaut.
Definition
Um E-Mail-Spoofing effektiv zu unterbinden, greifen moderne Sicherheitskonzepte auf ein Drei-Säulen-Modell zurück. Die Grundlage bilden die Protokolle SPF, DKIM und DMARC, die jeweils unterschiedliche Aspekte der Absenderidentität prüfen. Ein tiefgreifendes Verständnis dieser Mechanismen ist notwendig, um die Zustellbarkeit zu sichern und Angriffe abzuwehren, wie es auch Experten in aktuellen Leitfäden zu DMARC, SPF und DKIM beschreiben.
SPF (Sender Policy Framework) fungiert als eine Art autorisierte Liste im DNS. Über einen spezifischen DNS-Eintrag legen Administratoren fest, welche IP-Adressen oder Server berechtigt sind, E-Mails im Namen einer Domain zu versenden. Damit prüft der Empfänger-Server rein IP-basiert, ob der Absender legitim ist. Cloudflare erläutert zudem die Unterschiede dieser technischen Mechanismen im Detail.
Während SPF die Server autorisiert, sichert DKIM (DomainKeys Identified Mail) den Inhalt ab. Das Protokoll fügt jeder ausgehenden Nachricht eine digitale Signatur hinzu. Der Empfänger nutzt den im DNS hinterlegten öffentlichen Schlüssel, um die Integrität der Mail zu verifizieren. So wird sichergestellt, dass die Nachricht auf dem Transportweg nicht unbemerkt manipuliert wurde.
DMARC (Domain-based Message Authentication, Reporting & Conformance) bildet die Brücke zwischen beiden Verfahren. Es erzwingt das sogenannte Alignment: Die Domäne im sichtbaren From-Header muss mit der SPF-Domäne oder der DKIM-Signatur übereinstimmen. Zudem definiert DMARC die Konsequenz bei Fehlschlägen, etwa das Verschieben in den Spam-Ordner oder die komplette Ablehnung der Nachricht.
Seit Februar 2024 fordern Google und Yahoo für Bulk-Versender ab 5.000 Mails täglich zwingend SPF, DKIM und eine DMARC-Policy von mindestens p=none. Wer die Anforderungen nicht erfüllt, landet im Spam-Ordner oder wird direkt abgelehnt. Dieser Durchsetzungsdruck der Large Mailbox Provider macht die Implementierung zum geschäftskritischen Standard.
SPF – Sender Policy Framework
Der SPF-Eintrag liegt als TXT-Record im DNS der Absender-Domain. Er listet alle IP-Adressen und Subdomains auf, die berechtigt sind, E-Mails für diese Domain zu versenden. Beim Empfang fragt der Mailserver den Record ab und gleicht die IP des einliefernden Servers mit der Liste ab. Stimmt die IP nicht überein, lehnt der Empfänger die Nachricht ab oder schiebt sie in den Spam-Ordner.
Ein typischer Eintrag sieht so aus: v=spf1 ip4:203.0.113.0/24 include:_spf.provider.example ~all. Das ~all am Ende signalisiert Softfail – verdächtig, aber nicht hart blockiert. Für striktere Policies nutzen Administratoren -all (Hardfail).
Kritisch ist das DNS-Lookup-Limit: RFC 7208 begrenzt die Prüfung auf zehn Lookups pro SPF-Check. Jede include:-Anweisung, jedes a– oder mx-Mechanismus zählt dazu. Werden mehr als zehn Lookups nötig, bricht die Validierung ab und die Mail gilt als unauthentifiziert. Große Versender mit vielen Drittanbietern (Newsletter, CRM, Transactional) stoßen schnell an diese Grenze.
Lösungen: Nicht mehr genutzte include:-Einträge entfernen, Subdomains für separate Dienste delegieren oder SPF-Flattening einsetzen, bei dem die IP-Netze statisch in den Haupt-Record aufgelöst werden. Regelmäßige Audits verhindern, dass neue Dienste stillschweigend das Limit sprengen. Ein Praxis-Leitfaden zeigt, wie man die Lookups zählt und optimiert – hier nachlesbar.
Wichtig: SPF prüft nur den Envelope-Sender (Return-Path), nicht den sichtbaren From-Header. Deshalb allein kein Schutz vor Spoofing der Absenderadresse. Erst in Kombination mit DKIM und DMARC entsteht wirksame Identitätsprüfung.
DKIM – DomainKeys Identified Mail
DKIM erzeugt ein Schlüsselpaar. Der private Schlüssel bleibt auf dem Mailserver, der öffentliche Schlüssel wird als TXT-Record im DNS veröffentlicht. Jede ausgehende Nachricht wird mit dem privaten Schlüssel signiert. Der Empfänger kann die Signatur mit dem öffentlichen Schlüssel prüfen und sicherstellen, dass der Inhalt nicht verändert wurde. Für die Signatur wird ein Header-Field DKIM-Signature angehängt, das Signatur-Algorithmus, Signatur-Domain und Signatur-Selector enthält. Der Selector ermöglicht die gleichzeitige Nutzung mehrerer Schlüssel, was die Verwaltung vereinfacht.
Ein häufiger Fehler ist die fehlende Alignment-Prüfung. DMARC verlangt, dass die Domain im From-Header mit der DKIM-Domain übereinstimmt. Ohne Alignment schlägt die DMARC-Prüfung fehl, selbst wenn die Signatur gültig ist. Deshalb sollte der Selector so gewählt werden, dass er die gleiche Domain wie im From-Header verwendet.
Die Schlüsselrotation ist ein Muss. Kompromittierte Schlüssel können von Angreifern ausgenutzt werden. Die meisten Anbieter empfehlen eine Rotation alle 6 bis 12 Monate. Automatisierte Rotation kann über Milter-Plugins oder die Verwaltungsoberfläche des Mail-Providers erfolgen. Nach jeder Rotation muss der neue öffentliche Schlüssel im DNS aktualisiert werden.
Ein Beispiel für die Implementierung findet sich in der Mikas-Anleitung und in der Twilight-Networks-Dokumentation. Dort werden die Schritte von der Schlüsselgenerierung bis zur DNS-Eintragung detailliert beschrieben.
Vergeben Sie pro aussendendem System einen eigenen Selector (z. B. newsletter._domainkey, crm._domainkey). So lässt sich ein einzelner Schlüssel widerrufen, ohne den gesamten Mailverkehr zu unterbrechen. RSA 2048 Bit gelten als Minimum; Ed25519 bietet kürzere Signaturen und schnellere Verifikation.
DMARC – Domain-based Message Authentication, Reporting & Conformance
DMARC bildet das entscheidende Bindeglied in der E-Mail-Sicherheitsarchitektur. Während SPF die IP-Adresse validiert und DKIM die Integrität der Nachricht kryptografisch absichert, fungiert DMARC als übergeordnete Steuerungsinstanz. Der Mechanismus verknüpft die Ergebnisse der beiden vorangegangenen Verfahren und erzwingt ein sogenanntes Alignment. Das bedeutet: Die Domäne im sichtbaren „From“-Header der E-Mail muss exakt mit der Domäne aus dem SPF-Return-Path oder der DKIM-Signatur übereinstimmen. Ohne diese Übereinstimmung gilt die Authentifizierung trotz technisch korrekter SPF- oder DKIM-Einträge als gescheitert.
Die Konfiguration erfolgt als TXT-Record im DNS. Hierbei definieren Administratoren über die Policy (p), wie mit nicht autorisierten Mails umgegangen werden soll. Die Implementierung folgt dabei einer bewährten Eskalationsstrategie, um Fehlkonfigurationen zu vermeiden DMARC schrittweise konfigurieren:
p=none: Nur Überwachungsmodus. Die E-Mails werden ungehindert zugestellt, aber detaillierte Berichte werden generiert.p=quarantine: Verdächtige Nachrichten landen im Spam-Ordner des Empfängers.p=reject: Die strengste Stufe. Mails, die die Prüfung nicht bestehen, werden komplett blockiert.
Vor der Umstellung auf eine strikte Blockierung empfiehlt sich ein Monitoring-Zeitraum von zwei bis vier Wochen. Mithilfe der Reporting-Parameter (rua für aggregierte Berichte und ruf für forensische Berichte) lassen sich legitime Absender identifizieren und die Infrastruktur präzise abstimmen DMARC-Reporting nutzen. Dies verhindert, dass wichtige Geschäftskommunikation fälschlicherweise im Spam landet oder blockiert wird.
Nach Erreichen von p=reject ermöglicht BIMI (Brand Indicators for Message Identification) die Anzeige des Markenlogos im Posteingang. Voraussetzung: DMARC p=quarantine oder p=reject plus ein verifiziertes VMC-Zertifikat (Verified Mark Certificate). Google, Yahoo, Apple und Microsoft werten BIMI bereits aus und stärken so das Markenvertrauen.
Implementierungsreihenfolge – Schritt-für-Schritt
Die korrekte Abfolge ist technisch bindend: DMARC baut auf funktionierendem SPF und DKIM auf. Wer die Reihenfolge ignoriert, erhält irrelevante Reports oder blockiert legitime Mails.
- SPF einrichten: Legen Sie einen TXT-Record für Ihre Domain an, der alle autorisierten Versand-IPs auflistet. Testen Sie den Record sofort mit MXToolbox, um Syntaxfehler und das Lookup-Limit von zehn Abfragen zu prüfen. Überschreitungen brechen die Validierung ab.
- DKIM konfigurieren: Erzeugen Sie ein Schlüsselpaar (RSA 2048 Bit Minimum). Veröffentlichen Sie den öffentlichen Schlüssel als TXT-Record unter dem Selector (z. B.
default._domainkey). Aktivieren Sie die Signierung auf dem Mailserver oder im Gateway – ausgehende Mails tragen nun die kryptografische Signatur im Header. - DMARC implementieren: Starten Sie mit
p=noneund einer Reporting-Adresse (rua=mailto:dmarc@ihre-domain.de). Diese Phase dauert laut Sascha Fix zwei bis vier Wochen und dient reiner Datensammlung ohne Zustellungseinfluss. - Berichte analysieren: Werten Sie die täglichen XML-Reports aus. Tools wie dmarc-checker.de parsen die Daten und zeigen Fehlkonfigurationen – etwa Alignment-Probleme zwischen
From-Header, SPF-Return-Path und DKIM-d=-Domain. - Policy schärfen: Wechseln Sie stufenweise zu
p=quarantine(Spam-Ordner) und finalp=reject(Block). Nutzen Siepct=für graduellen Rollout: 25 → 50 → 100 Prozent. So minimieren Sie Risiken bei legitimen Absendern, die nachträglich gepflegt werden müssen.
Eine detaillierte Checkliste für jeden Schritt bietet Simon Erklärt – inklusive Fallback-Strategien für Forwarding-Szenarien.
Alignment – Schlüssel zum Erfolg
Alignment bedeutet, dass die Domain im From-Header mit der Domain im SPF-Return-Path oder der DKIM-d=‑Domain übereinstimmt. Ohne diese Übereinstimmung schlägt DMARC fehl, selbst wenn SPF und DKIM technisch korrekt sind. Der Grund dafür ist, dass DMARC die Authentizität anhand der sichtbaren Absenderadresse prüft. Um Alignment zu erreichen, setzen Sie die From-Domain auf dieselbe Domain wie die SPF‑ und DKIM-Einträge. Alternativ können Sie Sub-Domains konsistent konfigurieren, sodass jede Sub-Domain sowohl im SPF-Record als auch im DKIM-Record vorkommt. Ein häufiger Stolperstein ist die Verwendung unterschiedlicher Domains für den Return-Path und die sichtbare Absenderadresse. Der Praxisleitfaden zur Einrichtung von SPF, DKIM und DMARC bietet detaillierte Beispiele und erklärt, wie man Sub-Domains richtig bindet.
DMARC unterstützt zwei Alignment-Modi: strict verlangt exakt gleiche Domains, relaxed erlaubt Sub-Domains. Die Wahl hängt von Ihrer Infrastruktur ab. Für die meisten Unternehmen reicht relaxed, da Sub-Domains häufig für Marketing-oder Support-Mail verwendet werden. Achten Sie darauf, dass die DKIM-Signatur immer die gleiche Domain wie die From-Domain trägt. Wenn Sie mehrere Sub-Domains nutzen, delegieren Sie SPF-Records an diese Sub-Domains, um das Lookup-Limit nicht zu überschreiten. Der Praxisleitfaden zeigt, wie man SPF-Flattening vermeidet und Sub-Domains sauber bindet. Weitere Setup-Tipps finden Sie in den Setup-Tipps, die Schritt-für-Schritt-Anleitungen für die Alignment-Konfiguration liefern.
Beispiel: Ihr Newsletter versendet über news.example.com (Return-Path), aber der From-Header zeigt marketing.example.com. Ohne delegierten SPF-Record für news.example.com oder DKIM-Signatur mit d=marketing.example.com scheitert Alignment. Lösung: DKIM-Signatur auf marketing.example.com ausstellen oder SPF per include:news.example.com im Haupt-Record autorisieren.
Reporting – Analyse der Authentifizierungsberichte
Nach der Einrichtung der Schutzmechanismen folgt die Phase der Überwachung. DMARC bietet hierfür ein integriertes Feedback-System durch sogenannte Reports. Über die in der DMARC-Record hinterlegten Adressen (via rua für Aggregationsberichte und ruf für forensische Berichte) erhalten Administratoren regelmäßige Rückmeldungen von den empfangenden Mailservern.
Diese Berichte liegen im XML-Format vor und liefern essenzielle Daten zur Zustellbarkeit Ihrer Nachrichten. Sie geben Aufschluss über:
- Erfolgreiche und fehlgeschlagene Authentifizierungsversuche,
- die IP-Adressen der sendenden Server,
- die jeweils angewendeten Mechanismen (SPF oder DKIM),
- die durch die DMARC-Policy ausgelösten Maßnahmen.
Da die Rohdaten im XML-Format für Menschen schwer lesbar sind, ist ein automatisierter Auswertungsprozess notwendig. Durch das Parsen der Dateien mit spezialisierten Tools wie PowerDMARC oder EasyDMARC lassen sich komplexe Muster identifizieren. Dies ist entscheidend, um beispielsweise legitime Drittanbieter-Dienste zu entdecken, die noch keine korrekten Signaturen nutzen, oder um gezieltes E-Mail-Spoofing zu erkennen. Eine kontinuierliche Auswertung hilft Ihnen dabei, die DMARC-Policy sicher von der Monitoring-Phase (p=none) hin zur strikten Ablehnung (p=reject) zu verschärfen, ohne den regulären Mailverkehr zu gefährden.
Aggregierte Reports (rua) treffen täglich ein und enthalten statistische Übersichten pro sendender IP. Forensische Reports (ruf) liefern Header-Details einzelner fehlgeschlagener Mails – nützlich für Incident Response. Viele Provider drosseln ruf-Versand aus Datenschutzgründen; verlassen Sie sich primär auf rua.
Best Practices – Optimale Konfiguration
Eine schlanke SPF-Policy schützt vor dem Lookup-Limit von zehn DNS-Abfragen. Entfernen Sie nicht mehr genutzte include:-Einträge und prüfen Sie regelmäßig, ob alle aufgelisteten Hosts noch versenden. Detaillierte Tipps zum SPF-Aufräumen zeigen, wie Flattening oder Subdomain-Delegation Engpässe vermeiden.
DKIM-Schlüssel müssen rotieren. Statische Keys werden zum Risiko, wenn sie kompromittiert werden. Planen Sie einen Wechsel alle sechs bis zwölf Monate ein und vergeben Sie pro aussendendem System einen eigenen Selector. So lässt sich ein einzelner Schlüssel widerrufen, ohne den gesamten Mailverkehr zu unterbrechen.
DMARC starten Sie mit p=none. Dieser Modus liefert Berichte, ohne Zustellung zu beeinflussen. Beobachten Sie zwei bis vier Wochen lang, welche legitimen Quellen durchs Raster fallen, bevor Sie auf quarantine und später reject schärfen. Ein praxisnaher Leitfaden beschreibt den stufenweisen Rollout mit pct=-Werten.
Werten Sie die täglichen RUA-Berichte aus. Tools parsen das XML und zeigen Fehlkonfigurationen schnell an. So erkennen Sie vergessene Mailserver oder fehlerhafte Alignment-Einträge, bevor sie Reputation schädigen. Weiterführende Erklärungen ordnen die Report-Typen ein.
Setzen Sie ARC ein, wenn Mailinglisten oder Auto-Forwarding im Spiel sind. Die Authenticated Received Chain signiert jeden Hop kryptografisch und bewahrt die Authentizität über Weiterleitungen hinweg. Große Provider wie Google und Microsoft werten ARC bereits aus und honorieren intakte Ketten bei der Zustellentscheidung. Ohne ARC bricht Forwarding oft das Alignment – die Mail landet im Spam, obwohl SPF und DKIM korrekt waren.
Comments are closed, but trackbacks and pingbacks are open.