10 Schwachstellen im E-Mail-Filter: die subtilen Header-Signale, die dein Gateway verpasst

⚡TL;DR

• E-Mail-Gateways blockieren offensichtlichen Spam, übersehen aber ausgeklügelte Angriffe, die subtile Header-Schwachstellen ausnutzen
• 10 präzise Header-Indikatoren verraten bösartige E-Mails: Envelope-Abweichung, Drittanbieter-DKIM, abweichendes Reply-To, ungewöhnliche Received-Kette und sechs weitere technische Signale
• Jeder Indikator wird aus der Perspektive des Angreifers (wie er ihn ausnutzt) und des Verteidigers (wie man ihn erkennt) analysiert
• Die Header-Analyse nach dem Gateway ist die letzte Verteidigungslinie für das 1 % der E-Mails, das alle Filter passiert

Dein E-Mail-Gateway zeigt eine Blockierungsrate von 99,5 %. Der Monatsbericht sieht beruhigend aus, die Dashboards stehen auf Grün, und dein Sicherheitsteam wendet sich dem nächsten Thema zu. Das Problem versteckt sich in den verbleibenden 0,5 %. Bei einem Volumen von 200.000 E-Mails pro Monat sind das 1.000 ungefilterte Nachrichten. Darunter genügt eine einzige Spear-Phishing-E-Mail an den richtigen Mitarbeiter, um ein privilegiertes Konto zu kompromittieren, Daten abzugreifen oder einen Ransomware-Angriff auszulösen. Die durchschnittlichen Kosten einer durch Phishing initiierten Sicherheitsverletzung betragen 4,8 Millionen Dollar (IBM, Cost of a Data Breach 2025), und die durchschnittliche Zeit bis zur Erkennung einer Phishing-Kompromittierung liegt bei 207 Tagen (IBM, 2025). Laut Verizon DBIR 2025 beträgt die mediane Zeit zwischen dem Empfang einer Phishing-E-Mail und dem ersten Klick 21 Sekunden. Deine Nutzer denken nicht nach: sie reagieren.

Secure Email Gateways (SEGs) wie Proofpoint, Mimecast, Barracuda oder Microsoft Defender for Office 365 analysieren Inhalte, IP-Reputation, bekannte Signaturen und verhaltensbasierte Heuristiken. Aber sie teilen einen gemeinsamen blinden Fleck: subtile Signale in SMTP- und MIME-Headern, die ausgeklügelte Angreifer manipulieren, um Filter zu umgehen, ohne einen Alarm auszulösen. Die Zahlen sind eindeutig: Gateways übersehen 30 bis 50 % der fortgeschrittenen Bedrohungen, und das Volumen bösartiger E-Mails, die SEGs umgehen, ist in einem Jahr um 105 % gestiegen, was bedeutet, dass alle 19 Sekunden eine bösartige E-Mail die Filter passiert (Cofense, Annual State of Email Security 2026). Wenig überraschend erklären 91 % der Sicherheitsverantwortlichen, dass sie mit der Leistung ihres SEG frustriert sind (Egress, Email Security Risk Report 2024). Das ist kein theoretisches Problem. 2025 nutzte die Gruppe Tycoon2FA Schwachstellen im MX-Routing und der E-Mail-Authentifizierung aus, um 13 Millionen bösartige E-Mails in einem einzigen Monat zu generieren und die Gateways Tausender Organisationen zu umgehen. Insgesamt haben 78 % der Organisationen in den letzten 12 Monaten mindestens eine E-Mail-Sicherheitsverletzung erlitten (Barracuda, 2025).

Dieser Artikel analysiert 10 präzise Indikatoren in E-Mail-Headern, die die meisten Gateways ignorieren oder unterbewerten. Für jeden Indikator werden die Perspektive des Angreifers (wie er ihn ausnutzt) und die des Verteidigers (wie man ihn erkennt) mit konkreten Header-Beispielen detailliert dargestellt. Wenn du Security Engineer, SOC-Analyst, E-Mail-Administrator oder CISO bist, sollten diese 10 Signale Teil deiner Post-Gateway-Analyse-Checkliste sein.

Warum E-Mail-Filter nicht ausreichen

Was Gateways prüfen (und was sie ignorieren)

Moderne E-Mail-Gateways basieren auf mehreren Filterschichten. Die IP-Reputation prüft, ob die Adresse des sendenden Servers auf Blocklisten steht (Spamhaus, Barracuda, SpamCop). Die Inhaltsanalyse sucht nach verdächtigen Schlüsselwörtern, bösartigen URLs und gefährlichen Anhängen. Anti-Malware-Signaturen vergleichen Dateien mit bekannten Definitionsdatenbanken. Verhaltensbasierte Heuristiken erkennen Massen-Mailing-Muster und statistische Anomalien.

Diese Architektur funktioniert gegen Massen-Spam und generische Phishing-Kampagnen. Ein Server mit einer IP auf einer Blockliste, eine E-Mail mit dem Inhalt "Klicke hier, um deinen Gewinn abzuholen" und ein .exe-Anhang werden blockiert, bevor sie das Postfach erreichen. Die Blockierungsrate von 99 % ist real für diese Art von Bedrohungen.

Aber die Angreifer, die deine Organisation ins Visier nehmen, tun nichts davon. Sie senden von sauberen IPs (gemietet bei legitimen ESPs), verfassen glaubwürdige Nachrichten und manipulieren SMTP-Header, damit die Nachricht wie eine legitime E-Mail aussieht. Bemerkenswert: 82,6 % der analysierten Phishing-E-Mails nutzen mittlerweile irgendeine Form von KI für die Textgestaltung (KnowBe4, Phishing Threat Trends 2025), und die Klickrate bei KI-generierten Phishing-E-Mails erreicht 54 %, gegenüber 12 % bei manuell verfassten (Brightside AI, 2025). Darüber hinaus enthalten 76,4 % der Phishing-Angriffe mindestens ein polymorphes Merkmal, was bedeutet, dass jede gesendete E-Mail leicht unterschiedlich ist, um statischen Signaturen zu entgehen (KnowBe4, 2025). Das Gateway sieht eine E-Mail, die alle Standardkriterien "besteht", und lässt sie durch.

Was Gateways weitgehend ignorieren, sind Konsistenzsignale in den Headern. Eine legitime E-Mail weist interne Konsistenz auf: Die From-Domain stimmt mit den Domains in Return-Path und Message-ID überein, die DKIM-Signatur deckt die richtige Domain ab, die Received-Kette ist logisch, und die proprietären Header der Hosting-Plattform sind vorhanden. Wenn ein Angreifer eine E-Mail fälscht, repliziert er die sichtbaren Header (From, Subject, Date), hinterlässt aber Inkonsistenzen in den technischen Headern, die nur eine gründliche Untersuchung aufdeckt. Gateways führen diese Untersuchung nicht durch.

Das Paradox der Anpassung

Je strenger ein Filter ist, desto mehr passt sich der Angreifer an. Fortgeschrittene Bedrohungsgruppen (APTs, gezielte Spear-Phishing-Operationen) testen ihre E-Mails systematisch gegen die marktführenden Gateways, bevor sie eine Kampagne starten. Untergrundservices bieten "SEG-Testing" an: Der Angreifer reicht seine E-Mail ein und erhält einen Bericht, der angibt, welche Gateways sie blockieren und welche sie durchlassen. Es ist ein iterativer Prozess. Der Angreifer passt Header, Inhalt und Sendeinfrastruktur an, bis eine zufriedenstellende Durchlassrate erreicht ist.

Das Ergebnis: Die E-Mails, die nach dem Gateway im Postfach landen, sind keine gescheiterten Versuche. Es sind die ausgefeiltesten Versuche, optimiert, um genau deine spezifischen Abwehrmechanismen zu umgehen. Das ist ein verbreiteter kognitiver Bias bei Sicherheitsteams: anzunehmen, dass was das Gateway passiert, "wahrscheinlich legitim" ist. In Wirklichkeit ist es genau umgekehrt. Was das Gateway nach strenger Filterung passiert, ist potenziell gefährlicher als durchschnittlicher Spam, weil es dafür konzipiert wurde, durchzukommen.

Dieses Phänomen erklärt, warum Nutzer, die trainiert wurden, die visuellen Anzeichen von Phishing zu erkennen, weiterhin darauf hereinfallen. Die E-Mails, die das Gateway umgehen, enthalten keine Tippfehler, schlampigen Layouts oder offensichtlichen URLs mehr. Sie sehen wie legitime E-Mails aus, weil sie dafür optimiert wurden. Der einzige Unterschied liegt in den technischen Headern, unsichtbar für den Endnutzer.

Die letzte Verteidigungslinie: Post-Gateway-Analyse

Deshalb ist die Header-Analyse nach der Filterung entscheidend. Die 10 in diesem Artikel detailliert beschriebenen Indikatoren ersetzen das Gateway nicht: Sie ergänzen die Erkennung, indem sie Signale untersuchen, die automatisierte Filter nicht oder nur unzureichend prüfen. Diese Analyse kann manuell (für einzelne Vorfälle), halbautomatisiert (Exchange-/Gmail-Transportregeln) oder in ein SIEM für die Erkennung im großen Maßstab integriert sein.

Die 10 Indikatoren, die dein Gateway verpasst

1. Return-Path-/From-Abweichung (Envelope-Mismatch)

Wie der Angreifer es ausnutzt. Das SMTP-Protokoll trennt zwei verschiedene Identitäten: den Envelope-Absender (MAIL FROM, sichtbar im Return-Path-Header) und den angezeigten Absender (From-Header). Der Angreifer konfiguriert seinen Server so, dass er mit einem Return-Path sendet, den er kontrolliert (bounce@angreifer-infra.net), während er einen glaubwürdigen From anzeigt (direction@captaindns.com). Die meisten E-Mail-Clients zeigen nur den From an. Der Empfänger sieht eine E-Mail, die scheinbar von der Geschäftsleitung kommt, ohne zu ahnen, dass der Envelope woanders hinzeigt.

Warum Filter es übersehen. Gateways prüfen SPF auf den Return-Path und DKIM auf den From, aber nur wenige vergleichen aktiv beide und warnen bei einer Abweichung. Ein SPF-Pass auf dem Return-Path und ein DKIM-Pass auf einer Drittanbieter-Domain reichen oft aus, um die Nachricht durchzulassen.

Was der Verteidiger prüfen sollte. Vergleiche die Domain im Return-Path mit der Domain im From. Wenn sie ohne legitimen Grund (Mailingliste, konfigurierter ESP) voneinander abweichen, ist das ein starkes Signal.

Header-Beispiel:

Return-Path: <bounce-7842@angreifer-infra.net>
From: "Geschäftsleitung" <direction@captaindns.com>

Die Abweichung ist sofort sichtbar: Der Envelope kommt von angreifer-infra.net, der From zeigt captaindns.com. Eine legitime E-Mail, die über einen ESP gesendet wird, hätte einen Return-Path mit der Domain des ESP, konfiguriert im SPF der Absenderdomain, nicht eine unbekannte Drittanbieter-Domain.

Wann die Abweichung legitim ist. Es ist normal, dass der Return-Path in bestimmten Fällen vom From abweicht: ESPs (SendGrid, Mailgun, Amazon SES) verwenden ihre eigene Domain für den Return-Path, um Bounces zu verwalten. Mailinglisten schreiben den Return-Path um. Der Schlüssel ist zu prüfen, ob die Domain des Return-Path einem bekannten, im SPF der From-Domain konfigurierten Dienst gehört. Ein Return-Path zu einer unbekannten Domain (angreifer-infra.net) gepaart mit einem Unternehmens-From (captaindns.com) ohne SPF-Verbindung ist ein starkes Signal.

2. DKIM signiert von einer Drittanbieter-Domain (delegierte Signatur)

Wie der Angreifer es ausnutzt. Der Angreifer erstellt ein Konto bei einem legitimen ESP (SendGrid, Mailgun, Amazon SES) und konfiguriert DKIM für seine eigene Domain. Er sendet dann eine E-Mail mit einem gefälschten From (buchhaltung@captaindns.com). Die Nachricht trägt eine gültige DKIM-Signatur, aber signiert von der Domain des Angreifers (d=angreifer-marketing.com), nicht von captaindns.com. Das Gateway sieht "dkim=pass" und betrachtet die Nachricht als authentifiziert.

Warum Filter es übersehen. Gateways verifizieren, dass die DKIM-Signatur technisch gültig ist (der öffentliche Schlüssel stimmt überein, der Body-Hash ist korrekt). Aber die meisten prüfen nicht, ob die signierende Domain (d=) mit der From-Domain übereinstimmt. Das ist die Aufgabe des DMARC-Alignments, und viele Organisationen haben DMARC noch nicht im strikten Modus eingesetzt.

Was der Verteidiger prüfen sollte. Im DKIM-Signature-Header das Feld d= mit der From-Domain vergleichen. Wenn sie nicht übereinstimmen, ist die E-Mail von einem Dritten signiert, der keine Berechtigung über die angezeigte Domain hat.

Header-Beispiel:

DKIM-Signature: v=1; a=rsa-sha256; d=angreifer-marketing.com;
    s=sel2026; c=relaxed/relaxed;
    h=from:to:subject:date:message-id;
    bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
    b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...
From: "Buchhaltung" <buchhaltung@captaindns.com>

Das d=angreifer-marketing.com stimmt nicht mit dem From captaindns.com überein. Die Signatur ist technisch gültig, aber das Alignment ist gebrochen.

3. SPF-Pass bei gleichzeitigem DMARC-Alignment-Fehler

Wie der Angreifer es ausnutzt. Der Angreifer sendet von einem Server, dessen IP vom SPF einer von ihm kontrollierten Domain autorisiert ist (seine eigene Domain oder eine ESP-Domain). Der MAIL FROM (Envelope) verwendet diese autorisierte Domain, was einen SPF-Pass ergibt. Aber der From (Header) zeigt die Domain des Ziels (hr@captaindns.com). SPF besteht, DKIM fehlt oder ist von einer anderen Domain signiert, und DMARC scheitert am Alignment. Wenn die Zieldomain eine DMARC-Policy von p=none hat, wird keine Aktion ausgeführt. Und diese Lücke ist massiv: 84,2 % der analysierten Phishing-Angriffe bestehen die DMARC-Prüfungen (Egress, Email Security Risk Report 2024), größtenteils weil 47 % der E-Mail-Domains überhaupt keine DMARC-Konfiguration haben (Barracuda, 2025), 63 % der Implementierer bei p=none bleiben (Mailgun/Email on Acid, 2025) und nur 4 % der Domains p=reject durchsetzen (Valimail, 2025).

Warum Filter es übersehen. Das Gateway sieht spf=pass in den Authentifizierungsergebnissen und vergibt einen positiven Score. Die Tatsache, dass das DMARC-Alignment scheitert, wird oft untergewichtet, wenn die Policy p=none ist. Das Nettoergebnis: Die Nachricht passiert die Filterung mit einem "akzeptablen Authentifizierungs-Score".

Was der Verteidiger prüfen sollte. Im Authentication-Results-Header nach der Kombination spf=pass mit dmarc=fail suchen. Diese Kombination zeigt an, dass SPF auf einer anderen Domain als der From-Domain bestanden hat, ein klassisches Zeichen für Spoofing.

Header-Beispiel:

Authentication-Results: mx.captaindns.com;
    spf=pass (sender IP is 198.51.100.42)
        smtp.mailfrom=bounces.angreifer-esp.com;
    dkim=none;
    dmarc=fail (p=none dis=none) header.from=captaindns.com

Der spf=pass bezieht sich auf angreifer-esp.com (Envelope), nicht auf captaindns.com (From). DMARC scheitert, weil kein Mechanismus (SPF oder DKIM) mit der From-Domain aligned ist. Die Policy p=none lässt die Nachricht durch.

4. Reply-To zeigt auf eine andere Domain als From

Wie der Angreifer es ausnutzt. Der Angreifer fälscht einen glaubwürdigen From (support@captaindns.com), fügt aber ein Reply-To ein, das auf eine von ihm kontrollierte Adresse zeigt (support-captaindns@protonmail.com oder support@captaindns-helpdesk.com). Wenn der Empfänger antwortet, geht seine Antwort an den Angreifer. Das ist eine äußerst effektive Technik für BEC (Business Email Compromise), die über zehn Jahre kumulierte Verluste von 55,5 Milliarden Dollar verursacht hat (FBI IC3, 2024). Die erste E-Mail enthält weder Link noch Anhang, was jede Erkennung durch Inhaltsanalyse umgeht.

Warum Filter es übersehen. Das Reply-To ist ein informativer Header, kein Authentifizierungsmechanismus. Gateways vergleichen in der Regel die Domain des Reply-To nicht mit der des From. Eine E-Mail ohne verdächtige URL oder Anhang, mit einem SPF-Pass und sauberem Textinhalt, passiert die Filter problemlos.

Was der Verteidiger prüfen sollte. Die Domain des Reply-To-Headers mit der des From vergleichen. Eine Abweichung zu einer kostenlosen Domain (Gmail, ProtonMail, Outlook.com) oder einer ähnlich klingenden Domain (Typosquatting) ist ein starkes BEC-Signal.

Header-Beispiel:

From: "Jean Dupont - CFO" <jean.dupont@captaindns.com>
Reply-To: jean.dupont.captaindns@protonmail.com
Subject: Dringende Überweisung - Lieferantenrechnung

Der From zeigt eine glaubwürdige interne Adresse. Das Reply-To leitet auf ein ProtonMail-Konto um, das der Angreifer kontrolliert. Wenn der Empfänger antwortet, ohne zu prüfen, wird das Gespräch mit dem Angreifer fortgesetzt.

Fortgeschrittene Varianten. Die ausgeklügeltsten Angreifer verwenden keine offensichtliche kostenlose Domain. Sie registrieren eine Typosquatting-Domain, die der Zieldomain ähnelt: captaindns-support.com, captaindns.net, captaindnss.com. Diese Domains sind bei einem schnellen Blick auf das Reply-To schwerer zu erkennen. Eine weitere Variante nutzt eine täuschende Subdomain: captaindns.service-desk.com (die eigentliche Domain ist service-desk.com, nicht captaindns). Für die automatisierte Erkennung pflegst du eine Allowlist autorisierter Reply-To-Domains und markierst alles, was nicht darauf steht.

5. Ungewöhnlich kurze oder lange Received-Kette

Wie der Angreifer es ausnutzt. Jeder Server, der eine E-Mail verarbeitet, fügt einen Received-Header oben im Stapel hinzu. Eine legitime E-Mail durchläuft typischerweise 3 bis 5 Hops (Server des Absenders, ausgehendes Gateway, MX des Empfängers, eingehendes Gateway, Postfachserver). Der Angreifer kann diese Kette auf zwei Arten manipulieren. Erste Option: direkt von einem Skript an den MX des Empfängers senden, was eine Kette mit nur 1 oder 2 Hops erzeugt, ein Zeichen für nicht standardmäßiges Senden. Zweite Option: gefälschte Received-Header einfügen, um einen Transit über legitime Server vorzutäuschen und die Kette künstlich zu verlängern.

Warum Filter es übersehen. Gateways zählen nicht systematisch die Anzahl der Hops und prüfen nicht die zeitliche Konsistenz zwischen den Received-Headern. Eine E-Mail mit 8 Hops, von denen 3 gefälscht sind, besteht die Standardprüfungen, wenn die gefälschten Header gut formatiert sind.

Was der Verteidiger prüfen sollte. Die Received-Header zählen und zwei Dinge überprüfen. Erstens die zeitliche Konsistenz: Die Zeitstempel müssen von unten (erster Hop) nach oben (letzter Hop) fortschreiten. Ein Zeitsprung (ein Hop, der vor dem vorherigen datiert ist) weist auf einen gefälschten Header hin. Zweitens die Anzahl der Hops: weniger als 2 oder mehr als 7 ist für eine Standard-Geschäfts-E-Mail ungewöhnlich.

Header-Beispiel (verdächtige Kette, zu kurz):

Received: from mail-gw.captaindns.com (10.0.1.5) by mailbox.captaindns.com;
    Thu, 27 Mar 2026 09:15:22 +0100
Received: from unknown (HELO send-node-14.angreifer.net) (45.77.200.18)
    by mail-gw.captaindns.com; Thu, 27 Mar 2026 09:15:20 +0100

Nur 2 Hops. Kein ausgehender Server, kein Gateway des Absenders. Die Nachricht wurde direkt von einem Sendeknoten an den MX von captaindns.com gesendet, ein Zeichen für skriptbasiertes Senden, nicht für einen Unternehmens-Mailserver.

Die Technik der gefälschten Received-Header. Ein ausgeklügelterer Angreifer fügt gefälschte Received-Header ein, um einen Transit über legitime Server vorzutäuschen. Er fügt beispielsweise einen Hop Received: from mail-out.captaindns.com (10.0.1.2) by gateway.captaindns.com unten im Stapel hinzu. Die Falle: Empfangsserver fügen Received-Header oben im Stapel hinzu, nicht unten. Die Header unten sind die ältesten und wurden zuerst hinzugefügt. Ein Received-Header, der behauptet, von einem internen Server zu stammen, sich aber unten im Stapel befindet (vor dem ersten legitimen Hop), ist ein vom Absender gefälschter Header. Prüfe immer die Konsistenz der Kette, beginnend von unten.

6. Fehlendes TLS beim ersten Hop (STARTTLS abwesend)

Wie der Angreifer es ausnutzt. Der Angreifer nutzt einen Server ohne TLS-Unterstützung oder deaktiviert STARTTLS absichtlich. Das Ziel ist nicht die Verschlüsselung selbst, sondern was ihr Fehlen verrät. Ein legitimer Mailserver im Jahr 2026 unterstützt STARTTLS. Ein Server, der im Klartext sendet, ist wahrscheinlich ein Skript, ein Angriffstool oder ein kompromittierter Server. Das Fehlen von TLS kann auch auf einen SMTP-Downgrade-Angriff hindeuten, bei dem ein Angreifer die TLS-Aushandlung abfängt, um die Übertragung im Klartext zu erzwingen.

Warum Filter es übersehen. Gateways blockieren keine E-Mails, die ohne TLS empfangen werden. Das SMTP-Protokoll ist für den Klartext-Betrieb konzipiert, wobei TLS eine optionale Erweiterung ist. Viele Gateways akzeptieren unverschlüsselte Verbindungen, um keine legitime Post von älteren Servern zu verlieren. Ob der erste Hop im Klartext stattfindet, ist kein Standard-Filterkriterium.

Was der Verteidiger prüfen sollte. Im ersten Received-Header (dem untersten im Stapel) nach dem Hinweis with ESMTPS (TLS-Verbindung) versus with SMTP oder with ESMTP (Klartext-Verbindung) suchen. Eine geschäftliche E-Mail im Jahr 2026 sollte immer mit aktiviertem TLS beim ersten Hop übertragen werden.

Header-Beispiel:

Received: from send-node.angreifer.net (45.77.200.18)
    by mail-gw.captaindns.com with SMTP;
    Thu, 27 Mar 2026 09:15:20 +0100

Der Hinweis with SMTP (ohne das S von ESMTPS) zeigt eine Klartext-Verbindung an. Ein legitimer Unternehmens-Mailserver hätte with ESMTPS oder with TLS. Dieses Fehlen der Verschlüsselung ist ein schwaches, aber signifikantes Signal in Kombination mit anderen Indikatoren.

7. Verdächtiger X-Mailer oder User-Agent

Wie der Angreifer es ausnutzt. E-Mail-Clients und Server fügen einen X-Mailer- oder User-Agent-Header ein, der die verwendete Software identifiziert. Angreifer verwenden Python-Skripte (smtplib- oder aiosmtplib-Bibliotheken), Massen-Mailing-Tools (GoPhish, King Phisher, Social Engineering Toolkit) oder eigene Frameworks. Manche Angreifer lassen diesen Header weg (was bereits ein Signal ist), andere fälschen ihn, um einen legitimen Client zu imitieren (Outlook, Thunderbird). Fälschungen sind oft unvollkommen: eine nicht existierende Version, ein inkonsistentes String-Format oder ein X-Mailer, der nicht zu den anderen vorhandenen Headern passt.

Warum Filter es übersehen. Der X-Mailer ist kein von den RFCs standardisierter Header. Gateways behandeln ihn nicht als Sicherheitskriterium und pflegen keine Signaturdatenbank bösartiger Clients. Eine E-Mail, die von GoPhish mit einem gefälschten X-Mailer Microsoft Outlook 16.0 gesendet wird, passiert die Filter, wenn Inhalt und IP-Reputation sauber sind.

Was der Verteidiger prüfen sollte. Den X-Mailer- oder User-Agent-Header suchen. Ein Python-User-Agent (Python/3.11 aiosmtplib/2.0) ist ein starkes Signal. Das völlige Fehlen eines X-Mailers bei einer E-Mail, die angeblich von Outlook stammt, ist verdächtig. Eine Outlook-Version, die nicht existiert (zum Beispiel Microsoft Outlook 17.5, wenn die neueste Version 16.x ist), verrät eine Fälschung.

Header-Beispiel:

X-Mailer: Python/3.11 aiosmtplib/2.0.1
From: "IT-Support" <it-support@captaindns.com>
Subject: Obligatorische Passwort-Aktualisierung

Eine "Passwort-Aktualisierung"-E-Mail, gesendet von einem Python-Skript. Keine legitime IT-Abteilung sendet kritische E-Mails über ein Python-Skript mit aiosmtplib. Dieser Header verrät ein Angriffstool oder einen internen Phishing-Test.

8. Message-ID mit inkonsistenter Domain

Wie der Angreifer es ausnutzt. Der Message-ID-Header ist ein eindeutiger Identifikator, der vom sendenden Server generiert wird. Er enthält typischerweise einen Hash oder eine zufällige Kennung, gefolgt von der Domain des Servers, der ihn erzeugt hat. Der Angreifer, der den From @captaindns.com fälscht, aber von seinem eigenen Server sendet, generiert eine Message-ID mit seiner eigenen Domain oder einer generischen Kennung. Diese Diskrepanz zwischen der From-Domain und der Domain in der Message-ID offenbart die tatsächliche Infrastruktur des Angreifers.

Warum Filter es übersehen. Die Message-ID wird für Konversationsverkettung und Deduplizierung verwendet, nicht für Sicherheit. Gateways vergleichen die Message-ID-Domain nicht mit der From-Domain. Es ist ein technischer Header, den wenige Filtersysteme unter dem Aspekt der Konsistenz analysieren.

Was der Verteidiger prüfen sollte. Die Domain nach dem @ in der Message-ID extrahieren und mit der From-Domain vergleichen. Eine Abweichung zeigt an, dass die Nachricht von einem Server generiert wurde, der nicht zur angezeigten Domain gehört.

Header-Beispiel:

Message-ID: <a3f8e2c1-9b47-4d6e-b5a2-1c7d3e9f0482@vps-node-14.angreifer.net>
From: "Personalabteilung" <hr@captaindns.com>

Die Message-ID verrät den tatsächlichen Server: vps-node-14.angreifer.net. Eine legitime E-Mail von captaindns.com hätte eine Message-ID mit captaindns.com oder der Domain des genutzten ESP (zum Beispiel amazonses.com, wenn die Organisation Amazon SES verwendet).

9. Fehlende X-MS-Exchange- oder X-Google-Header

Wie der Angreifer es ausnutzt. Große E-Mail-Plattformen fügen spezifische proprietäre Header ein. Microsoft 365 fügt X-MS-Exchange-Organization-AuthSource, X-MS-Exchange-Organization-AuthAs, X-MS-Has-Attach, X-MS-TNEF-Correlator und andere hinzu. Gmail fügt X-Gm-Message-State, X-Google-DKIM-Signature, X-Google-Smtp-Source hinzu. Wenn eine E-Mail behauptet, von einer auf Microsoft 365 gehosteten Domain zu kommen, aber keinen dieser Header enthält, hat sie nicht die Microsoft-Plattform durchlaufen. Der Angreifer, der den From @captaindns.com (eine auf M365 gehostete Domain) fälscht, aber von seinem eigenen Server sendet, kann diese proprietären Header nicht glaubwürdig reproduzieren.

Warum Filter es übersehen. Drittanbieter-Gateways (nicht Microsoft, nicht Google) kennen nicht die Liste der erwarteten proprietären Header für jede Plattform. Selbst integrierte Gateways (Defender, Gmail) prüfen nicht systematisch die Konsistenz zwischen der From-Domain und dem Vorhandensein der erwarteten Header der Hosting-Plattform.

Was der Verteidiger prüfen sollte. Die Hosting-Plattform der From-Domain identifizieren (M365, Google Workspace, andere). Prüfen, ob die entsprechenden proprietären Header vorhanden sind. Eine E-Mail @captaindns.com (gehostet auf M365) ohne jeglichen X-MS-Exchange-*-Header hat Microsoft 365 nicht durchlaufen.

Header-Beispiel (verdächtige E-Mail, From M365, aber ohne Exchange-Header):

From: "Finanzabteilung" <cfo@captaindns.com>
To: buchhaltung@captaindns.com
Subject: Dringende Freigabe - internationale Überweisung
Date: Thu, 27 Mar 2026 09:15:00 +0100
Message-ID: <random-id@send-node.angreifer.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8

Kein X-MS-Exchange-*-Header, kein X-MS-Has-Attach, kein X-OriginatorOrg. Wenn captaindns.com auf Microsoft 365 gehostet wird, hat diese E-Mail die Plattform nicht durchlaufen. Es handelt sich um eine Fälschung, die von einem externen Server gesendet wurde.

10. Multipart Content-Type mit eingebettetem .html-Anhang

Wie der Angreifer es ausnutzt. Der Angreifer kapselt eine HTML-Seite zum Abfangen von Anmeldedaten (Credential Harvesting) im MIME-Body der Nachricht ein. Anders als ein klassischer Anhang (.exe, .zip), der Alarme auslöst, wird eine .html-Datei von Gateways oft als harmlos betrachtet. Wenn der Nutzer den HTML-Anhang öffnet, lädt sein Browser eine gefälschte Anmeldeseite, die Microsoft 365, Google Workspace oder einen anderen Dienst imitiert. Die eingegebenen Anmeldedaten werden an den Server des Angreifers gesendet. Die HTML-Seite kann vollständig offline funktionieren (kein Download externer Ressourcen), was die Erkennung durch Sandboxes erschwert.

Warum Filter es übersehen. HTML-Dateien sind keine ausführbaren Dateien und enthalten keinen bösartigen Code im traditionellen Sinne (kein Shellcode, keine Makros). Gateways, die Anhänge analysieren, konzentrieren sich auf Hochrisiko-Formate (.exe, .docm, .xlsm, .js, .vbs). Eine HTML-Datei ist statischer Webinhalt, und viele Filter lassen sie durch. Einige Gateways analysieren URLs im HTML, aber wenn die Seite offline mit eingebettetem JavaScript funktioniert, gibt es zum Zeitpunkt der Zustellung keine URL zum Blockieren.

Was der Verteidiger prüfen sollte. In den MIME-Headern nach einem Teil mit Content-Type: text/html und Content-Disposition: attachment suchen. Die Kombination HTML + Anhang ist ein starkes Signal. Den Inhalt der HTML-Datei analysieren: Das Vorhandensein von <form>-, <input type="password">-Tags oder obfuskiertem JavaScript in einem HTML-Anhang ist fast sicher bösartig.

Header-Beispiel:

Content-Type: multipart/mixed;
    boundary="----=_NextPart_001_0042_01D8F3A2.B5C7E890"

------=_NextPart_001_0042_01D8F3A2.B5C7E890
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hallo, bitte pr=C3=BCfen Sie das beigef=C3=BCgte Sicherheitsdokument.

------=_NextPart_001_0042_01D8F3A2.B5C7E890
Content-Type: text/html; name="security-update-captaindns.html"
Content-Disposition: attachment; filename="security-update-captaindns.html"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIGh0bWw+DQo8aHRtbD4NCjxoZWFkPjx0aXRsZT5DYXB0YWluRE5T...

Die MIME-Boundary enthält einen Anhang security-update-captaindns.html. Der base64-kodierte Body dekodiert zu einer HTML-Seite mit einem Anmeldeformular. Eine legitime E-Mail von CaptainDNS würde niemals eine HTML-Datei als Anhang für ein "Sicherheitsupdate" senden.

Evasion-Techniken im eingebetteten HTML. Angreifer verwenden mehrere Techniken, um Sandboxes zu umgehen, die HTML-Anhänge analysieren. JavaScript kann obfuskiert sein (Base64-Kodierung, String-Konkatenation, dynamische Code-Ausführung). Die Seite kann prüfen, ob sie in einem echten Browser läuft (Erkennung der Bildschirmauflösung, Mausbewegung, Plugins) und das Phishing-Formular nur auslösen, wenn die Bedingungen erfüllt sind. Einige HTML-Seiten verwenden das data:-Protokoll oder Blob-URLs, um das Formular dynamisch zu erstellen, was statische Analyse unwirksam macht. 2025 und 2026 sind .svg-Anhänge mit eingebettetem JavaScript zu einer immer häufigeren Variante dieser Technik geworden, da SVGs noch weniger überwacht werden als HTML-Dateien.

Indikatoren kombinieren: die Stärke des Multi-Signal-Scorings

Einzeln betrachtet kann jeder Indikator eine legitime Erklärung haben. Ein Return-Path, der vom From abweicht, ist normal, wenn ein ESP im Auftrag einer Organisation sendet. Ein DKIM, das von einer Drittanbieter-Domain signiert ist, ist Standard bei SendGrid oder Amazon SES. Eine kurze Received-Kette kann von einem On-Premise-Server stammen, der direkt sendet.

Die Stärke dieser 10 Indikatoren zeigt sich, wenn du sie kombinierst. Eine E-Mail mit einem einzigen Indikator verdient eine Überprüfung. Eine E-Mail mit drei oder mehr Indikatoren ist fast sicher bösartig. Das Prinzip ist Multi-Signal-Scoring: Jedem erkannten Indikator einen Score zuweisen und eskalieren, wenn der kumulative Score einen Schwellenwert überschreitet.

Scoring-Beispiel für eine verdächtige E-Mail:

Erkannter Indikator	Score
Return-Path != From (unbekannte Domain)	+2
DKIM signiert von einer Nicht-ESP-Drittanbieter-Domain	+2
SPF-Pass + DMARC-Fail	+3
Reply-To zeigt auf kostenlose Domain	+3
Received-Kette < 3 Hops	+1
Fehlendes TLS beim ersten Hop	+1
X-Mailer Python/Skript	+2
Message-ID-Domain != From	+2
Fehlende X-MS-Exchange-Header (M365-Domain)	+3
HTML-Anhang	+2

Ein Schwellenwert von 5 Punkten löst eine Markierung für SOC-Review aus. Ein Schwellenwert von 8 Punkten löst eine automatische Quarantäne aus. Dieses Scoring kann in Exchange-/Gmail-Transportregeln oder in einem SIEM implementiert werden.

In der Praxis kombinieren ausgeklügelte Spear-Phishing-E-Mails typischerweise 3 bis 5 Indikatoren. Die Indikatoren 1 (Return-Path-Abweichung), 3 (SPF-Pass + DMARC-Fail) und 8 (inkonsistente Message-ID) treten in der Mehrzahl der Domain-Spoofing-Fälle zusammen auf. Die Indikatoren 4 (abweichendes Reply-To) und 9 (fehlende proprietäre Header) kennzeichnen BEC-Angriffe (Business Email Compromise). Die Kombination 5 (kurze Received-Kette) + 6 (fehlendes TLS) + 7 (Skript-X-Mailer) verrät einen Versand über ein Angriffstool.

Die Lektion ist klar: Beurteile eine E-Mail nie anhand eines einzelnen Indikators. Erstelle ein Multi-Signal-Scoring-System, das an deine Umgebung angepasst ist, und kalibriere die Schwellenwerte, indem du deine legitimen E-Mails und vergangenen Vorfälle analysierst.

Wie du diese Signale nach dem Gateway erkennst

Manuelle Analyse mit einem Inspektionstool

Für einzelne Vorfälle (ein Nutzer meldet eine verdächtige E-Mail) bleibt die manuelle Header-Analyse die schnellste Methode. Der Nutzer exportiert die Roh-Header aus seinem E-Mail-Client (in Outlook: Datei > Eigenschaften > Internetkopfzeilen; in Gmail: drei Punkte > Original anzeigen). Der SOC-Analyst fügt die Header in ein Analysetool ein, das jeden Header aufschlüsselt und Anomalien hervorhebt.

Prioritäre Prüfpunkte bei der manuellen Analyse:

1. Return-Path vs From: identische Domains oder eine legitime Begründung für die Abweichung?
2. DKIM d= vs From: deckt die Signatur die richtige Domain ab?
3. Authentication-Results: Kombination spf=pass + dmarc=fail?
4. Reply-To: Domain konsistent mit dem From?
5. Received-Kette: Anzahl der Hops, zeitliche Konsistenz, TLS-Vorhandensein?
6. Message-ID: Domain konsistent mit dem From?
7. Proprietäre Header: vorhanden, wenn die Domain auf M365/Gmail gehostet wird?
8. MIME-Teile: verdächtiger HTML-Anhang?

Exchange-/Gmail-Transportregeln für automatisches Tagging

Für eine systematische Erkennung ermöglichen Transportregeln (Mail-Flow-Rules) in Exchange Online oder Routing-Regeln in Google Workspace das automatische Markieren von Nachrichten, die bestimmte Indikatoren aufweisen.

Exchange-Online-Regelbeispiel zur Erkennung der Reply-To-Abweichung:

Bedingung: Der Reply-To-Header enthält eine Domain, die sich von der From-Domain unterscheidet, UND die Reply-To-Domain steht nicht auf einer Allowlist (interne Domains, autorisierte ESPs). Aktion: Ein Warnbanner zur Nachricht hinzufügen ("Diese Nachricht hat eine Reply-To-Adresse, die vom angezeigten Absender abweicht") und zur SOC-Review markieren.

Regelbeispiel zur Erkennung fehlender M365-Header:

Bedingung: Die From-Domain ist eine interne Domain, die auf M365 gehostet wird, UND der Header X-MS-Exchange-Organization-AuthSource fehlt. Aktion: Zur manuellen Überprüfung in Quarantäne stellen.

Diese Regeln ersetzen das Gateway nicht, sondern fügen eine Post-Filtering-Erkennungsschicht hinzu, die auf Signale abzielt, die das Gateway ignoriert.

SIEM-Integration für Erkennung im großen Maßstab

Für Organisationen mit erheblichem E-Mail-Volumen ermöglicht die Integration mit einem SIEM (Microsoft Sentinel, Splunk, Elastic Security) automatisierte Erkennung und Korrelation. Exchange- oder Gmail-Transportlogs enthalten Authentifizierungsergebnisse, Schlüssel-Header und Routing-Metadaten. Benutzerdefinierte Erkennungsregeln suchen nach folgenden Mustern:

• Ungewöhnliches Volumen von E-Mails mit dmarc=fail action=none für eine interne Domain
• Eingehende E-Mails mit Reply-To auf kostenlose Domains, wenn der From eine interne Domain ist
• Nachrichten ohne X-MS-Exchange-*-Header, wenn die From-Domain auf M365 gehostet wird
• HTML-Anhänge in eingehenden E-Mails mit einem internen From

Die SIEM-Korrelation ermöglicht auch die Querverknüpfung einer verdächtigen E-Mail mit Netzwerkverbindungen: Wenn ein Nutzer um 09:15 einen HTML-Anhang öffnet und um 09:18 eine verdächtige M365-Verbindung von einer ausländischen IP erscheint, wird der Vorfall nahezu in Echtzeit erkannt.

Der Zusammenhang mit Zustellbarkeit und Spam

Die 10 in diesem Artikel beschriebenen Indikatoren betreffen nicht nur die Sicherheit. Sie beeinflussen auch die Zustellbarkeit deiner eigenen E-Mails. Wenn deine Domain die gleichen Signale wie eine Phishing-E-Mail aufweist (inkonsistenter Return-Path, nicht ausgerichtetes DKIM, DMARC auf p=none), werden die Gateways der Empfänger deine Nachrichten mit Misstrauen behandeln. Deine legitimen E-Mails landen im Spam, weil deine DNS-Konfiguration und Header die gleichen Signale auslösen, die Angreifer ausnutzen.

Deine eigenen Header zu korrigieren (SPF und DKIM ausrichten, DMARC auf p=reject umstellen, konsistente Message-IDs konfigurieren) bietet daher einen doppelten Vorteil: die Sicherheit deiner Domain gegen Spoofing stärken UND die Zustellbarkeit deiner legitimen E-Mails verbessern. Es ist dasselbe Analyseraster, angewandt auf zwei sich ergänzende Ziele.

Aktionsplan

1. Die letzten 50 verdächtigen E-Mails auditieren: Rufe die Header der E-Mails ab, die deine Nutzer im letzten Monat gemeldet haben, und analysiere sie anhand der 10 Indikatoren. Dieses Audit deckt die Arten von Angriffen auf, die dein Gateway umgehen.
2. Transportregeln für die Indikatoren 1, 4 und 5 erstellen: Die Return-Path/From-Abweichung, das abweichende Reply-To und die ungewöhnliche Received-Kette sind die drei am einfachsten automatisch über Exchange- oder Gmail-Regeln zu erkennenden Signale.
3. DMARC auf p=quarantine oder p=reject verstärken: Solange deine DMARC-Policy p=none ist, bleiben die Indikatoren 1, 2 und 3 ohne Konsequenz für den Angreifer ausnutzbar. Zur Erinnerung: Nur 4 % der Domains setzen p=reject durch (Valimail, 2025): Jede Domain, die migriert, reduziert die Angriffsfläche für das gesamte Ökosystem. Nutze unser DMARC-Prüftool (Link im Banner oben), um deine aktuelle Policy zu auditieren.
4. SOC-Teams in Header-Warnsignalen schulen: Geschulte Mitarbeiter melden viermal mehr Bedrohungen als ungeschulte, nämlich 21 % gegenüber 5 % (Verizon DBIR, 2025). Die 10 Indikatoren in diesem Artikel sollten Teil des Standard-Verfahrens zur Analyse von E-Mail-Vorfällen sein. Erstelle eine druckbare Checkliste, die Analysten bei jeder Untersuchung konsultieren.
5. Header-Analyse in den Incident-Response-Prozess integrieren: Organisationen, die KI in ihre Sicherheitspipeline integrieren, reduzieren den Breach-Zyklus um 80 Tage und sparen durchschnittlich 1,9 Millionen Dollar pro Vorfall (IBM, Cost of a Data Breach 2025). Jede gemeldete verdächtige E-Mail sollte eine systematische Post-Gateway-Analyse durchlaufen, bevor sie als False Positive eingestuft wird.
6. Monatlich mit Test-E-Mails erneut testen: Sende dir selbst E-Mails, die jeden der 10 Indikatoren reproduzieren. Wenn dein Gateway sie durchlässt und deine Transportregeln sie nicht markieren, haben deine Abwehrmechanismen einen blinden Fleck.

FAQ

Warum erkennt mein E-Mail-Gateway diese Signale nicht?

Gateways sind für Massenfilterung optimiert: IP-Reputation, verdächtige Inhalte, Malware-Signaturen. Die 10 hier beschriebenen Indikatoren betreffen die Header-Konsistenz, einen Bereich, den Gateways nicht tiefgehend analysieren. Die Return-Path/From-Abweichung oder das Fehlen proprietärer Header sind keine Standard-Filterkriterien in den meisten SEGs auf dem Markt.

Welche E-Mail-Filter sind am anfälligsten für diese Umgehungen?

Gateways, die sich ausschließlich auf IP-Reputation und Inhaltsanalyse konzentrieren, sind am anfälligsten. Lösungen, die Verhaltensanalyse und DMARC-Alignment-Verifizierung integrieren, sind besser aufgestellt, aber kein Gateway auf dem Markt prüft alle 10 Indikatoren erschöpfend. Deshalb bleibt die Post-Gateway-Analyse notwendig.

Wie erstelle ich eine Exchange-Transportregel zur Erkennung der Reply-To-Abweichung?

Erstelle im Exchange Admin Center eine Mail-Flow-Regel mit der Bedingung "Ein Nachrichtenheader enthält" auf dem Reply-To-Header. Kombiniere mit der Bedingung "Die Absenderdomain ist", um interne Domains zu erfassen. Die empfohlene Aktion ist, dem Empfänger eine sichtbare Warnung hinzuzufügen und die Nachricht für SOC-Review zu markieren. Teste zwei Wochen im Auditmodus, bevor du die Blockierung aktivierst.

Kann die Header-Analyse automatisiert werden?

Ja. Authentifizierungsergebnisse und Schlüssel-Header sind in den Transportlogs von Exchange Online und Gmail verfügbar. Ein SIEM (Sentinel, Splunk, Elastic) kann diese Logs aufnehmen und Erkennungsregeln für die 10 Indikatoren anwenden. Für Organisationen ohne SIEM bieten Exchange-/Gmail-Transportregeln ein erstes zugängliches Automatisierungsniveau.

Funktionieren diese Umgehungstechniken gegen Gmail und Outlook nativ?

Gmail und Outlook verfügen über eigene Filterschichten (Gmail verwendet fortgeschrittene ML-Modelle, Outlook integriert Defender). Diese Filter schneiden beim DMARC-Alignment und der Erkennung verdächtiger Reply-Tos besser ab als der Durchschnitt. Aber sie sind nicht unfehlbar: Die Indikatoren 5 (ungewöhnliche Received-Kette), 7 (verdächtiger X-Mailer), 8 (inkonsistente Message-ID) und 10 (HTML-Anhang) bleiben auch für diese Plattformen blinde Flecken.

Wie schule ich mein SOC-Team in der Header-Analyse?

Beginne mit einem 2-stündigen Praxis-Workshop mit echten (anonymisierten) E-Mails, die jeden der 10 Indikatoren aufweisen. Erstelle eine druckbare Checkliste, die Analysten bei jeder Untersuchung konsultieren. Integriere die Header-Analyse in Tabletop-Übungen und interne Phishing-Simulationen. Das Ziel ist, dass jeder SOC-Analyst die 10 Indikatoren in weniger als 5 Minuten pro E-Mail identifizieren kann.

Muss ich mein E-Mail-Gateway ersetzen, um geschützt zu sein?

Nein. Die 10 Indikatoren ergänzen das Gateway, sie ersetzen es nicht. Das Gateway bleibt unverzichtbar, um Massen-Spam, bekannte Malware und generische Phishing-Kampagnen zu blockieren. Ziel ist es, eine Post-Gateway-Erkennungsschicht hinzuzufügen (Transportregeln, SOC-Analyse, SIEM), die auf ausgeklügelte Angriffe abzielt, die der Standardfilter nicht erkennt.

Wie teste ich, ob mein Gateway diese Signale verpasst?

Sende dir selbst Test-E-Mails von einem externen Server, die jeden der 10 Indikatoren reproduzieren. Für die Return-Path-Abweichung: Konfiguriere einen MAIL FROM, der vom From abweicht. Für Drittanbieter-DKIM: Signiere mit einer anderen Domain. Für Reply-To: Füge ein Reply-To ein, das auf eine externe Domain zeigt. Dokumentiere, welche E-Mails das Gateway passieren und welche blockiert werden. Dieser Test deckt die spezifischen blinden Flecken deiner Konfiguration auf.

Glossar

• Return-Path: Header, der vom Empfangsserver eingefügt wird und die SMTP-Envelope-Adresse (MAIL FROM) enthält. Wird für Unzustellbarkeitsmeldungen (Bounces) verwendet. Von SPF geprüft.
• DKIM-Signature: Header mit der kryptografischen Signatur einer Nachricht. Das Feld d= identifiziert die signierende Domain, s= den Selektor des öffentlichen Schlüssels.
• DMARC-Alignment: Überprüfung, ob die From-Domain mit der von SPF verifizierten Domain (SPF-Alignment) oder der DKIM-Signaturdomain (DKIM-Alignment) übereinstimmt. Das Alignment kann strikt (exakte Übereinstimmung) oder relaxed (Übereinstimmung auf Organisationsdomainebene) sein.
• Reply-To: Optionaler Header, der die Adresse angibt, an die Antworten gerichtet werden sollen. Kann vom From abweichen.
• Received-Kette: Serie von Headern, die von jedem Server (Hop) hinzugefügt werden, der die Nachricht verarbeitet hat. Von oben nach unten gelesen, zeichnen sie den Weg der Nachricht vom letzten Hop (oben) zum ersten (unten) nach.
• STARTTLS: SMTP-Erweiterung, die eine TLS-verschlüsselte Verbindung über eine bestehende SMTP-Verbindung initiiert. In Received-Headern sichtbar durch den Hinweis with ESMTPS.
• X-Mailer: Optionaler Header, der die Client-Software identifiziert, die zum Senden der Nachricht verwendet wurde. Nicht von den RFCs standardisiert, aber weit verbreitet bei E-Mail-Clients.
• Message-ID: Eindeutiger Identifikator, der jeder Nachricht vom sendenden Server zugewiesen wird. Format: <identifikator@domain>. Wird für Konversationsverkettung und Deduplizierung verwendet.
• MIME (Multipurpose Internet Mail Extensions): E-Mail-Kodierungsstandard, der Anhänge, HTML-Inhalte und Nicht-ASCII-Zeichen ermöglicht. Definiert durch den Content-Type-Header.
• Content-Disposition: MIME-Header, der angibt, ob ein Nachrichtenteil inline angezeigt (inline) oder als Download angeboten (attachment) werden soll.
• Envelope-Absender: SMTP-Adresse, die beim MAIL-FROM-Befehl in der SMTP-Sitzung verwendet wird. Unterscheidet sich von der Adresse im From-Header, die für den Empfänger sichtbar ist.

---

Verbergen deine Header verdächtige Signale? Füge deine Roh-Header in unseren E-Mail-Header-Analyzer ein, um eine automatische Diagnose zu erhalten, die Authentifizierung, Routing und die in diesem Artikel beschriebenen Anomalien abdeckt.

---

Quellen

• RFC 5322 - Internet Message Format
• RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures
• RFC 7208 - Sender Policy Framework (SPF)
• Microsoft - Enhanced Filtering for Connectors in Exchange Online
• MITRE ATT&CK T1566 - Phishing