E-Mail-Versand beweisen: Header, Hashes und gerichtsfeste Beweise

Um zu beweisen, dass eine E-Mail gesendet wurde, brauchst du die technischen Header der Nachricht, keinen Screenshot. Die Received-Kette, die Message-ID und die Authentication-Results (SPF, DKIM, DMARC) zeigen, woher die E-Mail kam und welchen Weg sie genommen hat. Kombinierst du diese Header mit einem SHA-256-Hash der Originaldatei, hast du einen manipulationssicheren Nachweis, auf den sich ein Richter oder die Personalabteilung tatsächlich verlassen kann.

Das Wichtigste in Kürze

• Ein Screenshot eines Posteingangs beweist so gut wie nichts: Er lässt sich mühelos bearbeiten und enthält weder Header noch Übertragungskette noch einen Integritäts-Hash.

• Der eigentliche Beweis steckt in den E-Mail-Headern: der Received-Kette (die Stationen, die die Nachricht durchlaufen hat), der Message-ID (ein eindeutiger Fingerabdruck) und den SPF/DKIM/DMARC-Ergebnissen, die zeigen, ob der Absender authentifiziert wurde.

• Ein SHA-256-Hash der originalen .eml oder .msg-Datei dient als manipulationssicherer Anker: Ändert sich ein einziges Byte, ändert sich der Hash.

• Allein Business Email Compromise verursachte 2024 2,77 Milliarden US-Dollar Schaden bei 21.442 Beschwerden (Quelle: FBI IC3 2024 Annual Report, 2025), deshalb ist die Echtheit von E-Mails wichtiger denn je.

• Tools wie PDFengine machen aus einer Roh-E-Mail einen einseitigen Echtheitsbericht, der Header und einen Hash festhält, ohne den Nachrichtentext darzustellen. Beachte die ehrlichen Grenzen weiter unten.

Die meisten greifen zum Screenshot, wenn sie beweisen müssen, dass es eine E-Mail gibt. Das fühlt sich naheliegend an. Das Problem: Ein Screenshot ist die schwächste denkbare Form digitaler Beweise, und die Leute, auf die es ankommt, wissen das: Richter, Schiedsrichter, Ermittler in Personalabteilungen.

E-Mail-Beweise müssen echte Authentizitätsstandards erfüllen und nicht nur überzeugend aussehen.

Warum ist ein Screenshot einer E-Mail kein gültiger Beweis?

Ein Screenshot beweist nichts im kryptografischen Sinn und lässt sich leicht fälschen. Jeder kann in den Entwicklertools eines Browsers Text ändern, eine Absenderadresse neu eintippen oder ein Bild in Sekunden manipulieren. Genau deshalb kommt das Thema so oft auf: Auf der juristischen Q&A-Seite Avvo fragen Leute regelmäßig: „Wie zulässig ist ein Screenshot von nicht verifizierten Konten als Beweismittel vor Gericht?“ Die ehrliche Antwort lautet: Für sich genommen hat er sehr wenig Gewicht.

Ein Screenshot hält nur die dargestellte Oberfläche einer E-Mail fest. Alles darunter geht verloren: die Header mit dem sendenden Server, die eindeutige Message-ID, die Authentifizierungsergebnisse und jede Möglichkeit, Manipulationen zu erkennen. Die Gegenseite muss nur eine Frage stellen: „Woher wissen wir, dass das nicht bearbeitet wurde?“ Auf einen bloßen Screenshot gibt es darauf keine Antwort.

Zitierfähige Kurzfassung: Ein Screenshot eines E-Mail-Posteingangs ist reine Darstellung ohne zugrunde liegende Metadaten. Er enthält keine Received-Kette, keine Message-ID und keinen Integritäts-Hash und kann daher nicht eigenständig belegen, dass eine E-Mail gesendet wurde, von wem sie stammt oder dass der Inhalt unverändert ist. Forensisch belastbare Beweise erfordern die Rohheader und einen kryptografischen Hash der Quelldatei.

Mehr zum rechtssicheren Aufbewahren von Nachrichten findest du in unserem Leitfaden zur E-Mail-Archivierung und E-Mail-zu-PDF/A-Konvertierung.

Was belegt wirklich, dass eine E-Mail gesendet wurde?

Der Beweis steckt in den vollständigen Headern der E-Mail, die die meisten Postfächer standardmäßig ausblenden. In Gmail zeigst du sie mit „Original anzeigen“ an, in Outlook über die Nachrichteneigenschaften. Diese Header sind das Protokoll, das dein E-Mail-Server und jedes Relay auf dem Weg automatisch geschrieben haben. Drei Felder leisten die Hauptarbeit, und jedes beantwortet eine andere Frage.

Die Received-Kette: Welchen Weg hat die E-Mail genommen?

Die Received-Kette ist ein Stapel von Zeilen, die jeder Mailserver (MTA) hinzufügt, der die Nachricht bearbeitet hat. Von unten nach oben gelesen, zeichnet sie den Weg der E-Mail vom Server des Absenders bis zu deinem nach, mit Zeitstempeln und IP-Adressen an jeder Station. Das kommt dem, was bei E-Mails ein Poststempel-Verlauf wäre, am nächsten. Ist die Kette in sich stimmig und passt sie zur Infrastruktur des angeblichen Absenders, spricht vieles dafür, dass die E-Mail tatsächlich diesen Weg genommen hat.

Message-ID, Return-Path und Reply-To: Wer und was?

Die Message-ID ist eine weltweit eindeutige Kennung, die beim Erstellen der Nachricht vergeben wird, vergleichbar mit einer Seriennummer. Stimmen die Message-IDs in der „Gesendet“-Kopie des Absenders und in der empfangenen Kopie des Empfängers überein, ist das eine starke Bestätigung. Die Felder Return-Path und Reply-To liefern Kontext zum tatsächlichen Absenderkonto, das sich manchmal vom freundlichen „From“-Namen unterscheidet, den ein Fälscher vortäuschen könnte.

SPF, DKIM und DMARC: Wurde der Absender authentifiziert?

Diese drei Prüfungen sagen dir, ob die E-Mail tatsächlich von der angegebenen Domain stammt. SPF prüft, ob der sendende Server für diese Domain autorisiert ist. DKIM ist eine kryptografische Signatur, die die Nachricht an die Domain bindet. DMARC verbindet beide über eine Richtlinie. Der empfangende Server hält das Ergebnis im Header Authentication-Results als Urteil fest: pass, fail, softfail, neutral, none, temperror oder permerror. Ein grünes pass bei allen dreien ist ein starkes Signal für Echtheit.

Hier ein Haken, den du kennen solltest: Authentifizierung ist längst nicht überall verbreitet. In der Praxis setzen viele sendende Domains DMARC noch immer nicht durch, und etliche veröffentlichen eine Richtlinie mit dem Wert „none“, die Empfänger bei einem Fehlschlag um keine Maßnahme bittet. Ein fehlendes oder nicht durchgesetztes „pass“ ist also kein Beweis für eine Fälschung, oft bedeutet es nur, dass die sendende Domain schlecht konfiguriert ist.

Weil die Durchsetzung so lückenhaft ist, dreht sich der praktische Rat gegenüber der üblichen Empfehlung um. Ein DKIM-pass ist ein starker positiver Beleg, aber ein fehlendes oder none-Ergebnis ist nur ein schwacher negativer Beleg. In den meisten Streitfällen leisten die Received-Kette und die Message-ID mehr verlässliche Arbeit, als einem DMARC-Urteil nachzujagen, das die Domain des Absenders vielleicht nie unterstützt hat.

Was Roh-E-Mail-Header tatsächlich enthalten, bevor ein Tool sie erfasst.

Wie macht ein SHA-256-Hash E-Mail-Beweise manipulationssicher?

Ein SHA-256-Hash ist ein Fingerabdruck einer Datei mit fester Länge. Schickst du dieselbe Datei zweimal durch den Algorithmus, erhältst du denselben Hash; änderst du ein einziges Byte, ändert sich der Hash vollständig. Diese Eigenschaft macht ihn zu einem manipulationssicheren Anker. Wenn du den SHA-256-Hash der originalen .eml oder .msg-Datei in dem Moment festhältst, in dem du sie archivierst, kann jeder die Datei später erneut hashen und bestätigen, dass sie seither nicht verändert wurde.

Das ist der Baustein, den ein Screenshot nie liefern kann. Der Hash beweist nicht, dass der Inhalt der E-Mail wahr ist, aber er beweist, dass die Datei, die du heute vorlegst, Byte für Byte dieselbe ist, die du damals gesichert hast. Zusammen mit einem UTC-Zeitstempel und der Dateigröße in Byte ergibt sich eine einfache, überprüfbare Integritätskette, die auch ein technisch nicht versierter Prüfer nachvollziehen kann.

Zitierfähige Kurzfassung: Ein SHA-256-Hash einer originalen .eml oder .msg-Datei ist ein Mechanismus zum Nachweis von Manipulationen. Da jede Änderung an der Datei einen anderen Hash ergibt, kann ein Dritter den Hash, der zum Archivierungszeitpunkt festgehalten wurde, später neu berechnen und bestätigen, dass die Datei unverändert ist. Genau diesen Integritätsanker hat ein Screenshot grundsätzlich nicht.

Wie machst du aus einer Roh-E-Mail einen gerichtsfesten Beweis?

Für eine einzelne E-Mail brauchst du keine Forensik-Firma. Der Ablauf ist kurz und besteht aus drei Schritten:

1. Exportiere die Originalnachricht als .eml oder .msg-Datei, nicht als Screenshot und nicht als weitergeleitete Kopie.

2. Schicke sie durch ein Tool, das die Header extrahiert und einen Hash berechnet, zum Beispiel PDFengine E-Mail-zu-Beweis.

3. Bewahre den einseitigen Bericht auf, der die Header und den SHA-256-Hash festhält.

In der Praxis machen die meisten beim Export den Fehler. Leitest du eine E-Mail an dich selbst weiter, werden die Header neu geschrieben und die Kette bricht ab. Verwende immer „Speichern unter“ oder „Originalnachricht herunterladen“, damit die .eml/.msg-Datei ihre ursprünglichen Received-Zeilen und die Message-ID behält.

Was der PDFengine-Beweisbericht enthält:

• Integrität: der SHA-256-Hash der Originaldatei (in Festbreitenschrift dargestellt), die Dateigröße in Byte und ein UTC-Zeitstempel. Der Hash ist eine Momentaufnahme der Originaldatei und wird nach der Verarbeitung nicht neu berechnet.

• Identität: From, To, Subject, Date, Message-ID, Return-Path und Reply-To.

• Authentifizierung: SPF-, DKIM- und DMARC-Ergebnisse, aus dem Header Authentication-Results ausgelesen und farbcodiert, sodass pass grün und fail rot angezeigt wird. Gibt es keinen solchen Header, bleiben die Felder leer; sie werden nie erfunden.

• Transport: die vollständige Received-Kette.

• Dazu der S/MIME-Signaturstatus und der meldende Host (der Server, der die Authentifizierungsergebnisse gestempelt hat).

Bemerkenswert: Der Bericht gibt den Nachrichtentext nicht wieder. Das ist Absicht. Wird der Nachrichtentext weggelassen, gibt es keinen Streit darüber, wie der Inhalt angezeigt wurde, und der Fokus bleibt auf den forensischen Metadaten, die Weg und Integrität der E-Mail belegen.

Eine Beweisseite zu einem E-Mail-Export hinzuzufügen, dauert nur einen Klick.

Die ehrlichen Grenzen, die du kennen solltest

Kein Tool ist Zauberei, und wer etwas anderes vorgibt, riskiert, dass Beweise verworfen werden. Zwei Einschränkungen sind wichtig.

Erstens: Bei einer hochgeladenen einzelnen .eml/.msg-Datei stammen die SPF/DKIM/DMARC-Ergebnisse und die Received-Header aus der gelieferten Datei. PDFengine prüft sie nicht unabhängig erneut, denn wer die Datei geliefert hat, könnte die Header theoretisch vor dem Hochladen verändert haben. Das ist eine Frage der Beweismittelkette und kein Mangel des Tools: Die Datei ist nur so vertrauenswürdig wie ihre Quelle.

Zweitens: Auch bei E-Mails, die direkt an ein PDFengine-Postfach gesendet werden (eingehend), bei denen die Authentifizierungswerte bei der Zustellung vom eigenen Empfangsserver von PDFengine gestempelt wurden, wird die kryptografische DKIM-Signatur von PDFengine nicht erneut geprüft. Eine unabhängige kryptografische DKIM-Prüfung ist geplant, aber noch nicht live. Behaupte also nicht, der Bericht prüfe DKIM kryptografisch neu. Er gibt das Urteil wieder; er rechnet nicht noch einmal nach.

PDFengine vs. Adobe Acrobat bei E-Mail-Beweisen

Acrobat wandelt eine E-Mail hervorragend in ein sauberes, lesbares PDF um. Es ist aber nicht dafür gebaut, Echtheitsnachweise zu erzeugen. Nach dem dokumentierten Funktionsumfang von Adobe Acrobat erfasst das Outlook-Plug-in den sichtbaren Text und die grundlegenden Angaben Von/An/Betreff, nicht aber die vollständigen technischen Header, einen Datei-Hash oder die Auswertung von SPF/DKIM/DMARC. Hier der ehrliche direkte Vergleich.

Kurz gesagt: Nutze Acrobat, wenn du eine teilbare, druckbare Kopie des Inhalts einer E-Mail möchtest. Nutze dagegen ein spezialisiertes Beweis-Tool, wenn du die Herkunft und Integrität der E-Mail beweisen musst. Beide lösen unterschiedliche Probleme. Acrobat ist abonnementbasiert und auf den Desktop ausgerichtet (aktuelle Preise bei Adobe nachsehen), während die Beweisextraktion pro E-Mail bei gelegentlicher Nutzung deutlich günstiger ist.

Authentifizierung und Integrität unterscheiden einen Beweis von einem Screenshot.

Du musst mehr als eine Nachricht erfassen? Unser E-Mail-zu-PDF-Tool verarbeitet einzelne Nachrichten, während PST zu PDF ganze Postfächer zur Archivierung konvertiert.

Häufig gestellte Fragen

Wie beweise ich, dass ich eine E-Mail gesendet habe?

Exportiere die Originalnachricht als .eml oder .msg-Datei aus deinem Ordner „Gesendet“ und sichere ihre Header, vor allem die Message-ID und die Received-Kette, statt dich auf einen Screenshot zu verlassen. Eine häufige Frage in der Gmail Community lautet genau so, und die dauerhafte Antwort bleibt dieselbe: Die Header plus ein Hash der Originaldatei haben Gewicht.

Ist ein Screenshot einer E-Mail vor Gericht gültig?

Für sich genommen selten. Wie Leute in den Rechtsforen von Avvo fragen, lassen sich Screenshots von nicht verifizierten Konten leicht anfechten, weil sie keine Header, keine Übertragungskette und keine Möglichkeit enthalten, Bearbeitungen zu erkennen. Sie können einen Fall als Kontext stützen, sind aber kein eigenständiger Echtheitsbeweis. Ergänze jeden Screenshot um die Originaldatei und ihre Header.

Wie kann ich beweisen, dass eine E-Mail zugestellt (und nicht nur gesendet) wurde?

Die Zustellung ist schwerer zu belegen als das Senden. Die Received-Kette des Empfängers zeigt, dass die Nachricht seinen Mailserver erreicht hat, und das Ausbleiben eines Bounce ist ein Indiz. Echte „Lesebestätigungen“ sind jedoch unzuverlässig und leicht zu deaktivieren. Wie der Thread „anyway to prove my email was delivered?“ in der Gmail Community zeigt, sind die stärksten verfügbaren Belege meist die Header auf Empfängerseite, die die Annahme durch seinen Server zeigen.

Was sind E-Mail-Header und wo finde ich sie?

Header sind die versteckten Metadaten, die jeder Mailserver schreibt, während eine E-Mail unterwegs ist. In Gmail öffnest du die Nachricht, klickst auf das Drei-Punkte-Menü und wählst „Original anzeigen“. In Outlook öffnest du die Nachrichteneigenschaften oder „Quelltext anzeigen“. Dort siehst du die Received-Kette, die Message-ID, den Return-Path und die Authentication-Results, also die Felder, die die Herkunft tatsächlich belegen.

Können E-Mail-Header gefälscht werden?

Die Ergebnisse zur Authentifizierung (vor allem DKIM) lassen sich nur schwer überzeugend fälschen. Aber die Header in einer einzelnen .eml-Datei, die dir übergeben wurde, können von demjenigen verändert werden, der sie geliefert hat; deshalb ist die Beweismittelkette wichtig. Eingehende Header, die ein vertrauenswürdiger Empfangsserver gestempelt hat, sind stärker als Header in einer Datei unbekannter Herkunft.

Prüft PDFengine DKIM kryptografisch erneut?

Noch nicht. PDFengine gibt die SPF/DKIM/DMARC-Ergebnisse wieder, die im Header Authentication-Results stehen, und berechnet einen SHA-256-Hash der Originaldatei. Eine unabhängige erneute Prüfung der DKIM-Signatur ist geplant, aber derzeit nicht live; der Bericht zeigt also das aufgezeichnete Urteil, statt die kryptografische Prüfung erneut auszuführen.

Fazit

Zu wissen, wie du beweist, dass eine E-Mail gesendet wurde, hat nichts damit zu tun, wie überzeugend dein Screenshot aussieht. Es geht um den technischen Datensatz darunter: die Received-Kette, die den Weg der E-Mail nachzeichnet, die Message-ID, die sie wie ein Fingerabdruck kennzeichnet, die SPF/DKIM/DMARC-Ergebnisse, die den Absender prüfen, und einen SHA-256-Hash, der die Datei gegen Manipulation absichert. Sicherst du diese Angaben, hast du Beweise, die einer Prüfung standhalten, statt beim ersten „Woher wissen wir, dass das echt ist?“ einzuknicken.

Wenn es die Umstände rechtfertigen: Angesichts von 2,77 Milliarden US-Dollar Verlust allein durch Business Email Compromise im Jahr 2024 (Quelle: FBI IC3 2024 Annual Report, 2025) ist vorausschauende Archivierung eine günstige Versicherung. Exportiere die originale .eml oder .msg-Datei, schicke sie durch ein Beweis-Tool und bewahre den einseitigen Bericht in der Akte auf.

Du willst aus einer Roh-E-Mail einen einseitigen Echtheitsbericht mit Headern und einem SHA-256-Hash machen? Probiere PDFengine E-Mail-zu-Beweis, ganz ohne Outlook oder Desktop-Software. Für größere Aufträge archiviert unser PST-zu-PDF-Konverter ganze Postfächer auf einmal.

Über den Autor — Daan van Tongeren ist der Gründer von PDFengine (pdfen.com), einer Online-Plattform für PDF-Konvertierung, druckfertige Aufbereitung und E-Mail-Archivierung.