E-Mail-Spoofing: gefälschte Absender erkennen und stoppen

So kommt eine gefälschte Mail beim Empfänger an, gekürzt auf die Zeilen, die zählen:

Return-Path: <bounce@versand.example>
Received: from mail.versand.example (mail.versand.example [203.0.113.45])
        by mx.empfaenger.example with ESMTPS; Fri, 2 Oct 2026 09:14:02 +0200
Authentication-Results: mx.empfaenger.example;
       spf=pass smtp.mailfrom=versand.example;
       dkim=none;
       dmarc=fail (p=none) header.from=deine-domain.at
From: "Buchhaltung" <rechnung@deine-domain.at>
Reply-To: <zahlung@andere-domain.example>
Subject: Offene Rechnung 2026-1043

Im From: steht deine Adresse, verschickt hat sie ein fremder Server, und der Empfänger hat das auch gemerkt: dmarc=fail. Zugestellt wurde sie trotzdem, weil deine Domain mit p=none nur um Berichte bittet und nichts verlangt. Das ist E-Mail-Spoofing: Jemand verschickt Mails mit einer fremden Absenderadresse, und das Mailprotokoll prüft die Adresse im From: nicht. Ob eine Mail wirklich von der Domain kommt, die sie nennt, entscheidet erst der Empfänger, anhand von drei DNS-Einträgen dieser Domain: SPF, DKIM und DMARC.

Gefälschte Mails mit deiner Adresse heißen nicht, dass dein Postfach gehackt ist. Meist hat der Absender dein Konto nie berührt. Abstellen lässt sich das auf deiner Seite, im DNS, ohne neues Programm und ohne neuen Anbieter.

Warum das geht#

Eine Mail hat zwei Absender. Der eine steht im Umschlag (MAIL FROM, in der fertigen Mail als Return-Path zu sehen) und sagt, wohin Unzustellbarkeitsmeldungen gehen. Der andere steht im Kopf der Nachricht als From: und ist der, den das Mailprogramm anzeigt. RFC 5321 und RFC 5322 verlangen nicht, dass beide zusammenpassen, und keiner von beiden wird beim Versand geprüft. SPF prüft später nur den Umschlag; warum das so ist und was DKIM dazu beiträgt, steht ausführlich in DMARC einrichten.

Daraus ergeben sich drei Spielarten:

1. Gleiche Domain. Im From: steht wirklich rechnung@deine-domain.at. Dagegen helfen SPF, DKIM und DMARC, sofern die Domain sie gesetzt hat.
2. Nur der Anzeigename. Im From: steht „Buchhaltung Deine Firma“ <irgendwer@freemail.example>. Viele Mailprogramme auf dem Telefon zeigen nur den Namen. DNS-Einträge können das nicht verhindern, denn die Adresse gehört jemand anderem.
3. Ähnliche Domain. deine-domain.co oder deine-dornain.at mit „rn“ statt „m“. Auch hier greifen deine Einträge nicht; der Angreifer hat die fremde Domain registriert und kann für sie selbst SPF und DKIM setzen.

Wer mit einer gefälschten Rechnung oder einer angeblich neuen Kontonummer im Namen eines Lieferanten betrogen werden soll, sieht meist Fall 2 oder 3. Wer Spam „von sich selbst“ bekommt oder von Kunden auf Mails angesprochen wird, die er nie geschrieben hat, sieht Fall 1.

Vier Zeilen, die die Fälschung verraten#

Was eine Mail wirklich ist, steht im vollständigen Nachrichtenkopf. So kommt man an ihn heran:

• Gmail: Nachricht öffnen, Drei-Punkte-Menü, „Original anzeigen“.
• Outlook (Desktop): Nachricht per Doppelklick öffnen, „Datei“ → „Eigenschaften“, Feld „Internetkopfzeilen“.
• Outlook im Web und neues Outlook: Drei-Punkte-Menü → „Anzeigen“ → „Nachrichtendetails anzeigen“.
• Apple Mail: „Darstellung“ → „Nachricht“ → „Alle Header“.
• Thunderbird: „Ansicht“ → „Kopfzeilen“ → „Alle“, oder mit Strg+U den Quelltext öffnen.

Im Beispiel oben verraten vier Zeilen die Fälschung.

Authentication-Results ist das Urteil des empfangenden Servers (festgelegt in RFC 8601). Entscheidend ist dmarc=: pass heißt, die Mail kommt nachweislich aus dem Umfeld der Domain im From:. fail heißt, sie tut es nicht. Dass spf=pass daneben steht, beruhigt nicht, denn es gilt für versand.example, die Domain aus dem Umschlag, nicht für die angezeigte.

Return-Path nennt eine ganz andere Domain als das From:. Bei Newsletter-Diensten ist das normal, bei einer Rechnung vom eigenen Lieferanten ein Warnzeichen.

Received: Jeder Server auf dem Weg setzt oben eine Zeile dazu. Verlässlich ist nur die, die dein eigener Mailserver geschrieben hat. Sie nennt Namen und IP-Adresse des Servers, der die Mail abgeliefert hat. Hat er nichts mit dem angeblichen Absender zu tun, war es nicht dessen Server. Zeilen weiter unten kann der Absender selbst erfunden haben.

Reply-To schickt die Antwort an eine dritte Adresse. Dorthin soll die Rückfrage zur „neuen Kontonummer“ gehen.

Und p=none in der DMARC-Zeile sagt noch etwas: Die gefälschte Domain hat zwar DMARC, verlangt aber nicht, dass Fälschungen aussortiert werden. Deshalb lag die Mail im Posteingang statt im Spam.

Gefälscht oder gehackt?#

Bekommst du Mails, die angeblich von dir selbst kommen, oder melden sich Kunden wegen Nachrichten, die du nicht geschickt hast, hilft ein Blick in den Ordner „Gesendet“ und in die Anmeldeprotokolle deines Mailanbieters. Stehen die Mails dort nicht und gibt es keine fremden Anmeldungen, sind sie gefälscht, und der Header zeigt dmarc=fail. Stehen sie dort, ist das Postfach übernommen. Dann zuerst das Passwort ändern, Zwei-Faktor-Anmeldung einschalten und Weiterleitungsregeln prüfen; ein DNS-Eintrag hilft in diesem Fall nicht.

Ein Nebeneffekt von Spoofing sind Unzustellbarkeitsmeldungen zu Mails, die du nie verschickt hast. Der Angreifer hat deine Adresse als Absender eingesetzt, und manche Server schicken ihre Fehlermeldung an diese Adresse zurück. Nennen echte Rückläufer dagegen eine Sperrliste, steht der eigene Mailserver darauf; das zeigt der Blacklist-Check.

Zwei Reflexe, die in diesem Fall nichts bringen: die Absenderadresse beim eigenen Mailanbieter „sperren“ (der Angreifer verschickt über seinen eigenen Server, dein Anbieter sieht die Mail nie) und das Passwort ändern, obwohl das Postfach gar nicht betroffen ist (schadet nicht, ändert an gefälschten Mails aber nichts, solange DMARC fehlt oder auf p=none steht).

Die eigene Domain schützen#

Gegen Fall 1 wirken drei Einträge im DNS deiner Domain zusammen:

1. SPF nennt die Server, die für die Domain senden dürfen. Ein Eintrag, höchstens zehn DNS-Abfragen, am Ende ~all oder -all. Zusammensetzen lässt er sich im SPF-Generator, die Schritte stehen in SPF-Eintrag erstellen. Ein zweiter Eintrag für einen neuen Dienst ist ein Fehler: Zwei Einträge mit v=spf1 wertet der Empfänger gar nicht aus.
2. DKIM hängt an jede Mail eine Signatur. Den Schlüssel erzeugt der Mailanbieter, du veröffentlichst den öffentlichen Teil im DNS.
3. DMARC verbindet beides mit der sichtbaren Adresse im From: und sagt dem Empfänger, was mit einer Mail passieren soll, die weder SPF noch DKIM für diese Domain besteht: nichts (p=none), Spam-Ordner (p=quarantine) oder abweisen (p=reject). Den Eintrag erzeugt der DMARC-Generator.

Erst p=quarantine oder p=reject schützt. Mit p=none kommen nur Berichte, die Fälschung landet weiter im Posteingang. Der Weg dorthin führt trotzdem über p=none: zwei bis vier Wochen Berichte lesen, bis jeder eigene Versandweg (Postfach, Newsletter, Buchungssystem, Rechnungsprogramm) SPF oder DKIM besteht, dann verschärfen. Wer p=reject setzt, ohne die Berichte gelesen zu haben, verliert die eigenen Newsletter oder Rechnungen, sobald einer der Dienste nicht sauber eingetragen ist. Die sieben Schritte stehen in DMARC einrichten.

Domains, über die gar keine Mails verschickt werden, sind am schnellsten geschützt: v=spf1 -all als SPF-Eintrag und v=DMARC1; p=reject unter _dmarc. Damit sagt die Domain jedem Empfänger, dass jede Mail in ihrem Namen falsch ist.

Wo deine Domain heute steht, zeigt der E-Mail-Check: Er liest SPF, DKIM und DMARC und zeigt in vier Ampeln, ob eine Fälschung durchkäme. Rot oder gelb bei DMARC heißt, dass Mails mit deiner Adresse heute zugestellt werden, egal wer sie schickt.

Gegen Fall 2 und 3 hilft kein Eintrag bei dir, sondern Aufmerksamkeit beim Empfänger: Bei Mails mit Zahlungsanweisungen den Header ansehen, die Adresse ausklappen statt den Namen zu lesen, und eine neue Kontonummer nie per Antwort auf dieselbe Mail bestätigen, sondern über eine bekannte Telefonnummer.

So sieht das Ergebnis aus, wenn alle vier Punkte stehen. Die Domain gehört mir (elitegear.io), der Screenshot ist vom 03.10.2026:

Messung#

34 Tiroler Tourismusverbände, dreimal geprüft#

In eigener Sache: Am 29.09.2026 um 01:48 UTC habe ich die öffentlichen DNS-Einträge der Hauptdomains aller 34 Tiroler Tourismusverbände abgefragt, am 02.10. (17:52 UTC) und am 03.10. (04:04 UTC) noch einmal. Die Abfrage lief über DNS-over-HTTPS bei Cloudflare, rein passiv: kein Zugriff auf Systeme, keine Testmail, keine Verbindung zu einem Mailserver. Geprüft wurden _dmarc.<domain>, der SPF-Eintrag und die MX-Einträge der Hauptdomain. Als wirksam gilt eine Richtlinie p=quarantine oder p=reject. Nicht erfasst sind weitere Versanddomains oder Subdomains der Verbände, und ein DMARC-Eintrag sagt nichts über gehackte Postfächer, nur über gefälschte Absender.

Alle 34 haben den ersten Schritt gemacht, SPF steht überall. 25 haben einen DMARC-Eintrag, aber 22 davon mit p=none, und bei 18 der 25 fehlt die Berichtsadresse: Sie erfahren nicht, ob jemand ihren Namen benutzt. Für einen Gast heißt das: Eine Mail mit der Absenderadresse eines dieser 31 Verbände wird heute zugestellt, egal wer sie schickt. Die „gefälschte Buchungsbestätigung mit neuer Kontonummer“ ist Fall 1 von oben.

Namen nenne ich nicht, auch die drei mit wirksamer Richtlinie nicht, sonst ließen sich die anderen per Ausschluss ermitteln. Jeder Verband kann seine Domain selbst im E-Mail-Check prüfen. Eine Randnotiz zur Sorgfalt: Am 29.09. hatte ein Verband zwei TXT-Einträge, die wie SPF aussahen; am 03.10. war nur noch der gültige da. Solche Dinge ändern sich, deshalb steht bei jeder Zahl hier das Datum.

Und die Betriebe im Land?#

Dieselbe Abfrage am 27.09.2026 für 115 Tiroler Betriebe aus meiner Akquise-Liste (Hotels, Arzt- und Zahnarztpraxen, Kanzleien, Handwerk, Agenturen, Stadtwerke, überwiegend Innsbruck und Zillertal): 60 ohne DMARC-Eintrag, 43 mit p=none, 1 mit zwei Einträgen, 3 mit quarantine, 8 mit reject. Also 104 von 115 ohne wirksame Richtlinie, dazu 14 ohne SPF. Die Verbände sind damit kein Sonderfall. Die Zahlen für alle 149 Domains zusammen und die Grafik dazu stehen in DMARC einrichten.

Häufige Fragen#

Kann man E-Mail-Spoofing verhindern?#

Für die eigene Domain ja: Mit SPF, DKIM und DMARC auf p=quarantine oder p=reject weisen die großen Postfachanbieter Fälschungen mit deiner Adresse ab oder sortieren sie aus. Gegen ähnlich geschriebene Domains und gefälschte Anzeigenamen hilft das nicht; dort bleibt nur der Blick in den Header.

Woran erkenne ich eine gespoofte Mail?#

Im vollständigen Nachrichtenkopf an dmarc=fail in der Zeile Authentication-Results, an einem Return-Path oder Received von einer fremden Domain und an einem Reply-To, das woandershin zeigt als das From:.

Ist mein Konto gehackt, wenn Spam mit meiner Adresse verschickt wird?#

Meist nicht. Steht die Mail nicht in deinem Ordner „Gesendet“ und zeigt der Mailanbieter keine fremden Anmeldungen, wurde nur die Adresse gefälscht. Dagegen hilft DMARC. Steht sie dort, ist das Postfach übernommen, und zuerst kommen Passwort und Zwei-Faktor-Anmeldung.

Reicht ein SPF-Eintrag gegen Spoofing?#

Nein. SPF prüft nur die Absenderadresse aus dem Umschlag, nicht die angezeigte im From:. Ein Angreifer kann einen eigenen Umschlag-Absender verwenden, der SPF besteht, und trotzdem deine Adresse anzeigen. Erst DMARC verlangt, dass die geprüfte Domain zur angezeigten passt.

Wenn du es nicht selbst machen willst#

In eigener Sache: cyberscale bin ich, Stefan Haun aus Tirol. Das Paket E-Mail-Schutz richtet SPF, DKIM und DMARC beim bestehenden Anbieter ein, inventarisiert alle Versandwege aus den DMARC-Berichten und geht schrittweise bis reject, ohne dass Newsletter oder Buchungssystem hängen bleiben. Vorher kostenlos selbst prüfen: der E-Mail-Check.

Stand 03.10.2026. Quellen abgerufen und die DNS-Messung an diesem Tag wiederholt.

Quellen#

• RFC 9989: DMARC (Mai 2026, Nachfolger von RFC 7489): p, sp, np, Abgleich der From:-Domain mit SPF und DKIM
• RFC 7208: SPF: Prüfung der Umschlag-Adresse (MAIL FROM), ein Eintrag je Domain, zehn DNS-Abfragen
• RFC 6376: DKIM: Signatur und öffentlicher Schlüssel im DNS
• RFC 8601: Authentication-Results: die Kopfzeile, in der der Empfänger SPF, DKIM und DMARC festhält
• RFC 5321 und RFC 5322: Umschlag (MAIL FROM) und Nachrichtenkopf (From:, Reply-To:) als getrennte Angaben
• RFC 2606: reservierte Beispieldomains (.example)
• Eigene Messung: DNS-Einträge (DMARC, SPF, MX) der Hauptdomains aller 34 Tiroler Tourismusverbände am 29.09.2026 (01:48 UTC), 02.10.2026 (17:52 UTC) und 03.10.2026 (04:04 UTC) sowie von 115 Tiroler Betrieben am 27.09.2026, jeweils per DNS-over-HTTPS (Cloudflare), passiv. Veröffentlicht werden nur Summen, keine Namen.