E-Mail-Authentifizierung: SPF, DKIM & DMARC

SPF Deep Dive — die 10-DNS-Lookup-Falle

Das Sender Policy Framework (SPF, RFC 7208) definiert über einen DNS-TXT-Record, welche IP-Adressen berechtigt sind, E-Mails für eine Domain zu senden. Was die meisten Administratoren nicht wissen: SPF hat ein striktes Limit von 10 DNS-Lookups pro Auswertung. Jeder include:, a:, mx: und redirect= Mechanismus zählt als ein DNS-Lookup. Verschachtelte Includes werden rekursiv gezählt: Wenn Ihr SPF-Record include:spf.protection.outlook.com enthält und dieser wiederum 3 weitere Includes hat, verbrauchen Sie bereits 4 Lookups. Überschreiten Sie das Limit, liefert SPF ein PermError-Ergebnis — und je nach Empfänger-Konfiguration wird die E-Mail verworfen oder als verdächtig markiert.

Das 10-Lookup-Limit wird besonders problematisch, wenn Sie mehrere Cloud-Dienste nutzen: Microsoft 365 (include:spf.protection.outlook.com = 2 Lookups), Google Workspace (include:_spf.google.com = 3 Lookups), Salesforce, HubSpot, Mailchimp — jeder Dienst bringt 1-4 Lookups mit, und Sie sind schnell bei 12-15 Lookups. Die Lösung sind SPF Macro Expansion und SPF Flattening: Beim Flattening werden alle include:-Mechanismen durch die tatsächlichen IP-Adressen (ip4:/ip6:) ersetzt, die keine DNS-Lookups erfordern. Der Nachteil: Wenn ein Cloud-Provider seine IP-Bereiche ändert, ist Ihr geflatteter Record veraltet. Tools wie dmarcian SPF Surveyor oder AutoSPF automatisieren die Aktualisierung.

Ein weiteres kaum bekanntes Problem ist das +all-Antipattern: Manche Administratoren setzen ~all (Softfail) statt -all (Hardfail), weil sie befürchten, legitime E-Mails zu blockieren. Tatsächlich ist Softfail in einer DMARC-gestützten Umgebung genauso effektiv wie Hardfail, da DMARC die finale Entscheidung trifft. Aber: Ohne DMARC ist ~all nahezu wirkungslos — die meisten Empfänger-Server behandeln Softfail-Ergebnisse als neutral. Der häufigste Fehler überhaupt: Mehrere SPF-Records für dieselbe Domain. RFC 7208 Abschnitt 3.2 ist eindeutig: Es darf genau ein SPF-TXT-Record pro Domain existieren. Zwei Records führen zu einem PermError — und damit zu einem vollständigen Ausfall des SPF-Schutzes.

• Lookup-Zählung prüfen: dig +short TXT example.com | grep spf zeigt den SPF-Record. Nutzen Sie MXToolbox SPF Lookup oder python3 -c "import checkdmarc; print(checkdmarc.check_domains(['example.com']))" für eine vollständige Analyse mit Lookup-Zählung. Ziel: unter 8 Lookups bleiben (Puffer für Cloud-Provider-Änderungen).
• Void Lookup Limit (2): Neben dem 10-Lookup-Limit existiert ein kaum bekanntes Void-Lookup-Limit von 2 (RFC 7208 Abschnitt 4.6.4). Jeder DNS-Lookup, der NXDOMAIN oder einen leeren Ergebnissatz zurückliefert, zählt als „void Lookup“. Mehr als 2 Void Lookups führen ebenfalls zu PermError. Ursache: verwaiste Include-Einträge für Dienste, die Sie nicht mehr nutzen.
• SPF für Subdomains: SPF-Records werden nicht vererbt. Wenn Sie SPF nur für example.com konfigurieren, hat mail.example.com keinen SPF-Schutz. Angreifer nutzen gezielt Subdomains, für die kein SPF konfiguriert ist. Lösung: Für jede Subdomain, die E-Mails senden könnte (oder auch nicht), einen SPF-Record setzen — nicht sendende Subdomains erhalten v=spf1 -all.
• PTR-Mechanismus vermeiden: Der ptr: Mechanismus ist in RFC 7208 als „SHOULD NOT be used“ markiert. Er erfordert Reverse-DNS-Lookups, die langsam und unzuverlässig sind. Viele große Empfänger (Gmail, Microsoft) ignorieren PTR-Mechanismen vollständig. Verwenden Sie stattdessen ip4: und ip6:.

DKIM-Kryptographie — warum 1024-Bit-Schlüssel nicht mehr reichen

DomainKeys Identified Mail (DKIM, RFC 6376) signiert E-Mails kryptographisch mit einem privaten Schlüssel, der auf dem sendenden Mailserver liegt. Der zugehörige öffentliche Schlüssel wird als DNS-TXT-Record unter selektor._domainkey.example.com veröffentlicht. Der Empfänger-Server liest den öffentlichen Schlüssel aus DNS und verifiziert die Signatur — stimmt sie überein, ist die E-Mail nicht verändert worden und stammt von einem autorisierten Server. Was viele nicht wissen: DKIM signiert standardmäßig nicht den gesamten Body. Der l=-Tag (length) in der DKIM-Signatur kann die Signierung auf die ersten N Bytes des Body beschränken. Ein Angreifer kann Content nach dem signierten Bereich anhängen — die Signatur bleibt gültig. Google und Microsoft haben diesen Tag mittlerweile als verdächtig eingestuft, aber er wird immer noch von einigen Mailservern akzeptiert.

Die Schlüssellänge ist ein weiterer kritischer Punkt: Viele Domains verwenden noch 1024-Bit-RSA-Schlüssel, die seit 2017 als schwach gelten. Das Problem: DNS-TXT-Records haben eine maximale Länge von 255 Bytes pro String, und ein 2048-Bit-Schlüssel überschreitet diese Grenze. Die Lösung ist die Verkettung mehrerer Strings im TXT-Record (RFC 7208 erlaubt dies), aber viele DNS-Provider und DKIM-Bibliotheken behandeln verkettete TXT-Records fehlerhaft. Empfehlung: Verwenden Sie 2048-Bit-RSA und testen Sie die Signaturvalidierung mit opendkim-testkey -d example.com -s selektor -vvv. Für maximale Sicherheit: Ed25519-DKIM (RFC 8463) bietet 128-Bit-Sicherheitsniveau bei einem nur 44 Zeichen langen öffentlichen Schlüssel — kein DNS-Splitting erforderlich. Allerdings unterstützen bisher nur wenige Mailserver Ed25519.

• DKIM Key Rotation: DKIM-Schlüssel sollten alle 6–12 Monate rotiert werden. Verwenden Sie dafür zwei Selektoren (z. B. s1 und s2): Generieren Sie den neuen Schlüssel unter s2._domainkey, warten Sie 48 Stunden (DNS-Propagation), stellen Sie den Mailserver auf Selektor s2 um, warten Sie weitere 7 Tage (Empfänger-Caches), löschen Sie den alten s1-Record. Beim nächsten Wechsel rotieren Sie zurück auf s1.
• DKIM Replay-Angriff: Ein kaum bekannter, aber effektiver Angriff: Der Angreifer empfängt eine legitime DKIM-signierte E-Mail von Ihrer Domain (z. B. über einen Newsletter) und leitet sie an Tausende andere Empfänger weiter. Die DKIM-Signatur bleibt gültig, da sie den Body nicht verändert haben. Verteidigung: ARC (Authenticated Received Chain, RFC 8617) erlaubt Intermediate Hosts, ihren eigenen Authentifizierungsstatus zu dokumentieren, und Empfänger können unerwartete Weiterleitungen erkennen.
• Canonicalization-Probleme: DKIM bietet zwei Canonicalization-Modi: simple und relaxed. Im simple-Modus führt jedes geänderte Leerzeichen oder Zeilenumbruch zum Bruch der Signatur. Mailing-Listen, Virenscanner und Disclaimer-Tools ändern häufig den Body und brechen damit die DKIM-Signatur. Empfehlung: Verwenden Sie relaxed/relaxed (Header/Body) und signieren Sie mindestens: h=from:to:subject:date:message-id:content-type:mime-version.
• Third-Party-Signierung überwachen: Cloud-Dienste (Mailchimp, SendGrid, HubSpot) signieren E-Mails mit eigenen DKIM-Selektoren auf Ihrer Domain. Prüfen Sie regelmäßig: dig +short TXT *._domainkey.example.com — gibt es Selektoren, die Sie nicht kennen? Ein vergessener DKIM-Selektor von einem gekündigten Dienstleister ist ein potenzieller Angriffsvektor.

DMARC & Alignment — das Zusammenspiel verstehen

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) verbindet SPF und DKIM zu einem durchsetzbaren System. Die zentrale Idee ist Alignment: Es reicht nicht, dass SPF oder DKIM bestehen — die authentifizierte Domain muss mit der sichtbaren Absenderdomain (From: Header) übereinstimmen. Dies ist der Punkt, an dem die meisten Konfigurationen scheitern. SPF validiert die Envelope-From-Adresse (MAIL FROM in SMTP), während der Benutzer die Header-From-Adresse sieht. Ein Angreifer kann eine E-Mail mit MAIL FROM: [email protected] (SPF pass für boese.de) und From: [email protected] (Header) senden. Ohne DMARC sieht der Empfänger [email protected] als Absender, obwohl SPF bestanden hat — aber für die falsche Domain. DMARC erfordert, dass entweder die SPF-Domain (Envelope-From) oder die DKIM-Domain (d=) mit der Header-From-Domain übereinstimmt (aligned).

DMARC bietet zwei Alignment-Modi: strict (aspf=s / adkim=s) erfordert exakte Übereinstimmung, relaxed (aspf=r / adkim=r) erlaubt Subdomain-Matching (z. B. mail.example.com ist aligned mit example.com). Die meisten Organisationen starten mit p=none (nur Monitoring), gehen dann über p=quarantine (Spam-Ordner) zu p=reject (verwerfen). Der häufigste Fehler: Zu früh auf p=reject umstellen, bevor alle legitimen Sendequellen korrekt konfiguriert sind. Analysieren Sie die DMARC Aggregate Reports (RUA) mindestens 4–8 Wochen lang, bevor Sie die Policy verschärfen. Die Reports kommen im XML-Format und enthalten detaillierte Informationen über jeden Server, der E-Mails in Ihrem Namen versendet hat.

• DMARC Rollout-Strategie: Phase 1: v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected] — 4-8 Wochen sammeln und analysieren. Phase 2: p=quarantine; pct=10 — nur 10 % der E-Mails betroffen, schrittweise auf 100 % erhöhen. Phase 3: p=reject — vollständiger Schutz. Tools für Report-Analyse: dmarcian, Valimail, postmark DMARC Digests (kostenlos).
• Subdomain-Policy (sp=): Kaum bekannt, aber kritisch: Ohne sp=-Tag erben Subdomains die Policy der Hauptdomain. Aber: Wenn die Hauptdomain p=reject hat und ein Angreifer invoicing.example.com spooft (für die keine eigene DMARC-Policy existiert), wird der Reject nicht angewendet, wenn die Subdomain eigene, fehlerhafte SPF/DKIM-Konfiguration hat. Setzen Sie explizit sp=reject und konfigurieren Sie nicht sendende Subdomains mit v=spf1 -all und einem eigenen DMARC-Record.
• MTA-STS (RFC 8461): DMARC schützt vor Absender-Fälschung, aber nicht vor Man-in-the-Middle bei der Übertragung. SMTP-Server verwenden standardmäßig opportunistisches TLS (STARTTLS) — ein Angreifer kann die TLS-Aushandlung unterdrücken und die E-Mail im Klartext mitlesen. MTA-STS erzwingt TLS-Verschlüsselung und Zertifikatsvalidierung: Erstellen Sie eine Policy-Datei unter https://mta-sts.example.com/.well-known/mta-sts.txt und einen DNS-TXT-Record _mta-sts.example.com.
• BIMI (Brand Indicators for Message Identification): Die nächste Stufe: Zeigt Ihr Firmenlogo direkt neben dem Absendernamen im E-Mail-Client (Gmail, Apple Mail). Voraussetzung: p=quarantine oder p=reject DMARC-Policy + ein VMC (Verified Mark Certificate) von DigiCert oder Entrust (~1.500 €/Jahr). Der DNS-Record: default._bimi.example.com IN TXT "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem". Das Logo muss als Tiny PS SVG (SVG Portable/Secure) vorliegen — ein spezielles, eingeschränktes SVG-Profil ohne JavaScript oder externe Referenzen.
• DANE/TLSA (RFC 6698): Eine Alternative zu MTA-STS für DNSSEC-fähige Domains: DANE bindet das TLS-Zertifikat des Mailservers direkt an einen DNS-TLSA-Record. Vorteil: Kein Trust-on-First-Use wie bei MTA-STS — der Empfänger kennt den erwarteten Zertifikats-Fingerprint sofort. Nachteil: Erfordert DNSSEC auf beiden Seiten. In der Praxis wird DANE häufig in Deutschland und den Niederlanden eingesetzt (DE-CIX-Umfeld), international dominiert MTA-STS.