Email-Spoofing stoppen – SPF, DKIM und DMARC richtig nutzen

Eine Rechnung wirkt plausibel, der Absender passt zur eigenen Domain, und trotzdem ist die Mail betrügerisch. Genau dieses Muster steckt hinter vielen Business-E-Mail-Compromise- und Phishing-Fällen: Angreifer fälschen den sichtbaren Absender (From:) und hoffen, dass Empfänger oder Mail-Gateways nicht genau prüfen. Technisch heißt das Email-Spoofing (Absenderfälschung). Gegenmaßnahmen sind gut etabliert, scheitern in der Praxis aber oft an halbfertiger Konfiguration, fehlendem Monitoring oder einem zu strengen Rollout ohne Vorwarnung.

Warum Absenderfälschung trotz „korrekter“ Domain möglich ist

Das Kernproblem: Das sichtbare Absenderfeld einer E-Mail ist nicht automatisch an die Infrastruktur der Domain gebunden. Ohne zusätzliche Prüfmechanismen kann grundsätzlich jeder Mailserver eine Nachricht mit beliebigem From:-Wert verschicken. Empfänger-Mailsysteme entscheiden dann anhand von Heuristiken (Spam-Filter) und optionalen Authentifizierungsdaten, ob die Mail vertrauenswürdig ist.

Im Alltag führt das zu drei typischen Angriffsbildern:

• Domain-Spoofing: From: zeigt die echte Unternehmensdomain, die E-Mail kommt aber von fremder Infrastruktur.

• Lookalike-Domains: visuell ähnliche Domains (z. B. „firma-support.tld“ statt „firma.tld“) – technische Authentifizierung hilft hier nur indirekt, weil es eine andere Domain ist.

• „Display Name“-Tricks: Der Anzeigename im Mail-Client imitiert eine bekannte Person, die eigentliche Adresse wirkt unauffällig.

SPF, DKIM und DMARC adressieren primär die erste Kategorie: Sie helfen Empfängern zu erkennen, ob ein Absender zur Domain passt und wie im Fehlerfall zu handeln ist.

SPF: Welche Server dürfen für die Domain senden?

SPF (Sender Policy Framework) ist ein DNS-Eintrag, der festlegt, welche Mailserver berechtigt sind, E-Mails für eine Domain zu versenden. Empfänger prüfen dabei typischerweise die Domain aus dem Envelope-From (Return-Path), nicht zwingend die sichtbare From:-Adresse. Genau dieser Unterschied ist eine häufige Quelle für Missverständnisse.

Was SPF gut kann – und wo Grenzen liegen

SPF ist effektiv gegen einfache Spoofing-Versuche, wenn Angreifer direkt einen eigenen SMTP-Server nutzen. Grenzen entstehen in zwei Situationen:

• Weiterleitungen (Forwarding): Ein legitimer Mailserver leitet eine Nachricht weiter. Der weiterleitende Server steht oft nicht im SPF der ursprünglichen Domain, wodurch SPF beim Empfänger fehlschlagen kann.

• From/Return-Path-Alignment: Wenn sichtbarer From: und Envelope-From nicht „zusammenpassen“, kann SPF zwar bestehen, aber DMARC später trotzdem scheitern.

Praxis-Tipp: SPF klein und gepflegt halten

Ein sauberer SPF-Record enthält nur tatsächlich genutzte Versandsysteme: Provider für Postfächer, Newsletter-Tools, Ticket-Systeme, Monitoring-Tools. Jede zusätzliche Include-Kette vergrößert die Angriffsfläche und erhöht das Risiko, DNS-Lookup-Grenzen zu reißen. Änderungen sollten immer zusammen mit dem Mailbetrieb (z. B. Marketing-Tooling) abgestimmt werden, sonst blockiert eine „Sicherheits“-Änderung plötzlich legitime Transaktionsmails.

DKIM: Integrität und Absenderbindung per Signatur

DKIM (DomainKeys Identified Mail) ergänzt SPF: Der sendende Mailserver signiert ausgewählte Header und den Body kryptografisch. Der öffentliche Schlüssel liegt im DNS. Empfänger prüfen damit, ob die Mail unterwegs unverändert blieb und ob die Domain aus der DKIM-Signatur plausibel ist.

Warum DKIM in der Praxis oft der stabilere Baustein ist

DKIM ist weniger anfällig für Weiterleitungen, weil eine Weiterleitung die DKIM-Signatur grundsätzlich bestehen lassen kann, sofern die Nachricht nicht verändert wird. Genau dort liegt aber auch eine typische Fehlerquelle: Manche Systeme fügen Footer, Tracking-Header oder Disclaimer hinzu und brechen dadurch Signaturen, wenn nicht korrekt kanonisiert (canonicalization) oder passend signiert wird.

Ein robustes Setup setzt daher auf:

• Signieren der relevanten Header (From, To, Subject, Date) und sinnvoller weiterer Felder.

• Schlüssellängen, die zum eingesetzten System passen, sowie geregelte Rotation (Schlüsselwechsel ohne Downtime).

• Klare Zuständigkeit: Wer betreibt DKIM für welche Sender? Häufig senden mehrere Systeme im Namen einer Domain.

Typische DKIM-Fallen im Unternehmen

In gemischten Umgebungen (Microsoft 365, Mailgateway, Newsletter-Provider, CRM) entstehen DKIM-Probleme meist nicht durch Kryptografie, sondern durch Prozesse:

• Ein neues SaaS-Tool versendet Mails, aber DKIM ist nicht aktiviert oder nicht auf die Root-Domain ausgerichtet.

• Ein Gateway „normalisiert“ Header oder fügt Inhalte hinzu und beschädigt Signaturen.

• Mehrere DKIM-Selectoren existieren, aber DNS ist veraltet oder falsch delegiert.

DMARC: Policy, Alignment und verwertbare Reports

DMARC (Domain-based Message Authentication, Reporting & Conformance) verbindet SPF und DKIM zu einer überprüfbaren Regel: Empfänger sollen nicht nur prüfen, ob SPF/DKIM „irgendwie“ passt, sondern ob diese Ergebnisse zur sichtbaren Absenderdomain (From:) ausgerichtet sind (Alignment). Zusätzlich liefert DMARC Berichte, die sichtbar machen, wer im Namen der Domain sendet.

DMARC-Logik verständlich gemacht

DMARC bewertet vereinfacht:

• Besteht SPF oder DKIM?

• Ist das Ergebnis aligned zur From:-Domain?

• Welche Policy ist gesetzt (none/quarantine/reject)?

Damit wird ein klassischer Fehler sichtbar: SPF kann für eine Subdomain oder einen technischen Return-Path bestehen, während der sichtbare From:-Absender die Hauptdomain ist. Ohne Alignment bringt „SPF=pass“ im Ergebnis wenig.

Warum DMARC-Reporting ein Sicherheitsinstrument ist

Die Reports zeigen, welche Systeme weltweit E-Mails mit der Domain als Absender verschicken und ob diese Authentifizierung korrekt ist. Damit lassen sich Schatten-IT (unbekannte Newsletter-Tools), Fehlkonfigurationen nach Providerwechseln oder missbräuchliche Nutzung schneller erkennen. In der Praxis ist das oft der Schritt, der „unsichtbare“ Probleme ans Licht bringt, bevor eine harte Policy echte Geschäftsmails blockiert.

Ein sicherer Rollout ohne Mail-Ausfälle

Eine strikte DMARC-Policy schützt am besten, aber ein unkontrollierter Wechsel auf „reject“ kann legitime Mails verwerfen. Besser ist ein gestufter Ansatz: erst beobachten, dann schrittweise durchsetzen, dabei alle Sender sauber erfassen und korrigieren.

Umsetzbare Schritte für eine saubere Einführung

• Alle legitimen Sender inventarisieren: Postfach-Provider, Newsletter, Ticket-System, Monitoring, Multifunktionsdrucker, Anwendungen.

• SPF konsolidieren: Nur notwendige Includes, keine „wildwüchsigen“ Einträge.

• DKIM pro Sender aktivieren und testen; bei Gateways prüfen, ob Inhalte nach dem Signieren verändert werden.

• DMARC zunächst mit Policy „none“ ausrollen und Berichte auswerten.

• Nach Korrekturen schrittweise auf „quarantine“ erhöhen; erst danach „reject“ setzen, wenn legitime Quellen stabil bestehen.

• Ausnahmen vermeiden: Statt „irgendwie erlauben“ besser Sender technisch korrekt anbinden (Alignment erreichen).

Fehlersuche: Wenn legitime Mails abgelehnt werden

Wenn Empfänger Mails zurückweisen oder in Quarantäne verschieben, sind die Ursachen meist systematisch. Wichtig ist, nicht nur auf „SPF fail“ zu reagieren, sondern das Zusammenspiel mit DKIM und DMARC zu prüfen.

Häufige Ursachen und schnelle Gegenmaßnahmen

Für die Analyse sind Mail-Header entscheidend: „Authentication-Results“ zeigt, wie der Empfänger SPF/DKIM/DMARC bewertet hat. In Supportfällen sollte immer ein vollständiger Header mitgeliefert werden, nicht nur ein Screenshot aus dem Mail-Client.

Grenzen der Technik: Was SPF/DKIM/DMARC nicht lösen

Auch ein perfektes Setup verhindert nicht jede Form von Betrug. Drei realistische Lücken bleiben:

• Lookalike-Domains: Eine andere Domain kann korrekt authentifizieren und trotzdem täuschend ähnlich aussehen. Hier helfen Awareness, klare Kommunikationsregeln und Mail-Gateway-Regeln für ähnliche Domains.

• Kompromittierte Konten: Wenn Angreifer echte Postfächer übernehmen, sind SPF/DKIM/DMARC „korrekt“, weil der Versand legitim ist. Hier sind starke Anmelde- und Geräteschutzmaßnahmen entscheidend, z. B. über sicher genutzte MFA und gehärtete Endpoints.

• Interne Weiterleitungen und Mail-Flows: Komplexe Routing-Ketten (Cloud, Gateway, Archiv, DLP) können Authentifizierung unbeabsichtigt brechen, wenn die Reihenfolge „Signieren → Verändern → Weiterleiten“ nicht sauber geplant ist.

Einbettung in den Gesamtschutz: Mail ist nur ein Angriffsvektor

Absenderauthentifizierung reduziert Spoofing deutlich, ersetzt aber keine ganzheitliche E-Mail-Sicherheit. Sinnvoll ist die Kombination mit pragmatischen Schutzmaßnahmen:

• Klare Freigabeprozesse für Zahlungsanweisungen (Vier-Augen-Prinzip, Rückruf über bekannte Nummern).

• Technische Härtung von Konten und Clients, z. B. durch zentrale Richtlinien und Schutzfunktionen in der Mail-Plattform.

• Regelmäßige Überprüfung von Änderungen an DNS und Mail-Flows, insbesondere nach Tool-Einführungen.

• Incident-Readiness: Wenn ein Absender missbraucht wird, müssen DNS-Zugänge, Registrar-Konten und Mail-Admins schnell handlungsfähig sein.

Für angrenzende Themen, die in vielen Umgebungen direkt mit Mail-Sicherheit zusammenhängen, bieten sich diese Vertiefungen an: Microsoft 365 absichern und Phishing stoppen.

Entscheidungshilfe für typische Szenarien

• Nur wenige Systeme senden Mails (z. B. Mailprovider + Newsletter)

  • SPF strikt pflegen, DKIM für alle Sender aktivieren, DMARC zügig von „none“ zu „quarantine“ entwickeln.

• Viele Absenderquellen (CRM, Tickets, Scanner, Anwendungen)

  • Zuerst Inventarisierung und Reporting etablieren, dann Alignment pro Quelle herstellen, erst danach Policy verschärfen.

• Häufige Weiterleitungen (Partner, Shared Mailboxes, Aliase)

  • DKIM priorisieren, Mail-Flows prüfen, Weiterleitungswege minimieren; DMARC-Policy schrittweise erhöhen und mit Monitoring begleiten.