E-Mail-Authentifizierung erklärt: SPF, DKIM und DMARC für Verteidiger

E-Mail bleibt der wichtigste Übertragungsweg für Phishing, Business E-Mail Compromise und Malware, und fast alles davon beruht auf einer einzigen Schwäche: Die From:-Adresse, die ein Empfänger sieht, lässt sich trivial fälschen, sofern man nicht die richtigen Authentifizierungseinträge veröffentlicht. Dieser Artikel richtet sich an das Blue Team. Er erklärt SPF, DKIM und DMARC rein aus der Verteidigungsperspektive — was jede Kontrolle beweist, wie die drei ineinandergreifen, wie man die erzeugte Telemetrie liest und wie man die Domain zu einer erzwingenden Richtlinie bringt, ohne legitime Post zu blockieren.

Warum E-Mail-Spoofing standardmäßig so einfach ist#

SMTP wurde in einer Zeit gegenseitigen Vertrauens entworfen und besitzt keine eingebaute Identitätsprüfung. Jede Nachricht hat zwei Absenderidentitäten: den Envelope-Absender (das MAIL FROM der SMTP-Transaktion, auch Return-Path genannt) und das Header-From, das E-Mail-Programme tatsächlich anzeigen. Ein Angreifer kann beide beliebig setzen, und in der Praxis sieht ein normaler Empfänger nur das Header-From, nie den Envelope-Absender. Ohne Authentifizierungseinträge hat ein empfangender Server keine kryptografische oder richtlinienbasierte Grundlage, eine Nachricht abzulehnen, die vorgibt, von Ihrer Domain zu stammen. Genau diese Lücke nutzen Angreifer für Phishing und Rechnungsbetrug aus, weil eine gefälschte Absenderadresse Vertrauen erzeugt, das das Opfer sonst erst verdienen müsste. Die folgenden drei Standards schaffen diese fehlende Grundlage und decken jeweils eine andere Teillücke ab; erst zusammen ergeben sie einen belastbaren Schutz.

SPF: Autorisierung der sendenden Infrastruktur#

Sender Policy Framework (SPF) ist ein DNS-TXT-Eintrag, der auflistet, welche IP-Adressen und Hosts mit Ihrer Domain im Envelope-Absender senden dürfen. Ein Empfänger schlägt v=spf1 ... für die Envelope-Domain nach und prüft, ob die verbindende IP autorisiert ist. Der Eintrag endet mit einem all-Mechanismus: -all bedeutet Hard Fail (nicht Gelistetes ablehnen), ~all Soft Fail (annehmen, aber markieren), und +all ist gefährlich und darf nie verwendet werden. SPF hat zwei wichtige Grenzen: Es prüft den Envelope-Absender, nicht das sichtbare Header-From, und es bricht bei Weiterleitung, weil der Weiterleiter zur neuen verbindenden IP wird. Zudem gilt eine Obergrenze von zehn DNS-Abfragen, sodass ausufernde include:-Ketten einen Eintrag still in permerror treiben können.

DKIM: kryptografische Signatur der Nachricht#

DomainKeys Identified Mail (DKIM) hängt eine digitale Signatur an ausgehende Nachrichten. Ihre Mail-Plattform signiert ausgewählte Header und den Nachrichtentext mit einem privaten Schlüssel; der passende öffentliche Schlüssel liegt im DNS unter selector._domainkey.ihredomain. Ein Empfänger berechnet den Hash neu und prüft die Signatur, was beweist, dass der signierte Inhalt unterwegs nicht verändert wurde und mit einem Schlüssel Ihrer Domain signiert wurde. Da die Signatur in der Nachricht selbst reist, übersteht DKIM die meisten Weiterleitungen, anders als SPF. Rotieren Sie Selektoren regelmäßig, nutzen Sie mindestens 2048-Bit-Schlüssel und ziehen Sie alte Selektoren zurück, damit ein geleakter historischer Schlüssel nicht missbraucht werden kann.

DMARC: Alignment, Richtlinie und Reporting#

DMARC verbindet SPF und DKIM mit dem Header-From, das Nutzer tatsächlich sehen, über ein Konzept namens Alignment. Eine Nachricht besteht DMARC, wenn sie SPF besteht und die SPF-Domain zum From ausgerichtet ist, oder wenn sie DKIM besteht und die DKIM-Domain ausgerichtet ist — nur eines ist nötig. Die DMARC-Richtlinie ist ein DNS-TXT-Eintrag unter _dmarc.ihredomain mit der Policy p=none (nur beobachten), p=quarantine (in den Spam) oder p=reject (ablehnen). Entscheidend: DMARC fordert auch Berichte an — aggregierte XML-Berichte über rua= und, wo angeboten, forensische Muster über ruf=. Diese Berichte sind Ihre primäre Erkennungstelemetrie.

Die Angriffsfläche, die diese Kontrollen adressieren#

Zu verstehen, wogegen man sich verteidigt, hilft beim Feintuning der Richtlinie. Exact-Domain-Spoofing fälscht Ihre eigene Domain im From und ist genau das, was DMARC im Enforcement stoppt. Cousin- oder Look-alike-Domains (Registrierung eines optisch ähnlichen Namens) sind von Ihrem DMARC-Eintrag nicht abgedeckt und erfordern Markenüberwachung und Nutzersensibilisierung. Anzeigename-Imitation behält eine legitime Adresse im Envelope, setzt aber einen irreführenden Anzeigenamen, was die Authentifizierung nicht erkennen kann und clientseitige Warnungen braucht. Das Kennen dieser Grenzen verhindert falsche Sicherheit, sobald DMARC auf Reject steht.

Erkennung: DMARC-Aggregatberichte lesen#

Aggregat-Berichte (RUA) kommen täglich als XML von jedem Empfänger und fassen Nachrichtenzahlen gruppiert nach Quell-IP, SPF-Ergebnis, DKIM-Ergebnis und DMARC-Disposition zusammen. Speisen Sie sie in einen Parser oder ein gehostetes Dashboard, statt rohes XML zu lesen. Achten Sie auf drei Signale: unbekannte sendende IPs, die für Ihre Domain bestehen oder scheitern (ein Marketing-Tool, von dem niemand wusste, oder ein Angreifer), legitime Quellen, die das Alignment verfehlen (ein Dienst, der mit der falschen Domain signiert), und Volumenspitzen zu Reject, die auf eine aktive Spoofing-Kampagne hindeuten können. Indizieren Sie in Gateway und SIEM den Authentication-Results-Header, um dmarc=fail, dkim=fail und spf=softfail abzufragen und Imitationen Ihrer Führungskräfte zu alarmieren.

Erkennung: Header- und Log-Signale#

Über DMARC-Berichte hinaus sollten Verteidiger normale Authentifizierungsergebnisse als Baseline erfassen. In Microsoft 365 legen Nachrichtenverlauf und der compauth-Wert zusammengesetzte Authentifizierungsentscheidungen offen; in Google Workspace zeigen die BigQuery-E-Mail-Logs und das Security Investigation Tool die SPF/DKIM/DMARC-Urteile. Erstellen Sie Erkennungen für eingehende Post, die DMARC scheitert, aber vorgibt, von einer internen oder Partnerdomain zu stammen, für das plötzliche Auftauchen eines neuen Selektors in Ihrem eigenen DNS, den Sie nicht angelegt haben, und für ausgehende Post von Ihrer Domain, die externe Empfänger als scheiternd melden — Letzteres ist oft das erste Zeichen, dass ein Schatten-IT-System oder ein kompromittiertes Konto in Ihrem Namen sendet.

Mitigation und Härtung: Ausrollen bis zum Enforcement#

Rollen Sie in Stufen aus, um echte Post nicht zu verwerfen. Inventarisieren Sie zuerst jeden legitimen Absender — Ihre Mail-Plattform, Marketing-Tools, Ticketsysteme, CRM und Lohnabrechnung. Veröffentlichen Sie einen korrekten SPF-Eintrag mit -all und bleiben Sie unter dem Zehn-Abfragen-Limit, indem Sie ungenutzte Includes flatten oder entfernen. Aktivieren Sie DKIM-Signierung auf jeder Quelle mit 2048-Bit-Schlüsseln und eindeutigen Selektoren. Veröffentlichen Sie dann p=none mit rua= und sammeln Sie einige Wochen Berichte, bis jeder legitime Strom bestehendes Alignment zeigt. Gehen Sie zu p=quarantine mit niedrigem pct über und steigern Sie auf 100, dann schließlich zu p=reject. Setzen Sie sp=reject für Subdomains und erwägen Sie einen Null-MX plus DMARC-Reject für nicht sendende Domains, damit diese nicht missbraucht werden.

Ergänzende Kontrollen: MTA-STS, TLS-RPT und BIMI#

Authentifizierung beantwortet wer hat gesendet; Transportsicherheit beantwortet wurde es privat zugestellt. MTA-STS lässt Ihre Domain TLS für eingehendes SMTP verlangen und Downgrade-Angriffe abwehren, und TLS-RPT meldet Zustellfehler. BIMI zeigt ein verifiziertes Markenlogo, aber erst, wenn Sie im DMARC-Enforcement sind, was es zu einem nützlichen Anreiz macht, den Rollout abzuschließen. Keines davon ersetzt DMARC; sie härten die umgebenden Schichten. Behandeln Sie sie als zweite Welle, sobald Ihre Enforcement-Richtlinie stabil ist.

Häufige Fallstricke#

Die häufigsten Fehler sind selbstverschuldet. Das Veröffentlichen von zwei SPF-Einträgen verursacht einen Permerror und macht SPF völlig ungültig — es darf nur einen geben. Das Überschreiten der zehn DNS-Abfragen bricht SPF für große Ökosysteme still. Der direkte Sprung zu p=reject ohne Beobachtungsphase verschluckt zuverlässig legitime Post eines vergessenen Absenders. Das Vergessen der Subdomain-Richtlinie lässt marketing.ihredomain fälschbar, selbst wenn die übergeordnete Domain gesichert ist. Und ~all mit Enforcement gleichzusetzen ist ein Fehler: Soft Fail plus p=none stoppt nichts. Verlassen Sie sich schließlich nie auf verfügbare ruf-Berichte — viele Empfänger senden sie aus Datenschutzgründen nicht mehr, also bauen Sie Ihre Erkennung auf Aggregatdaten.

Härtungscheckliste#

Nutzen Sie dies als Schnellaudit. 1. Genau ein SPF-Eintrag pro Domain, endend auf -all, unter zehn Abfragen. 2. DKIM auf jeder sendenden Quelle aktiviert, 2048-Bit-Schlüssel, Selektoren rotiert und alte zurückgezogen. 3. DMARC auf p=reject mit sp=reject und rua in ein überwachtes Postfach oder eine Plattform. 4. Geparkte und nicht sendende Domains mit SPF -all und DMARC-Reject gesperrt. 5. Eingangs-Gateway indiziert Authentication-Results und alarmiert bei Führungskräfte-Imitation und internen DMARC-Fehlern. 6. MTA-STS im Enforce-Modus und TLS-RPT veröffentlicht. 7. Überwachung markenähnlicher Domains und Nutzertraining für Anzeigenamen- und Look-alike-Angriffe, die Authentifizierung nicht stoppen kann.

FAQ: Stoppt DMARC auf Reject jegliches Phishing?#

Nein, und das zu glauben ist gefährlich. DMARC auf Reject verhindert, dass Angreifer Ihre exakte Domain im Header-From fälschen, was ein großer und wertvoller Gewinn ist, weil es Ihre Marke und Ihre eigenen Nutzer vor intern wirkenden Spoofs schützt. Gegen Look-alike-Domains, Anzeigenamen-Tricks, kompromittierte legitime Konten oder Phishing von unbeteiligten Domains bewirkt es nichts. Kombinieren Sie Enforcement mit Eingangsfilterung, Linkschutz, Nutzermeldungen und Sensibilisierung, damit die verbleibenden Techniken weiter erkannt werden.

FAQ: Bricht Enforcement Weiterleitung und Mailinglisten?#

Es kann, weshalb DKIM wichtig ist. SPF bricht bei einfacher Weiterleitung, weil der Weiterleiter eine neue Quell-IP ist, aber eine gültige DKIM-Signatur übersteht sie meist, sodass ein ausgerichtetes DKIM-Bestehen die Nachricht DMARC-konform hält. Mailinglisten, die Betreff oder Text ändern, können DKIM brechen; gut konfigurierte Listen mildern dies mit ARC (Authenticated Received Chain), womit ein vertrauenswürdiger Vermittler die ursprüngliche Authentifizierung bezeugt. Überwachen Sie Ihre Aggregatberichte während des Rollouts auf weiterleitungsbedingte Fehler, um bekannte gute Vermittler vor dem Reject freizuschalten.

Fazit#

SPF, DKIM und DMARC sind keine drei konkurrierenden Optionen; sie sind drei Schichten, die nur kombiniert und bis zum Enforcement getrieben Schutz bieten. SPF autorisiert Infrastruktur, DKIM beweist Integrität, und DMARC bindet beides an das sichtbare From und liefert das Reporting, das E-Mail-Authentifizierung in eine Erkennungsfähigkeit verwandelt. Das Verteidigungs-Playbook ist geradlinig: Absender inventarisieren, korrekte Einträge veröffentlichen, Aggregatberichte überwachen, bis jeder legitime Strom ausgerichtet ist, dann mit Subdomain-Abdeckung auf Reject steigern. Behandeln Sie diesen Rollout nicht als einmaliges Projekt, sondern als dauerhaften Prozess: Neue Marketing-Werkzeuge, ein Wechsel des Zahlungsdienstleisters oder eine übernommene Tochtergesellschaft bringen jederzeit neue sendende Quellen ins Spiel, die in den Aggregatberichten auftauchen und geprüft werden müssen. Tun Sie das, legen Sie MTA-STS und Überwachung darüber, und Sie schließen die einfachste Tür, die Angreifer nutzen, um Ihre Organisation zu imitieren.