E-Mail-Sicherheit: SPF, DKIM, DMARC, BIMI und MTA-STS im Detail

E-Mail ist das primäre Einfallstor für Cyberangriffe - 94% aller Malware wird per E-Mail verbreitet (Verizon DBIR 2024). Das Problem wurzelt im Protokoll selbst: SMTP aus dem Jahr 1982 hat kein eingebautes Authentifizierungskonzept. SPF, DKIM, DMARC, BIMI und MTA-STS sind die Erweiterungen, die diese strukturelle Lücke schließen.

Das E-Mail-Spoofing-Problem

SMTP (Simple Mail Transfer Protocol) hat keinen Mechanismus, der prüft ob der angegebene Absender tatsächlich der echte Absender ist:

telnet mail.example.com 25
EHLO attacker.com
MAIL FROM: ceo@ihrfirma.de   ← Beliebig setzbar, kein Check!
RCPT TO: buchhaltung@ihrfirma.de
DATA
From: CEO <ceo@ihrfirma.de>
Subject: Dringend: Überweisung
...
.

Ohne Schutzmaßnahmen landet diese Mail im Posteingang. Die Lösung ist ein dreistufiges Authentifizierungsmodell:

SPF:    Welche IP-Adressen dürfen E-Mails für meine Domain senden?
        → DNS-Record mit autorisierten Absender-IPs und -Hosts

DKIM:   Hat der echte Domain-Inhaber diese E-Mail kryptografisch signiert?
        → Privater Schlüssel beim sendenden Server
        → Öffentlicher Schlüssel im DNS der Absender-Domain

DMARC:  Was soll passieren wenn SPF/DKIM fehlschlägt?
        → Policy: none (nur Monitoring) / quarantine / reject
        → Verbindet SPF+DKIM via "Alignment"
        → Reporting: wer sendet im Namen der Domain?

SPF (Sender Policy Framework)

SPF legt fest, welche Server E-Mails von einer Domain senden dürfen.

SPF-Record-Aufbau

ihrfirma.de.  IN  TXT  "v=spf1 ip4:185.220.101.0/24 include:spf.protection.outlook.com include:_spf.google.com -all"

Mechanismen:

ip4:203.0.113.0/24   → IPv4-Adressbereich autorisiert
ip6:2001:db8::/32    → IPv6-Adressbereich autorisiert
a                    → A-Record der eigenen Domain autorisiert
mx                   → MX-Records der Domain autorisiert
include:spf.google.com  → Google Workspace-Server einschließen
include:servers.mcsv.net → Mailchimp einschließen
redirect=_spf.example.com → Komplette Weiterleitung

Qualifikatoren:

+ (pass)     → IP erlaubt (Standard wenn kein Qualifier)
- (fail)     → IP explizit verboten (Hard Fail) → empfohlen für -all
~ (softfail) → IP verdächtig (Soft Fail) → Rollout-Stadium
? (neutral)  → Keine Aussage → NIEMALS als Endwert verwenden

Vollständige Beispiele:

# Google Workspace:
v=spf1 include:_spf.google.com -all

# Microsoft 365:
v=spf1 include:spf.protection.outlook.com -all

# Eigene IPs + Google + Newsletter:
v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:mailchimp.com -all

Was SPF schützt und nicht schützt

SPF schützt:      Envelope-From (Return-Path, technische Absenderadresse)
SPF schützt NICHT: Header-From (sichtbarer Absender im E-Mail-Client)

Angreifer-Trick:
  Envelope-From: phisher@legitdomain.com  ← SPF-Pass
  Header-From:   ceo@ihrfirma.de           ← Sichtbar für User
→ SPF allein reicht nicht - DMARC löst das via Alignment

E-Mail-Forwarding bricht SPF: Der weitergeleitete Server steht nicht im SPF-Record der Original-Domain. Lösung: SRS (Sender Rewriting Scheme) oder DKIM-Only-Policy in DMARC.

SPF-Limits und häufige Fehler

Lookup-Limit: max. 10 DNS-Lookups!
  → include: zählt als Lookup + alle darin enthaltenen
  → Zu viele includes → "too many DNS lookups" → SPF PermError
  → Lösung: SPF-Flattening-Tools (IPs direkt eintragen)
    Werkzeuge: spflatten.com, dmarcly.com

Häufige Fehler:
  FALSCH: v=spf1 +all   ← Alle IPs erlaubt! Keinerlei Schutz!
  FALSCH: ~all dauerhaft → Soft Fail = nur Warnung, kein Block
  RICHTIG: -all als Endwert

DKIM (DomainKeys Identified Mail)

DKIM signiert ausgehende E-Mails kryptografisch mit einem privaten Schlüssel. Empfänger verifizieren die Signatur über den öffentlichen Schlüssel im DNS.

DKIM-Funktionsweise

1. Sendender Server: signiert E-Mail-Header + Body mit privatem RSA-Key
2. Signatur: als DKIM-Signature-Header in die E-Mail eingefügt
3. Empfangender Server: liest Selektor aus Signatur, lädt öffentlichen Key aus DNS
4. Prüft: Signatur gültig? Body unverändert?

DKIM-Header-Beispiel:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=ihrfirma.de; s=mail2026;
  h=from:to:subject:date:message-id;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=abc123...signaturebytes...xyz456

DKIM-Record einrichten

# DNS-Record:
# Name: {selector}._domainkey.{domain}
mail2026._domainkey.ihrfirma.de  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G..."

# Microsoft 365 (CNAME-Variante):
selector1._domainkey.ihrfirma.de  CNAME  selector1-ihrfirma-de._domainkey.ihrfirma.onmicrosoft.com
selector2._domainkey.ihrfirma.de  CNAME  selector2-ihrfirma-de._domainkey.ihrfirma.onmicrosoft.com

Schlüssel generieren (Postfix-Beispiel):

# RSA 2048-Bit (Minimum), 4096-Bit empfohlen:
openssl genrsa -out dkim-private.pem 2048
openssl rsa -in dkim-private.pem -pubout -out dkim-public.pem

# Public Key für DNS (Kopf/Fuß entfernen, Newlines entfernen):
cat dkim-public.pem | grep -v "^-" | tr -d '\n'

DKIM-Schlüsselrotation

Rotation ohne Downtime:
  1. Neuen Selektor "selector2" in DNS publizieren
  2. MTA auf selector2 umschalten
  3. selector1 aus DNS entfernen (nach 48h TTL)
  → Vorteil: DKIM-Key kompromittiert → nur Rotation nötig!

Alte Selektoren NICHT sofort löschen (In-Transit-E-Mails!)

DKIM-Alignment (wichtig für DMARC)

Relaxed Alignment (adkim=r, Standard):
  → DKIM-Signatur: d=ihrfirma.de
  → From-Header:   user@ihrfirma.de
  → Subdomains erlaubt: mail.ihrfirma.de stimmt mit ihrfirma.de überein

Strict Alignment (adkim=s):
  → Exakte Übereinstimmung erforderlich
  → mail.ihrfirma.de stimmt NICHT mit ihrfirma.de überein

Mailing-Listen-Problem: Mailing-Listen modifizieren Subject/Body, was die DKIM-Signatur ungültig macht. Lösung: DMARC mit adkim=r (relaxed) oder Mailing-Listen resignieren mit eigenem DKIM.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC verbindet SPF und DKIM und gibt Empfangsservern Anweisungen, was mit nicht-konformen E-Mails passieren soll.

DMARC-Record

_dmarc.ihrfirma.de.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@ihrfirma.de; ruf=mailto:dmarc-forensics@ihrfirma.de; fo=1; adkim=r; aspf=r; pct=100; sp=reject"

Parameter:

v=DMARC1          → Pflicht, Version
p=none            → Policy: none/quarantine/reject
rua=mailto:...    → Aggregate Reports (täglich, XML)
ruf=mailto:...    → Forensic Reports (pro E-Mail; Privacy-Implikationen beachten!)
fo=0|1|d|s        → Forensic Options (wann Forensic-Report senden?)
adkim=r|s         → DKIM-Alignment: r=relaxed, s=strict
aspf=r|s          → SPF-Alignment: r=relaxed, s=strict
pct=0-100         → Prozentsatz der Enforcement (für schrittweisen Rollout)
sp=none|quarantine|reject → Policy für Subdomains
ri=86400          → Report-Intervall in Sekunden (Standard: 1 Tag)

DMARC-Alignment-Logik

E-Mail PASS DMARC wenn MINDESTENS EINES davon gilt:
  1. SPF Pass + SPF Aligned (Return-Path-Domain = From-Domain)
  2. DKIM Pass + DKIM Aligned (d= Domain = From-Domain)

Beide können unabhängig scheitern:
  → SPF fail (z.B. durch Forwarding) + DKIM pass + DKIM aligned → DMARC PASS
  → SPF pass + DKIM fail → DMARC PASS (wenn SPF aligned)

DMARC-Rollout-Strategie

Eine sofortige Aktivierung von p=reject blockiert oft legitime E-Mails. Der stufenweise Rollout ist zwingend:

Schritt 1: Monitoring (p=none) - 2-4 Wochen
  → Nur Reports, keine Aktion
  → Welche Systeme senden E-Mails als Ihre Domain?
  → rua-Reports analysieren: bekannte Sender? Unbekannte? Drittanbieter?

Schritt 2: Quarantine mit niedrigem pct - 2-4 Wochen
  → p=quarantine; pct=10
  → 10% der fehlschlagenden E-Mails → Spam-Ordner
  → Monitor: legitime E-Mails im Spam?
  → pct schrittweise erhöhen: 10 → 25 → 50 → 100

Schritt 3: Quarantine mit 100% - 1-2 Wochen
  → p=quarantine; pct=100
  → Letzter Check: alle legitimen Sender konfiguriert?

Schritt 4: Reject (Ziel!)
  → p=reject; pct=100
  → Fehlschlagende E-Mails werden abgelehnt (SMTP-Fehler)
  → Vollständiger Schutz vor E-Mail-Spoofing
  → DMARC-Reports weiterhin beobachten

DMARC-Reports auswerten

Aggregate Reports (rua) - XML-Format:

<!-- Beispiel DMARC Aggregate Report -->
<feedback>
  <record>
    <row>
      <source_ip>40.107.22.15</source_ip>  <!-- Microsoft IP -->
      <count>1250</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <row>
      <source_ip>185.220.101.55</source_ip>  <!-- Unbekannte IP! -->
      <count>12</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
  </record>
</feedback>
<!-- Interpretation:
  1. Eintrag: legitime M365-Mails (alles PASS) → OK
  2. Eintrag: unbekannte IP, SPF+DKIM fail → Spoofing-Versuch!
     Maßnahme: IP prüfen, ggf. p=reject aktivieren
-->

Tools für Report-Auswertung und -Visualisierung:

dmarcian.com      → DMARC-Report-Visualisierung
dmarcanalyzer.com → DSGVO-konform, europäischer Anbieter
postmark          → DMARC-Wizard
easydmarc.com     → Guided DMARC-Rollout
parsedmarc        → Python CLI, SIEM-Integration
  pip install parsedmarc
  parsedmarc -c /etc/parsedmarc.ini --imap-host imap.example.com

BIMI (Brand Indicators for Message Identification)

BIMI zeigt das Unternehmenslogo neben E-Mails in unterstützten Mail-Clients.

BIMI-DNS-Record

default._bimi.ihrfirma.de  IN  TXT  "v=BIMI1; l=https://ihrfirma.de/logo.svg; a=https://ihrfirma.de/VMC.pem"

Voraussetzungen:

1. DMARC p=quarantine oder p=reject (pct=100)
2. SVG-Logo im Format "SVG Tiny PS"
   → Quadratisches Seitenverhältnis (1:1)
   → Max. 32 KB
   → Kein eingebettetes JavaScript, keine externen Ressourcen
   → Gehostet auf HTTPS, öffentlich erreichbar
   → Validierung: bimigroup.org/bimi-svg-validator/
3. VMC (Verified Mark Certificate) - für Gmail Pflicht!
   → Ausgestellt von: Entrust oder DigiCert
   → Erfordert eingetragene Marke (Trademark-Registrierung)
   → Kosten: ca. 1.000-1.500 EUR/Jahr

Client-Unterstützung:

Gmail:           Ja (VMC erforderlich für blauen Haken)
Apple Mail:      Ja (seit iOS 16 / macOS Ventura)
Yahoo Mail:      Ja (VMC empfohlen, aber nicht Pflicht)
Outlook.com:     In Vorbereitung (2026)
Microsoft 365:   Noch nicht

Nutzen: E-Mails mit verifiziertem Firmenlogo werden als deutlich vertrauenswürdiger wahrgenommen und häufiger geöffnet. Gleichzeitig ist gefälschten E-Mails das Logo nicht vorhanden - für Empfänger ein sichtbares Warnsignal.

MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS verhindert TLS-Downgrade-Angriffe beim E-Mail-Transport (Relay-zu-Relay). Ohne MTA-STS ist STARTTLS opportunistisch und kann durch MITM-Angriffe deaktiviert werden.

MTA-STS-Implementierung

Schritt 1: Policy-Datei unter HTTPS bereitstellen

URL: https://mta-sts.ihrfirma.de/.well-known/mta-sts.txt

version: STSv1
mode: enforce
mx: mail.ihrfirma.de
mx: mx2.ihrfirma.de
max_age: 604800

Modi:

testing:  Policy verletzt → E-Mail trotzdem senden, aber Report
enforce:  Policy verletzt → E-Mail NICHT senden (Ziel!)
none:     Policy aufgehoben

Schritt 2: DNS-Record setzen

_mta-sts.ihrfirma.de  IN  TXT  "v=STSv1; id=20260308001"

Das id=-Feld muss sich ändern, wenn sich die Policy-Datei ändert (Cache-Invalidierung).

TLSRPT (TLS Reporting)

TLSRPT liefert Reports über fehlgeschlagene TLS-Verbindungen beim E-Mail-Transport:

_smtp._tls.ihrfirma.de  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@ihrfirma.de"

Reports enthalten TLS-Verbindungsfehler, Zertifikatsfehler, Downgrade-Versuche und MTA-STS-Richtlinienverstöße.

DANE (DNS-based Authentication of Named Entities)

DANE ist eine alternative Transportabsicherung, die ein TLS-Zertifikat direkt in DNSSEC-gesicherten DNS-Records hinterlegt.

_25._tcp.mail.ihrfirma.de.  IN  TLSA  3 1 1 [SHA-256-HASH-DES-ZERTIFIKATS]

TLSA-Felder: 3 1 1 = Domain-Issued Certificate (DANE-EE), SubjectPublicKeyInfo, SHA-256 Hash.

Voraussetzung: DNSSEC muss für die Domain aktiv sein. Ohne DNSSEC bietet DANE keinen Mehrwert, da der TLSA-Record selbst angreifbar wäre.

# TLSA-Record-Hash generieren:
openssl x509 -in mail.crt -pubkey -noout | \
  openssl pkey -pubin -outform DER | \
  openssl dgst -sha256 -binary | \
  xxd -p | tr -d '\n'

Häufige Fehlkonfigurationen

1. SPF zu weit gefasst:
   FALSCH: v=spf1 +all   ← Alle IPs erlaubt, keinerlei Schutz!
   FALSCH: v=spf1 ?all   ← Neutral, keine Sicherheitsaussage
   RICHTIG: v=spf1 ... -all

2. SPF mit ~all als Dauerlösung:
   → Soft Fail = nur Warnung, E-Mail wird oft trotzdem zugestellt
   → OK als temporäres Rollout-Stadium, aber nicht als Endzustand

3. DKIM-Key zu klein:
   → 1024-Bit: nicht mehr sicher (Faktorisierung möglich)
   → Minimum: 2048 Bit; Empfehlung: 4096 Bit oder Ed25519

4. DMARC p=none dauerhaft:
   → Sammelt Daten, bietet aber KEINEN Schutz
   → Angreifer können trotzdem spoopen!
   → Ziel: p=reject

5. DMARC rua-Adresse nicht überwacht:
   → Reports kommen täglich → werden ignoriert
   → Unbekannte Drittsender und Konfigurationsprobleme bleiben unerkannt

6. Fehlende Subdomain-Policy:
   → DMARC für ihrfirma.de schützt NICHT test.ihrfirma.de automatisch
   → sp=reject ergänzen für vollständigen Subdomain-Schutz

7. BIMI ohne VMC bei Gmail:
   → Logo erscheint nicht (Gmail verlangt VMC)
   → Yahoo Mail unterstützt BIMI auch ohne VMC

8. MTA-STS ohne DNSSEC:
   → MTA-STS-DNS-Record selbst ist ohne DNSSEC angreifbar
   → DNSSEC wird dringend empfohlen

Implementierungs-Roadmap

Woche 1-2: Bestandsaufnahme
  □ Welche Systeme senden E-Mails als Ihre Domain?
    - Eigene Mailserver
    - Transactional E-Mail (Sendgrid, Mailgun, AWS SES)
    - Marketing-E-Mail (Mailchimp, HubSpot, Brevo)
    - CRM-Systeme, ERP, HR-Software
    - Kundenportal-Notifications
  □ SPF-Record mit allen legitimen Sendern aufbauen
  □ DKIM für alle Absender-Systeme konfigurieren und testen

Woche 3-4: Aktivierung mit none-Policy
  □ DMARC p=none mit rua= für Reports aktivieren
  □ Reports sammeln und auswerten (dmarcian, Postmark DMARC)
  □ Unbekannte Sender identifizieren und nachkonfigurieren

Woche 5-8: Quarantine-Rollout
  □ p=quarantine; pct=10 → schrittweise auf 100 erhöhen
  □ Monitoring: legitime E-Mails im Spam der Empfänger?
  □ Alle Drittanbieter-Sender: SPF include + DKIM konfiguriert?
  □ Subdomains prüfen: sp= Policy setzen

Woche 9-12: Reject und Härtung
  □ p=reject; pct=100 → vollständiger Schutz
  □ MTA-STS: testing → enforce
  □ TLSRPT aktivieren
  □ BIMI vorbereiten (VMC bestellen, SVG-Logo validieren)

Laufend:
  □ DMARC-Reports wöchentlich auswerten
  □ Neue E-Mail-Dienste sofort in SPF und DKIM konfigurieren
  □ DKIM-Schlüsselrotation: alle 6-12 Monate
  □ SPF aktuell halten bei Migrationen und neuen Diensten

DNS-Konfiguration: Gesamtübersicht

# SPF:
ihrfirma.de              TXT  "v=spf1 ip4:185.220.101.0/24 include:spf.protection.outlook.com -all"

# DKIM:
mail2026._domainkey.ihrfirma.de  TXT  "v=DKIM1; k=rsa; p=MIGfMA0..."

# DMARC:
_dmarc.ihrfirma.de       TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@ihrfirma.de; pct=100; sp=reject"

# MTA-STS:
_mta-sts.ihrfirma.de     TXT  "v=STSv1; id=20260308001"

# TLSRPT:
_smtp._tls.ihrfirma.de   TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@ihrfirma.de"

# BIMI:
default._bimi.ihrfirma.de  TXT  "v=BIMI1; l=https://ihrfirma.de/logo.svg; a=https://ihrfirma.de/VMC.pem"

# MTA-STS Policy-Datei (HTTPS):
# https://mta-sts.ihrfirma.de/.well-known/mta-sts.txt

Tools zum Testen und Debuggen

# SPF testen:
dig TXT ihrfirma.de | grep spf
nslookup -type=TXT ihrfirma.de

# DKIM testen:
dig TXT mail2026._domainkey.ihrfirma.de

# DMARC testen:
dig TXT _dmarc.ihrfirma.de

# BIMI testen:
dig TXT default._bimi.ihrfirma.de

# MTA-STS testen:
dig TXT _mta-sts.ihrfirma.de

Online-Tools:

mxtoolbox.com/SuperTool.aspx  → SPF, DKIM, DMARC prüfen
mail-tester.com               → Gesamter E-Mail-Score (Test-Mail senden)
dmarcian.com/dmarc-inspector/ → DMARC-Record analysieren
internet.nl                   → BSI-empfohlener Checker
postmaster.google.com         → Google Postmaster Tools
toolbox.googleapps.com/apps/checkmx/ → Google Admin Toolbox

E-Mail-Security-Checkliste

SPF:
  □ SPF-Record vorhanden
  □ Endet mit -all (Hard Fail)
  □ Alle E-Mail-Dienste eingetragen (Mailchimp, HubSpot, etc.)
  □ Unter 10 DNS-Lookups

DKIM:
  □ DKIM für alle Absender-Systeme konfiguriert
  □ Schlüssellänge mind. 2048 Bit
  □ Schlüsselrotation geplant (6-12 Monate)

DMARC:
  □ DMARC auf p=reject (nach Monitoring-Phase)
  □ rua= für Aggregate Reports gesetzt
  □ sp= für Subdomains gesetzt
  □ Reports werden regelmäßig ausgewertet

Transport-Sicherheit:
  □ MTA-STS auf mode=enforce
  □ TLSRPT aktiviert

Optional (empfohlen):
  □ BIMI konfiguriert (SVG-Logo, VMC)
  □ DNSSEC für die Domain aktiv
  □ DANE (TLSA-Record) für eigene Mailserver

---

E-Mail-Authentifizierung ist keine optionale Härtungsmaßnahme. Google und Yahoo verlangen seit 2024 DMARC für Bulk-Sender, Microsoft 365 erhöht schrittweise die Anforderungen. Unternehmen ohne DMARC riskieren nicht nur Spoofing-Angriffe gegen Kunden und Partner, sondern auch schlechtere Zustellbarkeit legitimer E-Mails.