Email-Spoofing: Absender-Fälschung verhindern
Email-Spoofing ist die technische Fälschung des Absender-Feldes. Ohne SPF, DKIM und DMARC kann jeder Mailserver E-Mails mit Ihrer Domain im From-Feld versenden. Diese Seite erklärt den Angriff, dokumentiert Vorfälle und zeigt, wie die SPF/DKIM/DMARC-Trias Spoofing beendet.
Was ist Email-Spoofing?
Email-Spoofing ist die Fälschung der Absender-Adresse einer E-Mail. Das SMTP-Protokoll wurde 1982 ohne Absender-Authentifizierung entworfen — jeder Mailserver kann E-Mails mit beliebiger From-Adresse versenden. Solange die empfangende Domain weder SPF noch DKIM noch DMARC veröffentlicht hat, akzeptiert der Empfangs-Server die Nachricht und zeigt sie als legitim an. Spoofing ist die Vorbedingung für Phishing, BEC und CEO-Fraud — wer Authentifizierungs-Records vernachlässigt, lässt die häufigste Einbruchstür offen.
Das BSI führt Spoofing in seinem Glossar als eigenständigen Begriff und beschreibt es als Sammelbegriff für Identitäts-Vortäuschung im Netzwerk. Im MITRE ATT&CK-Framework gehört Email-Spoofing zur Initial-Access-Technik T1566 (Phishing). Wolf-Agents prüft Ihre Schutz-Trias im Email Security Check: Der Scanner liest SPF, DKIM-Selektoren und DMARC-Policy aus dem DNS, bewertet jeden Record zeichengenau und sagt Ihnen, ob ein Angreifer Ihre Domain aktuell direkt spoofen könnte.
Spoofing in einem Satz
Spoofing setzt voraus, dass die Empfänger-Seite die Authentizität des Absenders nicht prüft. SPF prüft den Envelope-From gegen autorisierte IPs, DKIM prüft eine kryptografische Signatur, DMARC prüft das Alignment zwischen Envelope-From und Header-From. Wer alle drei sauber konfiguriert hat, ist gegen direktes Domain-Spoofing geschützt.
Wie funktioniert ein Spoofing-Angriff?
Der Angreifer verbindet sich per SMTP mit dem empfangenden Mailserver, gibt eine beliebige MAIL FROM-Adresse an und setzt im DATA-Bereich einen gefälschten From-Header. Wenn die Empfänger-Domain keine Authentifizierung erzwingt, landet die Nachricht im Posteingang — visuell von einer echten Mail nicht zu unterscheiden. Der Mail-Client zeigt nur den Header-From, der Empfänger sieht eine vertrauenswürdige Absender-Adresse.
SMTP-Verbindung öffnen
Der Angreifer-Server verbindet sich auf Port 25 mit dem MX-Server der Empfänger-Domain. Keine Anmeldung nötig — Port 25 ist für Server-zu-Server-Kommunikation offen.
MAIL FROM mit gefälschter Domain
MAIL FROM: <ceo@ihre-firma.de> — der Angreifer gibt die zu fälschende Domain als Envelope-From an. Ohne SPF wird der Wert nicht geprüft.
DATA mit gefälschtem Header
Im Nachrichtenkörper setzt der Angreifer einen weiteren From: "CEO" <ceo@ihre-firma.de>. Dieser Header wird im Mail-Client angezeigt — der Empfänger sieht den echten Namen.
Zustellung ohne Validierung
Ohne DMARC-Policy gibt es keinen Reject-Trigger. Die Nachricht landet im Posteingang — mit der gefälschten Domain als sichtbarem Absender.
angreifer$ telnet mx.empfaenger-firma.de 25
220 mx.empfaenger-firma.de ESMTP Postfix
EHLO angreifer.example
250 mx.empfaenger-firma.de
MAIL FROM: <ceo@ihre-firma.de>
250 2.1.0 Ok
RCPT TO: <buchhaltung@empfaenger-firma.de>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
From: "CEO" <ceo@ihre-firma.de>
Subject: Dringende Überweisung
Bitte überweisen Sie heute noch 47.500 EUR an...
.
250 2.0.0 Ok: queuedDMARC-Triangle gegen Spoofing — SPF + DKIM + DMARC Trust-Architektur
Multimodales Trust-Triangle: 3 RFC-Ecken (SPF RFC 7208 oben / DKIM RFC 6376 links unten / DMARC RFC 7489 rechts unten) verbunden durch Alignment-Pfeile (aspf relaxed/strict + adkim relaxed/strict) zum Email-Zentrum. DMARC-Policy: p=none (Monitoring) → p=quarantine (Quarantäne) → p=reject (Block). Wiederverwendbar in spoofing/bec/vec/phishing/echospoofing-subdomailing.
Vorfälle 2023–2026: Vom Marketing-Spoof zum CEO-Fraud
Email-Spoofing ist seit Jahrzehnten dokumentiert. Der BSI-Lagebericht 2025 weist Email-basierte Angriffe als dominanten Initial-Access-Vektor aus. Verizon DBIR bestätigt diese Lage in den globalen Auswertungen seit Jahren. Die Bandbreite reicht von trivialen Marketing-Spoofs über CEO-Fraud bis zu hochentwickelten Nation-State-Kampagnen — was sie alle teilen, ist eine fehlende oder unzureichende SPF/DKIM/DMARC-Konfiguration auf Ziel-Seite.
SubdoMailing-Kampagne (Guardio Labs, Februar 2024)
Guardio Labs deckte eine breite Kampagne auf, bei der Angreifer dangling DNS-Records bekannter Marken übernahmen, um Millionen von Spam- und Phishing-Mails im Namen vertrauenswürdiger Domains zu versenden. Betroffen waren Marken aus Medien, Handel und Industrie. Quelle: Guardio Labs.
Echospoofing-Pattern (Proofpoint, 2024)
Proofpoint dokumentierte eine Multi-Mio-Mails-pro-Tag-Kampagne, die fehlkonfigurierte SPF-Records von Cloud-Tenants ausnutzte, um sich als Top-Marken auszugeben. Echospoofing ist eine Variante des klassischen Spoofings, die SPF-Pass-Status erreicht, weil Cloud-Provider als legitime Sender im SPF-Record stehen.
EFF STARTTLS-Downgrade-Studie (klassischer Spoofing-Begleiter)
Die Electronic Frontier Foundation dokumentierte ISPs in den USA und Thailand, die STARTTLS auf Netzwerkebene durch Header-Manipulation entfernten — der klassische Downgrade-Begleitangriff, der Spoofing-Schutz durch Verschlüsselung aushebelt. Quelle: EFF „ISPs Removing Their Customers' Email Encryption“.
PCI DSS v4.0 + Microsoft Reject — DMARC als Spoofing-Mindeststandard
Zwei regulatorische Verschiebungen 2025: PCI DSS v4.0 verlangt seit März 2025 DMARC für Organisationen, die Karten-Daten verarbeiten. Microsoft begann am 5. Mai 2025, nicht-konforme Mails von Hochvolumen-Sendern (≥ 5.000 Mails/Tag) an Outlook-/Hotmail-/Live-Empfänger mit SMTP-Status 550; 5.7.515 abzulehnen — SPF/DKIM/DMARC werden Pflicht. Spoofing-Schutz ohne DMARC ist damit nicht mehr Best Practice, sondern operativer Mindeststandard. Quellen: Proofpoint „From Best Practice to Must-Have“ Mai 2025 (PCI DSS-Teil) + Microsoft Tech Community „Outlook's New Requirements for High-Volume Senders“ (Microsoft-Reject-Teil). Der DMARC-Enforcement-Roadmap-Pfad ist die direkte Antwort.
Wie erkenne ich Spoofing in der Praxis?
Spoofing-Erkennung passiert auf zwei Ebenen: in der einzelnen verdächtigen E-Mail über den Email-Header und in der eigenen Domain-Konfiguration über externe Scans. Die Authentication-Results-Zeile im Header zeigt SPF-, DKIM- und DMARC-Status. Eine ehrliche Außenprüfung der eigenen Domain (z.B. mit dem Wolf-Agents Scanner) zeigt, ob Angreifer Sie aktuell direkt spoofen könnten.
Ad-hoc: Email-Header lesen
Authentication-Results:— zeigt SPF/DKIM/DMARC-ErgebnisReturn-Path:— sollte zur Header-From-Domain passenReceived:— zeigt die echte Versand-Infrastruktur (von unten nach oben gelesen)From:vs.Reply-To:— unterschiedliche Domains sind ein Warnsignal
Strukturell: DMARC-Reports
- Aggregat-Reports (rua) zeigen alle IPs, die für Ihre Domain senden
- Failure-Reports (ruf) liefern einzelne fehlgeschlagene Authentifizierungen
- Auswertung mit Tools wie Postmark DMARC, Valimail, Easydmarc
- Wolf-Agents-Monitoring prüft DMARC-Setup alle 6 Stunden + alarmiert bei Drift
Wolf-Agents-USP für Spoofing
Der Wolf-Agents Email Security Check bewertet die SPF/DKIM/DMARC-Trias mit zeichengenauer SPF-Lookup-Zählung (gegen RFC 7208-Limit 10), DKIM-Schlüssellängen-Prüfung (mindestens 2048 Bit), DMARC-Policy-Stufenbewertung (p=none/quarantine/reject) und Subdomain-Override-Drift-Erkennung. So sehen Sie auf einen Blick, wie ein Angreifer Ihre Domain heute spoofen könnte.
Wie schütze ich mich vor Spoofing?
Spoofing-Schutz folgt einer klaren Reihenfolge: SPF (Envelope-From-Authentifizierung), DKIM (kryptografische Signatur), DMARC (Policy + Reporting). Erst wenn alle drei sauber stehen, ist direktes Domain-Spoofing technisch unmöglich. Die R1-Kapitel des Wolf-Agents Ratgebers erklären jede Schicht mit Provider-Anleitungen, das R2-Kapitel DMARC-Enforcement führt vom Beobachtungs-Modus p=none zur durchsetzungsstarken p=reject-Policy.
SPF konfigurieren
SPF-Record (RFC 7208) definiert, welche IPs für Ihre Domain senden dürfen. Achten Sie auf das 10-Lookup-Limit, qualifier -all oder ~all und konsistente Include-Ketten. Wolf-Agents zählt Lookups zeichengenau und warnt bei Drift.
DKIM signieren
DKIM (RFC 6376) signiert jede E-Mail kryptografisch. Mindestens RSA 2048 Bit oder Ed25519. Der Empfänger verifiziert die Signatur per DNS-Lookup. Ohne den privaten Schlüssel kann kein Angreifer eine gültige Signatur erzeugen.
DMARC veröffentlichen
DMARC (RFC 7489) verbindet SPF und DKIM mit einer Policy. Starten Sie mit p=none für Sichtbarkeit, prüfen Sie 4–8 Wochen die Aggregat-Reports, bewegen Sie sich dann zu p=quarantine.
DMARC-Enforcement
Erst mit p=reject ist Spoofing technisch geblockt. Die DMARC-Enforcement-Roadmap führt Sie in vier Phasen sicher dorthin — mit Monitoring und Rollback-Option.
MTA-STS härten
MTA-STS verhindert STRIPTLS-Begleitangriffe, die Spoofing-Schutz durch Transport-Manipulation aushebeln. RFC 8461 spezifiziert das HSTS-Äquivalent für Email.
SMTP-TLS prüfen
SMTP-TLS sichert die Vertraulichkeit. Ein gültiges Zertifikat, mindestens TLS 1.2 und korrekter Hostname-Match sind die Basis für jede ernsthafte Transport-Sicherheit.
Erweiterte Schutz-Schichten (optional, über DMARC-Enforcement hinaus): Microsoft Defender for Office 365 Anti-Phishing Policies ergänzen die Authentifizierungs-Schicht um Spoof Intelligence, Impersonation Protection (User/Domain/Brand mit AI-Mailbox-Intelligence), Tenant Allow/Block Lists und „Honor-DMARC“-Aktionen separat für p=quarantine und p=reject. BIMI (Brand Indicators for Message Identification, AuthIndicators Working Group) macht eine erfolgreich authentifizierte Marken-Mail in der Empfänger-Inbox sichtbar — Voraussetzung: DMARC-Enforcement (mindestens p=quarantine) plus VMC-Zertifikat für Gmail/Apple (Yahoo unterstützt BIMI auch ohne VMC).
Was tun bei einem Spoofing-Vorfall?
Wenn Sie Spoofing Ihrer Domain feststellen, gilt: dokumentieren, eindämmen, kommunizieren. Sammeln Sie die kompletten Email-Header der gespooften Nachrichten, prüfen Sie Ihre eigene DMARC-Konfiguration auf Drift, und informieren Sie betroffene Empfänger. Bei NIS2-pflichtigen Unternehmen kann die 24-Stunden-Frühwarnpflicht greifen — beginnen Sie deshalb noch während des Vorfalls mit der Dokumentation.
- Vollständige Email-Header sammeln — Authentication-Results, Received-Header, Message-ID. Ohne Header keine Forensik.
- Eigene DMARC-Konfiguration prüfen — ist die Policy noch p=reject? Sind alle Aggregat-Adressen erreichbar? Wolf-Agents-Monitoring liefert die letzten 6 Stunden Snapshot.
- Aggregat-Reports auswerten — welche IP hat versendet? Wenn aus dem Cloud-Provider-Pool: SPF-Include genauer eingrenzen.
- Empfänger benachrichtigen — über bekannten, verifizierten Kanal (NICHT per E-Mail antworten, sondern Anruf oder Messenger).
- NIS2 Art. 23 prüfen — wenn der Vorfall „erheblich“ ist (Schadenshöhe, Anzahl Betroffener, Branche): 24h-Frühwarnung an die zuständige Behörde. In DE: BSI als zentrale Meldestelle.
- Konfigurations-Lessons — fehlte ein Subdomain-Override? War sp=reject korrekt gesetzt? Drift-Guards in den nächsten Scan einbauen.
Spoofing-Schutz nach NIS2, BSI und DSGVO
Email-Authentifizierung ist Compliance-Pflicht für viele Branchen. NIS2 Art. 21 Abs. 2 lit. h (Kryptografie) und lit. g (Cyberhygiene) verlangen technische Schutzmaßnahmen, BSI TR-03108 fordert SPF/DKIM/DMARC für sicheren Email-Transport, DSGVO Art. 32 macht technische Maßnahmen zur Pflicht für die Sicherheit personenbezogener Daten. Wer Spoofing-Schutz vernachlässigt, riskiert nicht nur den Vorfall — sondern auch die persönliche Haftung der Geschäftsleitung nach §38 BSIG.
NIS2 Art. 21 Abs. 2 lit. h
Kryptografie und Verschlüsselung. DKIM ist die kryptografische Signatur jeder Nachricht — ohne DKIM keine NIS2-Konformität für Email. Auch lit. g (Cyberhygiene + Schulung) ist relevant: SPF/DKIM/DMARC gehört zum Grundschutz, der jedem KMU-Mitarbeiter bewusst sein sollte.
BSI TR-03108
Die BSI Technische Richtlinie für sicheren Email-Transport fordert explizit SPF, DKIM und DMARC für authentifizierte Email-Zustellung. Sie ist die maßgebliche DACH-Referenz für Email-Sicherheit nach dem Stand der Technik.
DSGVO Art. 32
Technische Maßnahmen zum Schutz personenbezogener Daten. Wenn Spoofing Ihrer Domain zu einer Datenpanne führt (z.B. Phishing mit Daten-Diebstahl), greift Art. 33 (72h-Meldung) und ggf. Art. 34 (Benachrichtigung Betroffener).
Der Wolf-Agents Email Security Check bewertet alle drei Compliance-Säulen automatisch. Das Monitoring überwacht Ihre Konfiguration alle 6 Stunden und alarmiert bei Drift — der prüfbare Nachweis der Sorgfaltspflicht nach §38 BSIG.
Wie steht Ihre Domain bei Email-Spoofing?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.
Häufig gestellte Fragen
Was ist Email-Spoofing?
Email-Spoofing ist die Fälschung der Absender-Adresse einer E-Mail. Da das SMTP-Protokoll aus 1982 keine Authentifizierung des Absender-Feldes vorsieht, kann jeder Mailserver E-Mails mit beliebiger From-Adresse versenden. Ohne SPF, DKIM und DMARC akzeptiert der Empfangs-Server die Nachricht und zeigt sie als legitim an. Spoofing ist die technische Grundlage für Phishing, Business Email Compromise (BEC) und CEO-Fraud.
Wie funktioniert Email-Spoofing technisch?
Der Angreifer verbindet sich mit dem empfangenden Mailserver per SMTP, gibt eine beliebige MAIL FROM-Adresse an und setzt im DATA-Bereich einen beliebigen From-Header. Ohne SPF wird der Envelope-From nicht gegen autorisierte IPs geprüft. Ohne DKIM fehlt die kryptografische Signatur, die nur der echte Absender erzeugen kann. Ohne DMARC gibt es keine Policy, die festlegt, was mit nicht-authentifizierten Nachrichten passiert — sie landen einfach im Posteingang.
Welcher Unterschied besteht zwischen Envelope-From und Header-From?
Der Envelope-From (auch Return-Path oder MAIL FROM) wird im SMTP-Dialog übertragen und gegen SPF geprüft. Der Header-From wird im Mail-Client angezeigt und kann unabhängig vom Envelope-From gesetzt werden. Diese Trennung ist die Wurzel vieler Spoofing-Angriffe: Der Angreifer setzt einen legitimen Envelope-From (für SPF-Pass), aber einen gefälschten Header-From (für die Anzeige). DMARC schließt diese Lücke durch das Alignment-Konzept — beide Felder müssen zur selben Domain gehören.
Stoppen SPF, DKIM und DMARC alle Spoofing-Angriffe?
Sie stoppen direktes Domain-Spoofing — niemand kann mehr E-Mails mit Ihrer Domain im Header-From versenden, ohne dass die Empfänger eine Quarantäne- oder Reject-Behandlung sehen, sofern Sie DMARC mit p=reject veröffentlicht haben. Sie stoppen NICHT Look-Alike-Domains (z.B. mircosoft.com statt microsoft.com), Display-Name-Spoofing (legitime Domain, gefälschter Anzeigename) oder Übernahme-Spoofing über kompromittierte Konten. Dafür braucht es zusätzlich CT-Log-Monitoring, Display-Name-Filter und MFA.
Wie erkenne ich Spoofing-Versuche in der Praxis?
Prüfen Sie den vollständigen Email-Header: Authentication-Results-Zeile zeigt SPF-, DKIM- und DMARC-Status. Bei „spf=fail“ oder „dmarc=fail“ liegt ein Spoofing-Versuch vor. Der Return-Path sollte zur Header-From-Domain passen. Bei legitimen Absendern: Received-Header zeigt die echten Versand-Server. Der Wolf-Agents Email Security Check prüft Ihre eigene Domain in Sekunden — er zeigt, ob Angreifer Sie aktuell spoofen könnten.
Was meldet NIS2 bei einem Spoofing-Vorfall?
NIS2 Art. 23 verlangt eine 24-Stunden-Frühwarnung, 72-Stunden-Vorfallsmeldung und einen 1-Monats-Bericht, wenn ein erheblicher Sicherheitsvorfall vorliegt. Reines Spoofing einer Marketing-Mail ist meist kein meldepflichtiger Vorfall. Wird Spoofing aber Teil eines BEC-Angriffs mit signifikantem Schaden oder einer breit gestreuten Phishing-Welle gegen Ihre Kunden, wird die Meldepflicht relevant. Die Beweissicherung (Email-Header, Logfiles) ist Voraussetzung — beginnen Sie noch während des Vorfalls.
Wo bewertet der Wolf-Agents Scanner Spoofing-Schutz?
Im 165-Punkte-System: SPF (22 Punkte) prüft Lookup-Limit, Qualifier und Include-Ketten, DKIM (22 Punkte) bewertet Selektor-Erreichbarkeit und Schlüsselstärke, DMARC (35 Punkte) prüft Policy, Alignment-Modus, Reporting-Adressen und Subdomain-Policy. Zusammen erkennt der Scanner, ob ein Angreifer Sie aktuell direkt spoofen könnte oder ob die Schutz-Trias greift.