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 hat keinen Mechanismus, der prüft ob der angegebene Absender tatsächlich der echte Absender ist. Jeder kann über eine SMTP-Verbindung beliebige MAIL FROM- und From:-Header setzen:

telnet mail.example.com 25
EHLO attacker.com
MAIL FROM: ceo@ihrfirma.de
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 legt fest welche IP-Adressen für eine Domain senden dürfen, DKIM prüft ob der Domain-Inhaber die E-Mail kryptografisch signiert hat, und DMARC gibt Empfangsservern Anweisungen was bei Fehlschlagen passieren soll.

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 bestimmen welche Quellen autorisiert sind: ip4:/ip6: für Adressbereiche, a und mx für eigene DNS-Records, include: für Drittanbieter-Server (Google Workspace, Mailchimp etc.) und redirect= für vollständige Weiterleitungen.

Qualifikatoren legen das Ergebnis bei Übereinstimmung fest: + (pass, Standard), - (fail, empfohlen für -all), ~ (softfail, für Rollout-Stadien) und ? (neutral, niemals als Endwert verwenden).

Wichtige Grenzen: SPF schützt nur den Envelope-From (Return-Path), nicht den Header-From (sichtbarer Absender). E-Mail-Forwarding bricht SPF weil der weitergeleitende Server nicht im SPF-Record steht. Das Lookup-Limit von maximal 10 DNS-Lookups muss eingehalten werden - zu viele include:-Einträge führen zu SPF PermError. SPF-Flattening-Tools können helfen.

SPF-Fehler

Das gefährlichste Muster ist v=spf1 +all, das alle IPs autorisiert und keinen Schutz bietet. ~all dauerhaft verwenden ist ebenfalls problematisch - Soft Fail bedeutet nur eine Warnung, keine Ablehnung. Der korrekte Endwert ist -all.

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.

Der sendende Server signiert E-Mail-Header und Body mit dem privaten RSA-Key. Die Signatur wird als DKIM-Signature-Header eingefügt. Der empfangende Server liest den Selektor aus der Signatur, lädt den öffentlichen Key aus dem DNS und prüft die Signatur.

DKIM-Record einrichten

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 für eigene Mailserver:

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

Schlüssel können ohne Downtime rotiert werden: Neuen Selektor (z. B. "selector2") in DNS publizieren, MTA auf den neuen Selektor umschalten, alten Selektor erst nach 48 Stunden TTL-Ablauf entfernen. In-Transit-E-Mails müssen noch verifiziert werden können.

DKIM-Alignment ist für DMARC entscheidend: Die Signatur-Domain (d=) muss mit dem From-Header übereinstimmen. Relaxed Alignment (Standard) erlaubt Subdomains. Mailing-Listen-Problem: Mailing-Listen modifizieren Subject und Body, was die DKIM-Signatur ungültig macht. Lösung: 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	Bedeutung
p=none/quarantine/reject	Policy für nicht-konforme E-Mails
rua=	Aggregate Reports (täglich, XML)
ruf=	Forensic Reports (pro E-Mail; Privacy-Implikationen beachten!)
fo=0/1/d/s	Forensic Options: wann Forensic-Report senden?
adkim=r/s	DKIM-Alignment: relaxed oder strict
aspf=r/s	SPF-Alignment: relaxed oder strict
pct=0-100	Prozentsatz der Enforcement (für schrittweisen Rollout)
sp=	Policy für Subdomains

DMARC-Alignment-Logik: Eine E-Mail besteht den DMARC-Check wenn mindestens eines gilt: SPF Pass und SPF aligned (Return-Path-Domain = From-Domain) oder DKIM Pass und DKIM aligned (d= Domain = From-Domain). Beide können unabhängig scheitern - SPF-Fail durch Forwarding und gleichzeitig DKIM-Pass mit korrektem Alignment ergibt trotzdem DMARC-Pass.

DMARC-Rollout-Strategie

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

Schritt 1 (2-4 Wochen, p=none): Nur Reports, keine Aktion. Welche Systeme senden E-Mails als die Domain? rua-Reports analysieren.

Schritt 2 (2-4 Wochen, p=quarantine; pct=10): 10% der fehlschlagenden E-Mails gehen in den Spam-Ordner. Legitime E-Mails im Spam überwachen. pct schrittweise erhöhen: 10 → 25 → 50 → 100.

Schritt 3 (1-2 Wochen, p=quarantine; pct=100): Letzter Check ob alle legitimen Sender konfiguriert sind.

Schritt 4 (Ziel: p=reject; pct=100): Fehlschlagende E-Mails werden per SMTP-Fehler abgelehnt. Vollständiger Schutz vor E-Mail-Spoofing.

DMARC-Reports auswerten

Aggregate Reports kommen täglich im XML-Format von empfangenden Mail-Providern:

<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>
<!-- Eintrag 1: legitime M365-Mails (alles PASS) - OK
     Eintrag 2: unbekannte IP, SPF+DKIM fail - Spoofing-Versuch! -->

Tools für Report-Auswertung: dmarcian.com, dmarcanalyzer.com (DSGVO-konform, europäischer Anbieter), Postmark DMARC-Wizard, easydmarc.com und parsedmarc (Python CLI für SIEM-Integration).

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: DMARC auf p=quarantine oder p=reject (pct=100), SVG-Logo im Format "SVG Tiny PS" (quadratisch 1:1, max. 32 KB, HTTPS-gehostet, kein eingebettetes JavaScript) und für Gmail ein VMC (Verified Mark Certificate) von Entrust oder DigiCert (erfordert eingetragene Marke, ca. 1.000-1.500 EUR/Jahr).

Client-Unterstützung:

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

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.

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 sendet trotz Policy-Verletzung aber erstellt einen Report, enforce verweigert das Senden bei Policy-Verletzung (Ziel), none hebt die Policy auf.

Schritt 2: DNS-Record setzen

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

Das id=-Feld muss sich ändern wenn die Policy-Datei geändert wird (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 hinterlegt ein TLS-Zertifikat direkt in DNSSEC-gesicherten DNS-Records als alternative Transportabsicherung:

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

Voraussetzung: DNSSEC muss für die Domain aktiv sein. Ohne DNSSEC bietet DANE keinen Mehrwert.

# 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: v=spf1 +all lässt alle IPs zu, v=spf1 ?all ist neutral ohne Sicherheitsaussage. Richtig: v=spf1 ... -all.
2. SPF mit ~all als Dauerlösung: Soft Fail ist nur ein temporäres Rollout-Stadium, kein Endzustand.
3. DKIM-Key zu klein: 1024-Bit ist nicht mehr sicher (Faktorisierung möglich). Minimum: 2048 Bit; Empfehlung: 4096 Bit oder Ed25519.
4. DMARC p=none dauerhaft: Sammelt Daten aber bietet keinen Schutz - Angreifer können trotzdem spoofing betreiben. Ziel ist p=reject.
5. DMARC rua-Adresse nicht überwacht: Reports kommen täglich, werden ignoriert, unbekannte Drittsender bleiben unerkannt.
6. Fehlende Subdomain-Policy: DMARC für ihrfirma.de schützt nicht automatisch test.ihrfirma.de. sp=reject ergänzen.
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: Der MTA-STS-DNS-Record selbst ist ohne DNSSEC angreifbar.

Implementierungs-Roadmap

Woche 1-2: Bestandsaufnahme - Welche Systeme senden E-Mails als die Domain? (eigene Mailserver, Transactional E-Mail, Marketing-Tools, CRM, ERP, HR-Software, Kundenportal-Notifications) - SPF-Record aufbauen, DKIM konfigurieren und testen.

Woche 3-4: Aktivierung mit p=none - DMARC aktivieren, Reports sammeln und auswerten, unbekannte Sender identifizieren und nachkonfigurieren.

Woche 5-8: Quarantine-Rollout - p=quarantine; pct=10 schrittweise auf 100 erhöhen, Monitoring auf legitime E-Mails im Spam, alle Drittanbieter-Sender vollständig konfigurieren, Subdomain-Policy setzen.

Woche 9-12: Reject und Härtung - p=reject; pct=100, MTA-STS auf mode=enforce, TLSRPT aktivieren, BIMI vorbereiten (VMC bestellen, SVG-Logo validieren).

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

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

dig TXT ihrfirma.de | grep spf
dig TXT mail2026._domainkey.ihrfirma.de
dig TXT _dmarc.ihrfirma.de
dig TXT default._bimi.ihrfirma.de
dig TXT _mta-sts.ihrfirma.de

Online-Tools: mxtoolbox.com/SuperTool.aspx für SPF, DKIM und DMARC, mail-tester.com für den gesamten E-Mail-Score, dmarcian.com/dmarc-inspector/ für DMARC-Record-Analyse, internet.nl als BSI-empfohlener Checker und postmaster.google.com für Google Postmaster Tools.

E-Mail-Security-Checkliste

SPF: Record vorhanden, endet mit -all, alle E-Mail-Dienste eingetragen, unter 10 DNS-Lookups.

DKIM: Für alle Absender-Systeme konfiguriert, Schlüssellänge mindestens 2048 Bit, Schlüsselrotation geplant.

DMARC: Policy 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.