E-Mail-Sicherheitsarchitektur: DMARC, SPF, DKIM, BIMI und MTA-STS im Verbund

E-Mail-Spoofing - jemand sendet E-Mails mit Ihrer Domain als Absenderadresse - ist der häufigste Einstiegspunkt für Phishing-Angriffe gegen Kunden und Mitarbeiter. Die Lösung existiert seit Jahren: SPF, DKIM und DMARC bilden zusammen eine mehrschichtige E-Mail-Authentifizierungs-Architektur. Richtig konfiguriert, verhindert sie dass Angreifer Ihre Domain missbrauchen können.

Das E-Mail-Spoofing-Problem

Warum E-Mail-Spoofing möglich ist:

SMTP (Simple Mail Transfer Protocol) aus 1982:
  → Kein eingebauter Authentifizierungsmechanismus
  → Jeder SMTP-Server kann beliebige From:-Header setzen
  → "From: ceo@yourcompany.com" → Angreifer kontrolliert!

  Technischer Ablauf:
  [Angreifer-Server] EHLO evil.server.com
                     MAIL FROM: <ceo@yourcompany.com>
                     RCPT TO: <employee@yourcompany.com>
                     DATA
                     From: CEO <ceo@yourcompany.com>
                     Subject: Dringend: Überweisung!
                     .

  Empfänger sieht: "Von: CEO <ceo@yourcompany.com>"
  → Ohne SPF/DKIM/DMARC: keine Möglichkeit zu erkennen ob legitim!

Lösung - Dreistufiges Authentifizierungsmodell:

  SPF:   Welche IP-Adressen dürfen E-Mails für meine Domain senden?
         → DNS-Record, enthält autorisierte Absender-IPs/Hosts
         → Empfänger prüft: kommt E-Mail von erlaubter IP?

  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
         → Empfänger verifiziert Signatur

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

SPF (Sender Policy Framework)

SPF-Implementierung:

DNS-Eintrag:
  Type: TXT
  Name: @ (oder yourdomain.com)
  Wert: "v=spf1 [mechanisms] -all"

Mechanisms (Autorisierungsregeln):
  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

Qualifiers (Was passiert bei Match):
  +all   → autorisiert (Standard wenn kein Qualifier)
  -all   → nicht autorisiert (FAIL!) → empfohlen für End-Eintrag
  ~all   → soft-fail (verdächtig, aber nicht blockieren)
  ?all   → neutral (keine Aussage) → SCHLECHT! Gibt keine Sicherheit

Typisches Beispiel:
  v=spf1 ip4:185.220.101.0/24 include:spf.protection.outlook.com
         include:_spf.google.com -all

  Bedeutung:
  → IP 185.220.101.x: autorisiert (eigener Mailserver)
  → Microsoft 365: autorisiert
  → Google Workspace: autorisiert
  → Alle anderen: FAIL!

SPF-Grenzen 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-Fehler
    → Lösung: SPF-Flattening-Tools (substituieren IP-Ranges)

  SPF schützt nur den Envelope-From (Return-Path)!
    → NICHT den Header-From (sichtbarer Absender)
    → DMARC löst das Problem via "Alignment"

  Forwarding bricht SPF!
    → E-Mail-Forwarding: neuer Absender-IP nicht in SPF
    → Lösung: SRS (Sender Rewriting Scheme) oder DKIM-Only-Policy

  -all vs. ~all:
    → ~all (Soft-Fail): E-Mails werden zugestellt, markiert
    → -all (Hard-Fail): E-Mails werden abgelehnt
    → Empfehlung: mit ~all beginnen, zu -all migrieren wenn stabil

DKIM (DomainKeys Identified Mail)

DKIM-Implementierung:

Funktionsprinzip:
  1. Sendender Server erstellt Signatur über E-Mail-Inhalt + Header
  2. Signatur wird als DKIM-Signature-Header angehängt
  3. Empfänger liest Selector aus Signatur → findet DNS-Record
  4. Öffentlicher Schlüssel aus DNS → Signatur verifizieren

DKIM-Header Beispiel:
  DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=yourdomain.com; s=mail2026;
    h=from:to:subject:date:message-id;
    bh=BASE64_BODY_HASH;
    b=BASE64_SIGNATURE

DNS-Record für DKIM:
  Type: TXT
  Name: mail2026._domainkey.yourdomain.com
  Wert: "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G..."

  Aufbau:
  {selector}._domainkey.{domain}
  → selector: "mail2026" (frei wählbar, z.B. "google", "mail", Datum)
  → Mehrere Selektoren möglich → Rotation ohne Downtime!

Schlüssel-Generierung (Postfix-Beispiel):
  # RSA 2048-Bit (Minimum), 4096-Bit empfohlen:
  openssl genrsa -out dkim_private.pem 2048
  openssl rsa -in dkim_private.pem -out dkim_public.pem -pubout

  # Öffentlichen Schlüssel für DNS extrahieren:
  openssl rsa -in dkim_private.pem -pubout -outform DER | base64 -w 0

DKIM Best Practices:
  □ RSA-Schlüssel: mind. 2048 Bit (4096 empfohlen, prüfe Header-Limits!)
  □ Ed25519 als Alternative: kürzer, schneller, modern
  □ Schlüsselrotation: alle 6-12 Monate
  □ Alte Selektoren NICHT sofort löschen (In-Transit-E-Mails!)
  □ Signing: alle ausgehenden E-Mails signieren (inkl. Transactional!)

DKIM-Alignment (wichtig für DMARC):
  → DKIM-Signatur: d=yourdomain.com
  → From-Header:   from@yourdomain.com
  → Alignment: beide müssen "yourdomain.com" enthalten → PASS!

  Relaxed Alignment (default): Subdomains erlaubt
    → sub.yourdomain.com stimmt mit yourdomain.com überein ✓

  Strict Alignment: exakte Übereinstimmung erforderlich
    → sub.yourdomain.com stimmt NICHT mit yourdomain.com überein ✗

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

DMARC - Das Bindeglied:

DMARC verbindet SPF + DKIM und definiert:
  1. Was soll passieren wenn BEIDE (SPF und DKIM) fehlschlagen?
  2. Wo sollen Aggregate Reports hingeschickt werden?
  3. Wie streng soll die Policy sein?

DNS-Record:
  Type: TXT
  Name: _dmarc.yourdomain.com
  Wert: "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com;
         ruf=mailto:dmarc-forensic@yourdomain.com; pct=100; adkim=r; aspf=r"

DMARC-Tags:
  v=DMARC1          → Pflicht, Version
  p=none             → Policy: none/quarantine/reject
  rua=mailto:...     → Aggregate Reports an diese Adresse
  ruf=mailto:...     → Forensic Reports (optional, Privacy-Implikationen!)
  pct=100            → % der E-Mails die Policy angewendet wird (Rollout!)
  adkim=r            → DKIM Alignment: r=relaxed, s=strict
  aspf=r             → SPF Alignment: r=relaxed, s=strict
  sp=reject          → Policy für Subdomains

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 scheitern:
  → SPF fail (Forwarding) + DKIM pass + DKIM aligned → DMARC PASS!
  → SPF pass + DKIM fail → DMARC PASS (wenn SPF aligned)

DMARC-Rollout (CRITICAL - nicht sofort auf reject!):

  Schritt 1: none (Monitoring, 2-4 Wochen):
    p=none; rua=mailto:dmarc@yourdomain.com
    → Sammelt Reports: WER sendet E-Mails von Ihrer Domain?
    → Kein Blocking! Nur Sichtbarkeit.
    → Analyse: bekannte Sender? Unbekannte? Drittanbieter?

  Schritt 2: quarantine mit niedrigem pct (2-4 Wochen):
    p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.com
    → 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
    → Alle fehlschlagenden E-Mails → Spam
    → Letzter Check: sind alle legitimen Sender konfiguriert?

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

DMARC Reports verstehen:
  Aggregate Reports (XML per E-Mail täglich/wöchentlich):
  → Von: empfangende E-Mail-Provider (Gmail, Microsoft, etc.)
  → Inhalt: Quell-IP, SPF-Result, DKIM-Result, DMARC-Result, Anzahl Mails
  → Tools für Visualisierung: Postmark DMARC, MxToolbox, Dmarcian

  Beispiel-Report-Daten:
    IP 203.0.113.1:  500 E-Mails, SPF pass, DKIM pass → DMARC pass ✓
    IP 198.51.100.5: 3 E-Mails, SPF fail, DKIM fail → DMARC fail ✗
    → Unbekannte IP sendet E-Mails als Ihre Domain! → Spoofing-Versuch!

BIMI (Brand Indicators for Message Identification)

BIMI - Logo-Anzeige als Vertrauenssignal:

Was ist BIMI?
  → Standard zur Logo-Anzeige direkt im E-Mail-Client (Gmail, Apple Mail, Yahoo)
  → Logo erscheint neben Absenderadresse → Vertrauenssignal für Empfänger
  → Voraussetzung: DMARC p=quarantine oder p=reject!

  Vorteile:
  → Klare Absender-Identifikation: echte E-Mails erkennbar
  → Phishing-Erkennung: gefälschte E-Mails haben kein Logo
  → Brand-Awareness: Logo in jedem E-Mail-Postfach

DNS-Record:
  Type: TXT
  Name: default._bimi.yourdomain.com
  Wert: "v=BIMI1; l=https://yourdomain.com/bimi-logo.svg; a=https://yourdomain.com/vmc.pem"

  l=: URL zum SVG-Logo (Tiny PS spec, gehostet auf HTTPS)
  a=: URL zum VMC (Verified Mark Certificate) - für Gmail Pflicht!

VMC (Verified Mark Certificate):
  → Ausgestellt von: Entrust oder DigiCert
  → Erfordert: eingetragene Marke (Trademark-Registrierung!)
  → Kosten: ~$1.000-1.500/Jahr
  → Prüft: Logo stimmt mit Marke überein, Domain-Ownership

Logo-Anforderungen:
  □ SVG-Format (Scalable Vector Graphics)
  □ Tiny PS (SVG Profile)
  □ Quadratisches Seitenverhältnis (1:1)
  □ Gehostet unter HTTPS auf der eigenen Domain
  □ Öffentlich erreichbar (kein Auth erforderlich)

  SVG-Validierung: https://bimigroup.org/bimi-svg-validator/

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

MTA-STS und TLS-RPT

MTA-STS (Mail Transfer Agent Strict Transport Security):

Problem ohne MTA-STS:
  → SMTP-TLS ist opportunistisch: Server fragen an ob TLS möglich
  → Angreifer kann TLS-Downgrade erzwingen → Klartextübertragung!
  → STARTTLS-Stripping-Angriffe möglich

MTA-STS löst das:
  → Empfangende Domain publiziert Policy: "Ich akzeptiere NUR TLS!"
  → Sendende Mail-Server cachen diese Policy
  → Wenn TLS nicht möglich: E-Mail WIRD NICHT gesendet (statt unsicher!)

Implementierung:
  1. Policy-Datei unter HTTPS:
     URL: https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
     Inhalt:
       version: STSv1
       mode: enforce
       mx: mail.yourdomain.com
       mx: mx2.yourdomain.com
       max_age: 604800

  2. DNS-Record:
     Type: TXT
     Name: _mta-sts.yourdomain.com
     Wert: "v=STSv1; id=20260304001"
     → id= ändert sich wenn Policy sich ändert (Cache-Invalidierung!)

  Modi:
    testing:  Policy verletzt → Senden trotzdem, nur Report
    enforce:  Policy verletzt → Senden verweigert (Ziel!)
    none:     Deaktiviert

TLS-RPT (TLS Reporting):

  Sendende Server melden TLS-Verbindungsprobleme:
  DNS-Record:
    Type: TXT
    Name: _smtp._tls.yourdomain.com
    Wert: "v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com"

  Reports enthalten:
  → TLS-Verbindungsfehler (Zertifikatsfehler, Downgrade-Versuche)
  → Anzahl erfolgreicher TLS-Verbindungen
  → MTA-STS-Richtlinienverstöße
  → Nützlich zur Diagnose von E-Mail-Zustellungsproblemen!

Implementierungs-Roadmap

Stufenweiser Rollout (empfohlen):

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 aufbauen mit allen legitimen Sendern
  □ DKIM für eigenen Mailserver konfigurieren und testen

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

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

Woche 9-12: Reject und Härtung
  □ p=reject pct=100 → VOLLSTÄNDIGER SCHUTZ!
  □ MTA-STS: testing → enforce
  □ TLS-RPT aktivieren
  □ BIMI vorbereiten (VMC bestellen, SVG vorbereiten)
  □ Monitoring-Dashboard einrichten

Laufend:
  □ DMARC-Reports wöchentlich auswerten
  □ Neue E-Mail-Sender sofort konfigurieren
  □ DKIM-Schlüsselrotation: jährlich
  □ SPF aktuell halten (neue Services, Migrationem)

DNS-Konfiguration Kurzübersicht:
  yourdomain.com              TXT  "v=spf1 ... -all"
  mail2026._domainkey.domain  TXT  "v=DKIM1; k=rsa; p=..."
  _dmarc.yourdomain.com       TXT  "v=DMARC1; p=reject; rua=mailto:..."
  _mta-sts.yourdomain.com     TXT  "v=STSv1; id=20260304001"
  mta-sts.yourdomain.com      HTTPS-hosted policy file
  _smtp._tls.yourdomain.com   TXT  "v=TLSRPTv1; rua=mailto:..."
  default._bimi.yourdomain.com TXT "v=BIMI1; l=...; a=..."

Test-Tools:
  MxToolbox:     https://mxtoolbox.com/SPFRecordViewer.aspx
  DMARC Analyzer: https://dmarcanalyzer.com
  Mail-Tester:   https://www.mail-tester.com (gesamter E-Mail-Score)
  Check-Auth:    checkdmarc (Python CLI-Tool für alle Records)

---

E-Mail-Authentifizierung ist keine optionale Härtungsmaßnahme mehr - Google und Yahoo fordern seit 2024 DMARC für Bulk-Sender, Microsoft 365 erhöht schrittweise die Anforderungen. Unternehmen ohne DMARC riskieren nicht nur Spoofing-Angriffe, sondern auch schlechtere Zustellbarkeit legitimer E-Mails. AWARE7 auditiert E-Mail-Sicherheitskonfigurationen und begleitet den DMARC-Rollout bis zum vollständigen p=reject.

E-Mail-Security-Check anfragen | Phishing-Simulation