SPF, DKIM & DMARC: E-Mail-Authentifizierung verständlich erklärt
SPF, DKIM und DMARC schützen deine Domains vor E‑Mail‑Fälschung. Diese ausführliche Anleitung erklärt Mechaniken, Setup, Beispiele, Tests und Best Practices.

E‑Mail‑Sicherheit beginnt mit zuverlässiger Authentifikation: SPF, DKIM und DMARC bilden heute die Standard-Basis, um Spoofing und Phishing zu reduzieren. Diese drei Technologien ergänzen sich: SPF prüft, ob ein sendender Server berechtigt ist, E‑Mails für eine Domain zu verschicken; DKIM signiert Nachrichten kryptographisch; DMARC verbindet die Prüfergebnisse und erlaubt Richtlinien, wie E‑Mails gehandhabt werden sollen.
Warum diese drei zusammen wichtig sind
Keines der drei Systeme alleine löst alle Probleme: SPF scheitert bei Weiterleitungen, DKIM kann durch veränderte Header brechen, und DMARC braucht die Resultate beider, um Richtlinien durchzusetzen. Setzt man alle drei korrekt ein, erreicht man sehr gute Schutzwirkung gegen gefälschte Absendeadressen und kann gleichzeitig aussagekräftiges Monitoring betreiben.
- SPF definiert erlaubte Sender (IP-basiert).
- DKIM signiert Nachrichten kryptographisch (selector basiert).
- DMARC verbindet Ergebnisse und erlaubt Richtlinien + Reporting.
SPF (Sender Policy Framework)
Kurz erklärt
SPF ist ein DNS-Textrecord (TXT), der festlegt, welche IP‑Adressen oder Hostnamen E‑Mails im Namen einer Domain versenden dürfen. Ein empfangender Mail-Server prüft die IP des sendenden Servers gegen die SPF-Policy.
Syntax und Beispiele
Ein einfacher SPF-Record:
v=spf1 ip4:203.0.113.10 include:mail.provider.example -all
v=spf1
: Versionip4:203.0.113.10
: explizit erlaubte IPv4-Adresseinclude:mail.provider.example
: erlaubte Sender gemäß dem SPF-Record des Providers-all
: harte Ablehnung für nicht erlaubte Sender (fail)
Tipps & Fallstricke
- Achte auf die 10-Lookup-Grenze: Mechanismen wie
include
,mx
,a
erzeugen DNS-Lookups. Überschreitet die Policy 10 Lookups, wird SPF ungültig. - Vermeide zu viele
include
-Ketten—nutze Provider-spezifische Zusammenfassungen. - SPF hilft nicht bei Weiterleitungen: Wenn ein Mail-Forwarder die Mail weiterleitet, sieht der finale Empfänger die IP des Forwarders, nicht des Originalsenders.
SPF testen
Prüfe einen SPF-Record mit dig:
dig TXT example.com +short
# oder nutze ein Online-Tool, das SPF-Lookups und Includes auswertet
DKIM (DomainKeys Identified Mail)
Kurz erklärt
DKIM signiert E‑Mails mit einem privaten Schlüssel; der öffentliche Schlüssel liegt als DNS TXT-Record unter
einem Subdomain-Selector, z. B. selector._domainkey.example.com
. Der Empfänger validiert die Signatur
durch Abfragen dieses DNS-Eintrags.
Wesentliche Konzepte
- Selector: Identifiziert den verwendeten Schlüssel (z. B.
mail2025
). - Canonicalization: Gibt an, wie Header und Body vor dem Signieren normalisiert werden (simple/relaxed).
- Header-Fields: Definiert, welche Header in die Signatur einfließen (z. B. From, Subject).
Beispiel: DKIM-Schlüssel erzeugen
# mit OpenDKIM/openssl
opendkim-genkey -t -s mail2025 -d example.com
# erzeugt mail2025.private und mail2025.txt (Public key Record)
Der Inhalt von mail2025.txt
enthält dann den TXT-Record, den du in DNS einträgst.
Häufige Probleme
- Signaturen brechen bei Weiterleitungen oder wenn Header von Relays verändert werden;
wähle passende Canonicalization (relaxed hilft oft). - Zu kurze Schlüssel oder veraltete Algorithmen—verwende mindestens 2048-bit RSA oder ECDSA.
DMARC (Domain-based Message Authentication, Reporting & Conformance)
Kurz erklärt
DMARC verknüpft SPF und DKIM-Resultate mit der sichtbaren From‑Adresse (d. h. Alignment). Per DMARC-Policy legt der Domain-Inhaber fest, wie empfangende Server mit fehlgeschlagenen Prüfungen umgehen sollen (none/quarantine/reject) und wo Berichte (Aggregate/Forensic) gesendet werden.
DMARC-Record Beispiel
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com; pct=100; aspf=r; adkim=r;"
p
: Policy für den Domain-Level (none/quarantine/reject)pct
: Prozent der Nachrichten, auf die die Policy angewendet wirdrua
/ruf
: Aggregate- und Forensic-Report-Adressenadkim
/aspf
: Alignment-Mode (r=relaxed, s=strict)
Deployment-Strategie
Setze DMARC schrittweise ein: beginne mit p=none
und sammle Reports, analysiere false positives, stelle auf
pct
100 wenn stabil, und erhöhe Policy auf quarantine
bzw. reject
erst nachdem Tests
positiv verlaufen.
Praktische Beispiele und Testbefehle
Wichtige Prüfungen mit dig und speziellen Tools:
# SPF
dig TXT example.com +short
# DKIM (public key)
dig TXT mail2025._domainkey.example.com +short
# DMARC
dig TXT _dmarc.example.com +short
# Test einer tatsächlichen Nachricht mit OpenDKIM-Tools (lokal)
opendkim-testmsg -d example.com -s mail2025 -k mail2025.private < testmail.txt
# Online-Tools: MXToolbox, Kitterman SPF checker oder DMARCian bieten ausführliche Analysen
Forwarding, Mailing-Listen und complex flows
Weiterleitungen und Mailing-Listen sind die klassischen Problemquellen: SPF bricht, weil Sender-IP nicht mehr übereinstimmt. DKIM kann die Nachricht stabil halten, wenn Signaturen nicht durch die Verteilung verändert werden. DMARC erlaubt mit relaxed-alignment etwas Toleranz; für Listen empfehlen sich Einstellungen, die DKIM-Header vor Änderungen schützen (z. B. Authen-Results-Preserve), oder die Verwendung von ARC (Authenticated Received Chain) als Ergänzung.
SPF-Macros und Advanced SPF
SPF bietet Macros, mit denen dynamische Werte in Policies genutzt werden können (z. B. %{h}
für den HELO
Hostname oder %{s}
für die Sender). Diese Funktionalität wird selten benötigt, ist aber nützlich für
komplexe Setups. Beispiele:
# Beispiel mit Macro (vereinfachte Darstellung)
v=spf1 ip4:203.0.113.0/24 include:%{d}._spf.example.net -all
Macros erhöhen Komplexität und sollten mit Vorsicht eingesetzt werden — dokumentiere und teste gründlich.
DMARC-Aggregate-Report: Beispiel und Erklärung
DMARC-Aggregat-Reports (RUA) kommen als XML und listen gesammelte Policy-Ergebnisse über Zeiträume. Ein stark vereinfachtes Beispiel eines Aggregat-Reports (Auszug):
<feedback>
<report_metadata>
<org_name>example-isp</org_name>
<email>abuse@example-isp.net</email>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<p>quarantine</p>
<adkim>r</adkim>
<aspf>r</aspf>
</policy_published>
<record>
<row>
<source_ip>198.51.100.23</source_ip>
<count>42</count>
<policy_evaluated>
<disposition>quarantine</disposition>
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
</record>
</feedback>
Solche Reports erlauben es, verdächtige IPs, fehlerhafte DKIM-Konfigurationen oder fehlende SPF-Settings systematisch zu identifizieren.
Automatisierung: Key-Rotation und Reporting-Pipelines
Automatisiere wiederkehrende Aufgaben: DKIM-Key-Rotation, SPF-Policy-Validierung und DMARC-Report-Parsing. Eine typische
Pipeline umfasst: 1) Sammeln der RUA-Dateien (z. B. per S3 oder per Mail-to-Storage), 2) Parsen & Normalisieren, 3)
Erzeugen von Alerts für neue IPs oder steigende Fehlerraten. Beispiel-Tools: opendmarc
, mailparser
und spezialisierte SaaS-Dienste.
Konkretes Migrations-Playbook (Zeitplan)
Ein sicheres Vorgehen zum produktiven Rollout könnte so aussehen (8 Wochen Plan):
- Woche 1–2: Inventarisieren aller Absender (SMTP-Server, Marketing-Tools, Drittanbieter). Erstelle eine Tracking-Liste mit IPs, Hostnames und Verantwortlichen.
- Woche 3: Implementiere und überprüfe SPF-Records, konsolidiere Includes und minimiere DNS-Lookups.
- Woche 4: Setze DKIM für alle relevanten Flows (transaktional, marketing) mit dedizierten Selectors.
- Woche 5: Aktiviere DMARC mit
p=none
und sammle Reports (rua/ruf). - Woche 6–7: Analysiere Reports, behebe Fehlkonfigurationen, erweitere Ausnahmen für legitime Dienste.
- Woche 8: Reduziere
pct
falls nötig, wechsle zuquarantine
und später zureject
, sobald das Monitoring grünes Licht gibt.
Deliverability- und Business-Considerations
Strikte DMARC-Policies können legitime E‑Mails blockieren, wenn Drittanbieter nicht korrekt konfiguriert sind. Bevor du
p=reject
einsetzt, stelle sicher, dass Transaktionsmails (z. B. Passwort-Resets) zuverlässig zugestellt werden.
Kommunikation mit Marketing-Partnern und ein Failback-Plan (z. B. eine dedizierte Subdomain für Newsletter) sind wichtig.
ARC (Authenticated Received Chain) kurz
ARC ist ein Zusatzmechanismus, um Authentizität bei Weiterleitungen zu erhalten: Ein Relay kann die ursprünglichen Authentifizierungsresultate (SPF/DKIM) in speziellen ARC-Headern festhalten, sodass der finale Empfänger die ursprüngliche Authentizität nachvollziehen kann. ARC ist nützlich für Mailing-Listen und bestimmte Weiterleitungs-Topologien.
BIMI & Markenstärkung
BIMI (Brand Indicators for Message Identification) erlaubt das Anzeigen eines Markenlogos in unterstützten Mailclients, vorausgesetzt DMARC-Policy ist strikt (quarantine/reject) und die Organisation hostet ein verifiziertes Logo via VMC. BIMI erhöht Markenvertrauen im Posteingang, setzt aber eine saubere Authentifizierungs-Basis voraus.
Tooling-Übersicht
Empfohlene Tools und Dienste:
- dig/opendkim/opendmarc – lokale Prüfungen und Tests.
- DMARC-Report-Parser – automatisch RUA analysieren (z. B. dmarc-report).
- SaaS-Dienste wie DMARCian, Valimail oder MXToolbox für Monitoring & Visualisierung.
- Logging & Alerting – Exportiere DMARC-Metriken in dein Monitoring (Prometheus/Grafana).
Konkrete Troubleshooting-Beispiele
Beispiel 1: Newsletter wird gebounced nach DMARC-Policy-Änderung — Ursache: Marketing-Plattform nutzt eigene Send-Infrastruktur, aber wurde nicht in SPF inkludiert und signiert die Mails nicht per DKIM. Lösung: Entweder Provider konfigurieren, eigener Sending-Domain-Selector einrichten oder Newsletter über Subdomain mit eigener Authentifizierung senden.
Beispiel 2: Weiterleitungen brechen SPF — Lösung: Abhängigkeit auf DKIM stärken, ARC prüfen, relaxed-alignment nutzen oder Weiterleitungspfade ändern.
Zusammenfassung technischer Empfehlungen
- Inventar: Kenne alle Sender und Services deiner Domain.
- Automatisiere DKIM-Key-Rotationen und überwache Key-Gültigkeiten.
- Sammle und analysiere DMARC-RUA-Daten täglich, setze Alerts für Anomalien.
- Teste Rollouts in Stufen und kommuniziere mit Drittanbietern frühzeitig.
Reporting & Monitoring
DMARC liefert Aggregate-Reports (rua) im XML-Format — nutze Tools wie DMARCian, dmarc-report oder RSpamd, um Reports auszuwerten. Richte Alarmgrenzen für plötzliche Anstiege fehlgeschlagener Nachrichten ein und überprüfe regelmäßig, ob legitime Services (Marketing-Plattformen, CRM, Newsletter) korrekt konfiguriert sind.
Best Practices & Empfehlungen
- Beginne mit
p=none
DMARC und sammle mindestens 7–14 Tage Reports bevor du Policies verschärfst. - Verwende dedizierte Selectors für unterschiedliche Mail-Flows (z. B. marketing, transactional).
- Behalte die SPF-Lookup-Grenze im Blick und konsolidiere Includes.
- Nutze 2048-bit RSA oder ECDSA für DKIM-Schlüssel und rolle Keys regelmäßig automatisiert.
- Dokumentiere alle Drittanbieter, die E‑Mails im Namen deiner Domain senden, und teste deren Konfigurationen.
Beispiel-Records für eine Produktionsdomain
Kombinierte Beispielkonfiguration:
# SPF
example.com. TXT "v=spf1 ip4:203.0.113.10 include:spf.sendgrid.net -all"
# DKIM (selector mail2025)
mail2025._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
# DMARC (start with monitoring)
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com; pct=100; aspf=r; adkim=r;"
Troubleshooting-Workflow
- Sammle DMARC-Reports und filtere legitime Services heraus.
- Prüfe SPF-Record-Lookups und konsolidiere Includes.
- Validiere DKIM-Signaturen lokal und auf verschiedenen Empfängern.
- Teste Forwarding-Szenarien und fallbacks (ARC, relaxed alignment).
Erweiterte Themen & Zukunft
Technologien wie ARC, BIMI oder verstärkte Use-Cases für DANE bauen auf SPF/DKIM/DMARC auf. Während DMARC die Grundlage für Policy-Enforcement bildet, können BIMI-Logos (Brand Indicators for Message Identification) nur mit korrekter DMARC Policy (p=quarantine/reject) vollständig genutzt werden.
Fazit
SPF, DKIM und DMARC sind zusammen der effektivste Weg, um E‑Mail‑Spoofing zu reduzieren und die Vertrauenswürdigkeit deiner Domain zu erhöhen. Ein schrittweiser Rollout, automatisierte Tests und ein Monitoring-Setup sind entscheidend. Wenn du möchtest, erstelle ich dir ein individuelles Playbook inklusive konkreter Befehle, Monitoring-Regeln und einer Timeline zur schrittweisen Einführung für deine Domains.