💭 Jeremys Brain

spf-dkim-dmarc

5 min read

Protokoll-Schwachstellen auf der DNS-Ebene: Warum SPF, DKIM und DMARC nur gemeinsam wirken

E-Mail-Sicherheit basiert auf drei DNS-gestützten Mechanismen. Jede einzelne Komponente ist isoliert umgehbar. Erst deren korrekte Kombination mit strikter Policy-Härtung und Telemetrie senkt das Risiko signifikant.

  1. SPF (Sender Policy Framework)

Problem

  • Geltungsbereich: SPF greift nur auf der exakt geprüften Domain (MAIL FROM/HELO). Ein Record für example.com schützt nicht automatisch sub.example.com.
  • Semantik: Ergebnisse wie None oder Neutral sind kein technischer Ablehnungsgrund gemäß gängiger MTA-Standards.

Risiko

  • Subdomain-Spoofing führt zu SPF=None/Neutral. Inbound-Systeme, die Reputation über Policy stellen, akzeptieren solche Mails.

Härtung

  • DMARC erzwingen: p=reject oder p=quarantine, sp=reject für Subdomains, aspf=s (strict).
  • SPF straffen: Nur notwendige Absender-IP-Ranges/Includes, keine breit gefassten include-Kaskaden, -all statt ~all.
  • Subdomains absichern: Für aktiv sendende Subdomains explizite SPF-Records; nicht genutzte Subdomains per DMARC sp=reject blockieren. Wildcard-TXT-Records sind operativ heikel und kollidieren oft mit anderen TXT-Nutzungen.
  • DNS-Gesundheit: Rekursive Includes (<10 DNS-Looksups), TTLs, keine zirkulären Verweise.

Verifikation

  • TXT-Records gezielt prüfen: bash dig +short TXT example.com dig +short TXT sub.example.com dig +trace TXT example.com

    SPF-Auswertung (lokal): spfquery —scope mfrom —identity postmaster@example.com —ip 203.0.113.10

  1. DKIM (DomainKeys Identified Mail)

Problem

  • Identitätsmodell: DKIM validiert Integrität, nicht die Absender-Identität im Header From. Ein valider DKIM-Signaturstatus allein ist kein Identitätsbeweis.

Risiko

  • Angreifer signieren mit einem gültigen Schlüssel der eigenen Domain, fälschen jedoch den sichtbaren From-Header der Ziel-Domain. Ohne DMARC-Alignment wird die Mail akzeptiert.

Härtung

  • DMARC-Alignment erzwingen: adkim=s (strict), p=reject/quarantine.
  • Schlüsselhygiene: 2048-bit RSA (oder Ed25519, falls Sender/Empfänger-Ökosystem kompatibel), kurze TTLs, regelmäßige Rotation, alte Selector entfernen.
  • Drittanbieter: Nur aligned From verwenden (organisational oder subdomänig), pro Sender eigener Selector, vertraglich geregelte Schlüssel- und Header-Policies.

Verifikation

  • Selector- und Key-Prüfung: bash dig +short TXT selector1._domainkey.example.com opendkim-testkey -d example.com -s selector1 -vvv
  1. DMARC (Domain-based Message Authentication, Reporting & Conformance)

Problem

  • Wirkungslosigkeit bei p=none. Fehlt eine harte Policy, entscheiden Empfänger auf Basis von Reputation/Heuristik.

Risiko

  • Nachrichten von IPs mit hoher Reputation (z. B. Shared-Pools großer Mail-Dienstleister) werden trotz SPF/DKIM-Fehlschlägen zugestellt, wenn DMARC nicht greift.

Härtung

  • Harte Policy: p=reject (bzw. p=quarantine als Zwischenschritt), aspf=s, adkim=s, pct=100.
  • Subdomain-Policy: sp=reject, np=reject (für Non-Mail-Domains).
  • Reporting: rua= für Aggregate, ruf= für Forensik (unter Beachtung Datenschutz/Volumensteuerung), fo=1 (alle Fehler reporten).
  • Durchsetzung Inbound: MTA/SEG so konfigurieren, dass DMARC-Fail bei p=reject zu Ablehnung führt; p=none mindestens markieren/isolieren.

Beispiel-Record

Verifikation bash dig +short TXT _dmarc.example.com

  1. DNS-Integrität und Transport
  • DNSSEC: SPF/DKIM/DMARC sind DNS-basiert. Zonen signieren und bei Registrar/Resolvern DNSSEC aktivieren, um Records gegen Manipulation abzusichern.
  • MTA-STS und TLS-RPT: Opportunistisches SMTP-TLS auf Richtlinienebene absichern; Zustell- und TLS-Fehlerpfade sichtbar machen.
  • DANE für SMTP (mit DNSSEC): TLSA-Records für zusätzliche Transportintegrität einsetzen, falls Ökosystem-kompatibel.

Gängige Angreifer-Werkzeuge: Fähigkeiten und Verteidigungsansätze

SWAKS (Swiss Army Knife for SMTP)

Fähigkeiten

  • Manuelles Steuern des SMTP-Dialogs, klare Trennung von Envelope-From und Header-From, reproduzierbare Testszenarien.

Defensiv relevant

  • Header-Alignment prüfen: Abweichungen zwischen MAIL FROM, HELO/EHLO, Return-Path und Header From korrelieren.
  • HELO/EHLO-Anomalien: Mismatch zu Reverse DNS, synthetische Hostnamen, fehlende PTR-Kohärenz.
  • Empfangskette: Received:-Kette, fehlende DKIM-Signatur für sichtbaren From-Namespace.

Gophish (Phishing-Orchestrator)

Fähigkeiten

  • Kampagnenverwaltung, Templating, Tracking-Parameter (z. B. ?rid=).

Defensiv relevant

  • URL-Indikatoren: Parameterisierte IDs, nichtssagende Subdomains, registrierte Domains <30 Tage, TLD-Muster.
  • HTML/DOM-Heuristik: Externe Ressourcen, Mischinhalte, On-Click-Handler, Inkonsistenzen bei Brand-Assets.
  • Mail-Varianten: Leichte Template-Divergenzen, unübliche MIME-Grenzen, fehlende/fehlerhafte List-Unsubscribe-Header.

Evilginx2 (Reverse-Proxy für Session-Hijacking)

Fähigkeiten

  • MITM-Proxying legitimer Logins, Abgreifen von Session-Cookies trotz klassischer MFA.

Defensiv relevant

  • Phishing-resistente MFA: WebAuthn/FIDO2 (Origin-Bindung) erzwingen; Push/OTP ist gegen MITM schwach.
  • Gerätebindung: Conditional Access an Gerätestatus binden (MDM/EDR), Device-bound-Tokens/Passkeys nutzen, wo verfügbar.
  • Sitzungshygiene: Kurze Token-Laufzeiten, Reauth bei neuer Geräteklasse/User-Agent, Geo-/ASN-Verhaltensanalyse, risk-basierte Session-Revocation.
  • Domain-Intelligence: Lookalikes, neu registrierte Domains, verdächtige Zertifikatsmuster (kurzlebige DV-Zertifikate), TLS-Fingerprints von bekannten Phishing-Stacks.

Infrastruktur & Reputation: Warum “gute” Absender dennoch riskant sind

Cloud-Provider (AWS, DigitalOcean, Hetzner)

  • Realität: Günstige VPS mit sauberem PTR werden nicht pauschal als Spam eingestuft.
  • Abwehr:
    • PTR/HELO-Kohärenz prüfen, aber nicht als alleinigen Entscheidungsfaktor nutzen.
    • Young-IP/ASN-Signale gewichten, insbesondere bei p=none/fehlendem DMARC.

SMTP-Relays (SendGrid, Mailjet u. a.)

  • Realität: Shared-Pools besitzen starke Reputation und exzellente Zustellraten.
  • Abwehr:
    • DMARC-Policy respektieren und durchsetzen; kein “Reputation > Policy”.
    • Header-From-Alignment erzwingen; generische Return-Path-Domains (z. B. sendgrid.net) ohne Alignment isolieren.
    • ARC vorsichtig interpretieren; nicht als Freifahrtschein nutzen.
    • Anomalien in X-Headern und Auth-Results korrelieren (spf=pass für fremde Domain + dkim=pass für andere Domain + dmarc=none ⇒ hochriskant).

Operative Prüfkommandos

  • Reverse DNS und HELO/PTR-Kohärenz: bash dig -x 203.0.113.10 +short

    EHLO-Name aus Received-Headern extrahieren und gegentesten:

    dig A mail.ehlo-name.example +short

  • MX- und MTA-STS/DANE-Basis: bash dig MX example.com +short dig _mta-sts.example.com TXT +short dig _smtp._tls.example.com TLSA +short

  • Header-basierte Inbound-Validierung (lokal mit gespeicherter EML-Datei): bash ripgrep -n “Authentication-Results” message.eml ripgrep -n “^Received:” message.eml ripgrep -n “^From:” message.eml

Inbound-Policy-Empfehlungen (MTA/SEG)

  • Ablehnen bei:

    • DMARC=fail und Policy p=reject/quarantine.
    • Organisationaler From-Domain ohne SPF/DKIM-Pass im Alignment, sofern unternehmenseigene Domain betroffen.

  • Isolieren/Taggen bei:

    • DMARC p=none oder fehlend.
    • Mischzuständen (spf=pass für fremde Domain, dkim=pass für andere Domain, dmarc=none).
    • Neu registrierte Absenderdomänen (<30/60 Tage), unbekannte ASNs, frische IPs.

  • Whitelisting nur bei:

    • Striktem Alignment (SPF/DKIM) und vertraglich abgesicherter Versandkette (dedizierte Subdomänen, dedizierte IPs/Keys, klare Selector-Nutzung).

Outbound-Governance

  • Dedizierte Versand-Subdomänen pro Anwendungsfall/Dienstleister (z. B. txn.example.com, marketing.example.com).
  • Einheitliche DKIM-Selector-Konventionen und automatisierte Rotation.
  • DMARC-Durchsetzung auf allen Sende-Subdomänen; Non-Mail-Domänen per np=reject/sp=reject absichern.
  • Kontinuierliches Monitoring von rua/ruf-Reports; Anomalie-Erkennung (plötzliche Volumina, neue Quell-ASNs, erhöhte Fail-Raten).

Relevante Standards und RFCs

  • SPF: RFC 7208
  • DKIM: RFC 6376
  • DMARC: RFC 7489, RFC 8601 (Auth-Results)
  • MTA-STS: RFC 8461
  • TLS Reporting (TLS-RPT): RFC 8460
  • DANE for SMTP: RFC 7672
  • DNSSEC: RFC 4033–4035

Tags #EmailSecuritySPFDKIMDMARCDNSSECMTASTSDANEPhishingEvilginxGophishSWAKSBlueTeamMTAPostfixMicrosoft365GmailDeliverabilityThreatDetectionHeaderAnalysisCloudReputation

Gehacktes-Overview

Graph View