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

SMTP (Simple Mail Transfer Protocol) aus dem Jahr 1982 hat keinen eingebauten Authentifizierungsmechanismus. Jeder SMTP-Server kann beliebige From:-Header setzen. Ein Angreifer schickt über seinen eigenen Server eine E-Mail mit MAIL FROM: <ceo@yourcompany.com> und setzt im Body From: CEO <ceo@yourcompany.com>. Der Empfänger sieht den gefälschten Absender ohne technische Möglichkeit, dies zu erkennen.

Das dreistufige Authentifizierungsmodell löst das Problem: SPF legt fest welche IP-Adressen für eine Domain senden dürfen (DNS-Record mit autorisierten Absender-IPs). DKIM prüft ob der Domain-Inhaber die E-Mail kryptografisch signiert hat (privater Schlüssel am sendenden Server, öffentlicher Schlüssel im DNS). DMARC verknüpft SPF und DKIM über "Alignment" mit dem From-Header und definiert die Policy: none (nur Monitoring), quarantine oder reject.

SPF (Sender Policy Framework)

Der SPF-DNS-Eintrag autorisiert Absender-IPs und -Hosts:

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

Die Mechanismen im Überblick: ip4:/ip6: autorisiert Adressbereiche direkt, a und mx autorisieren die eigenen DNS-Records, include: bindet Drittanbieter-Server ein (Google Workspace, Mailchimp etc.). Qualifikatoren legen das Ergebnis fest: + (pass, Standard), - (fail, empfohlen für -all), ~ (softfail) und ? (neutral, niemals verwenden).

Wichtige Grenzen und häufige Fehler: 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 schützt nur den Envelope-From (Return-Path), nicht den Header-From (sichtbarer Absender). E-Mail-Forwarding bricht SPF, weil der weiterleitende Server nicht im SPF-Record steht. ~all als Soft-Fail ist nur ein temporäres Rollout-Stadium; das Ziel ist -all. ?all gibt keinerlei Sicherheit und sollte niemals verwendet werden.

DKIM (DomainKeys Identified Mail)

Der sendende Server erstellt eine Signatur über E-Mail-Inhalt und ausgewählte Header, hängt diese als DKIM-Signature-Header an. Der empfangende Server liest den Selektor aus der Signatur, findet den DNS-Record und verifiziert die Signatur mit dem öffentlichen Schlüssel.

DNS-Record und Schlüssel-Generierung:

mail2026._domainkey.yourdomain.com  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G..."

openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -out dkim_public.pem -pubout
openssl rsa -in dkim_private.pem -pubout -outform DER | base64 -w 0

Best Practices: RSA-Schlüssel mindestens 2048 Bit (4096 empfohlen), Ed25519 als moderne Alternative, Schlüsselrotation alle 6-12 Monate, alte Selektoren nicht sofort löschen (In-Transit-E-Mails), alle ausgehenden E-Mails signieren (inklusive Transactional E-Mail).

DKIM-Alignment für DMARC: Die DKIM-Signatur-Domain (d=) muss mit dem From-Header übereinstimmen. Relaxed Alignment (Standard) erlaubt Subdomains: sub.yourdomain.com stimmt mit yourdomain.com überein. Strict Alignment erfordert exakte Übereinstimmung.

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

DMARC verbindet SPF und DKIM und definiert: Was passiert wenn beide fehlschlagen? Wohin sollen Aggregate Reports? Wie streng soll die Policy sein?

_dmarc.yourdomain.com  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; pct=100; adkim=r; aspf=r; sp=reject"

DMARC-Tags:

Tag	Bedeutung
p=	Policy: none/quarantine/reject
rua=	Aggregate Reports an diese Adresse
ruf=	Forensic Reports (optional, Privacy-Implikationen!)
pct=	Prozentsatz der E-Mails mit angewandter Policy (für Rollout)
adkim=r/s	DKIM Alignment: relaxed oder strict
aspf=r/s	SPF Alignment: relaxed oder strict
sp=	Policy für Subdomains

DMARC-Alignment-Logik: Eine E-Mail besteht den DMARC-Check wenn mindestens eines zutrifft: 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 ergibt trotzdem DMARC-Pass.

DMARC-Rollout (nicht sofort auf reject!):

Schritt 1 (p=none, 2-4 Wochen): Sammelt Reports, kein Blocking. Welche Systeme senden E-Mails von der Domain? Analyse: bekannte Sender, unbekannte, Drittanbieter?

Schritt 2 (p=quarantine; pct=10, 2-4 Wochen): 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 (p=quarantine; pct=100, 1-2 Wochen): Alle fehlschlagenden E-Mails gehen in Spam. Letzter Check: alle legitimen Sender konfiguriert?

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

DMARC-Reports auswerten: Aggregate Reports kommen täglich per XML-E-Mail von empfangenden Providern und enthalten Quell-IP, SPF-Ergebnis, DKIM-Ergebnis und Anzahl Mails. Beispiel-Interpretation: IP 203.0.113.1 mit 500 E-Mails und SPF/DKIM pass ist ein legitimer Sender. IP 198.51.100.5 mit 3 E-Mails und SPF/DKIM fail ist ein Spoofing-Versuch. Tools für Visualisierung: Postmark DMARC, MxToolbox, Dmarcian.

BIMI (Brand Indicators for Message Identification)

BIMI zeigt das Firmenlogo direkt im E-Mail-Client (Gmail, Apple Mail, Yahoo) als Vertrauenssignal. Das Logo erscheint neben der Absenderadresse. Voraussetzung: DMARC auf p=quarantine oder p=reject.

default._bimi.yourdomain.com  IN  TXT  "v=BIMI1; l=https://yourdomain.com/bimi-logo.svg; a=https://yourdomain.com/vmc.pem"

Das VMC (Verified Mark Certificate) ist für Gmail Pflicht: ausgestellt von Entrust oder DigiCert, erfordert eine eingetragene Marke (Trademark-Registrierung), kostet ca. 1.000-1.500 USD/Jahr und prüft ob Logo und Marke übereinstimmen.

Logo-Anforderungen: SVG-Format (Tiny PS), quadratisches Seitenverhältnis (1:1), HTTPS-gehostet auf der eigenen Domain, öffentlich erreichbar. Validierung: bimigroup.org/bimi-svg-validator.

BIMI-Unterstützung: Gmail ja (VMC für blauen Haken), Apple Mail ja (seit iOS 16), Yahoo Mail ja (VMC empfohlen aber nicht Pflicht), Outlook.com in Vorbereitung (2026), Microsoft 365 noch nicht.

MTA-STS und TLS-RPT

MTA-STS löst ein SMTP-Transport-Problem: SMTP-TLS ist opportunistisch - Server fragen an ob TLS möglich ist. Angreifer können TLS-Downgrade erzwingen und Klartext-Übertragung erzwingen (STARTTLS-Stripping). MTA-STS lässt die empfangende Domain eine Policy publizieren: "Ich akzeptiere NUR TLS!" Sendende Mail-Server cachen diese Policy und verweigern das Senden wenn TLS nicht möglich ist.

Implementierung: Eine Policy-Datei unter HTTPS bereitstellen (https://mta-sts.yourdomain.com/.well-known/mta-sts.txt) mit Inhalt version: STSv1, mode: enforce, den MX-Einträgen und max_age. Dann den DNS-Record setzen:

_mta-sts.yourdomain.com  IN  TXT  "v=STSv1; id=20260304001"

Das id=-Feld muss sich bei Änderung der Policy-Datei ändern (Cache-Invalidierung). Modi: testing sendet trotzdem aber erstellt einen Report, enforce verweigert das Senden (Ziel), none deaktiviert.

TLS-RPT lässt sendende Server TLS-Verbindungsprobleme melden:

_smtp._tls.yourdomain.com  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com"

Reports enthalten TLS-Verbindungsfehler, Zertifikatsfehler, Downgrade-Versuche, MTA-STS-Richtlinienverstöße und Statistiken über erfolgreiche TLS-Verbindungen. Nützlich zur Diagnose von E-Mail-Zustellungsproblemen.

Implementierungs-Roadmap

Woche 1-2: Bestandsaufnahme - Alle E-Mail-sendenden Systeme erfassen (eigene Mailserver, Transactional E-Mail, Marketing-Tools, CRM, ERP, HR-Software, Kundenportal-Notifications), SPF-Record aufbauen, DKIM für eigene Mailserver konfigurieren und testen.

Woche 3-4: Aktivierung mit p=none - DMARC aktivieren, Reports über DMARC Analyzer oder Postmark sammeln, unbekannte Sender identifizieren und konfigurieren.

Woche 5-8: Quarantine-Rollout - p=quarantine; pct=10 schrittweise auf 100 erhöhen, Monitoring auf legitime E-Mails im Spam der Empfänger, alle Drittanbieter-Sender mit SPF-include und DKIM konfigurieren, Subdomain-Policy setzen.

Woche 9-12: Reject und Härtung - p=reject; pct=100 für vollständigen Schutz, MTA-STS von testing auf 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 bei Migrationen und neuen Services aktuell halten.

DNS-Konfiguration Kurzübersicht

yourdomain.com                    TXT  "v=spf1 ... -all"
mail2026._domainkey.yourdomain.com  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"
_smtp._tls.yourdomain.com         TXT  "v=TLSRPTv1; rua=mailto:..."
default._bimi.yourdomain.com      TXT  "v=BIMI1; l=...; a=..."

Test-Tools: MxToolbox (mxtoolbox.com/SPFRecordViewer.aspx), DMARC Analyzer (dmarcanalyzer.com), Mail-Tester (mail-tester.com für gesamten E-Mail-Score) und checkdmarc als 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