E-Mail-Header lesen: Weg, Prüfergebnis und Absender einer Mail verstehen

So sieht der Header einer Mail aus, die mein Ranking-Skript am 21.09.2026 an mich selbst geschickt hat, gekürzt auf die Zeilen, die zählen:

Return-Path: <stefan@elitegear.io>
Delivered-To: admin@cyberscale.io
Received: from s3out.meinehp.at
    by cluster8.xa-servers.net with LMTP
    for <admin@cyberscale.io>;
    Mon, 21 Sep 2026 08:35:50 +0200
Received: from s5out.meinehp.at
    (s5out.meinehp.at [45.144.208.69])
    by s3out.meinehp.at (Postfix) with ESMTPS
    for <admin@cyberscale.io>;
    Mon, 21 Sep 2026 08:35:45 +0200 (CEST)
Authentication-Results: s3out.meinehp.at;
    dkim=pass header.d=elitegear.io
      header.s=default header.b=hk3qfE90;
    dmarc=pass (policy=quarantine)
      header.from=elitegear.io;
    spf=pass (s3out.meinehp.at: domain of
      stefan@elitegear.io designates
      45.144.208.69 as permitted sender)
      smtp.mailfrom=stefan@elitegear.io
ARC-Seal: i=1; s=default; d=cyberscale.io;
    t=1789972546; cv=none; b=…
ARC-Message-Signature: i=1; …
ARC-Authentication-Results: i=1; s3out.meinehp.at; …
Received: from mail-ej2-f12.google.com
    (mail-ej2-f12.google.com [74.125.228.140])
    (Authenticated sender: stefan@elitegear.io)
    by s5out.meinehp.at (Postfix) with ESMTPSA
    for <admin@cyberscale.io>;
    Mon, 21 Sep 2026 08:35:41 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256;
    c=relaxed/relaxed; d=elitegear.io; s=default;
    t=1789972541; h=from:from:reply-to:subject:…;
    bh=…; b=…
Received: by mail-ej2-f12.google.com with SMTP id …
    for <admin@cyberscale.io>;
    Sun, 20 Sep 2026 23:35:41 -0700 (PDT)
Received: from 176840299311 named unknown
    by gmailapi.google.com with HTTPREST;
    Mon, 21 Sep 2026 01:35:39 -0500
From: elitegear Ranking <stefan@elitegear.io>
Date: Mon, 21 Sep 2026 01:35:39 -0500
Message-ID: <CAO6cmdy…@mail.gmail.com>
Subject: elitegear Rankings 21.09.: 21 hoch, 24 runter
X-Spam-Status: No, score=-5.01
X-Spamd-Bar: -----

Ein E-Mail-Header ist das Protokoll der Zustellung. Jeder Server auf dem Weg schreibt eine Received-Zeile dazu, der empfangende Server hält sein Prüfergebnis in Authentication-Results fest, und der Absender hängt eine DKIM-Signatur an. Wer diese drei Teile lesen kann, beantwortet die meisten Fragen selbst: Woher kam die Mail? Wo hing sie fest? War sie echt?

Ein Header wird von unten nach oben gelesen. RFC 5321 verlangt, dass jeder Server seine Received-Zeile an den Anfang der Nachricht setzt und keine vorhandene ändert. Die unterste Zeile ist also die älteste, die oberste die jüngste.

Wo man den Header in Gmail, Outlook, Apple Mail und Thunderbird findet, steht in E-Mail-Spoofing erkennen. Dort stehen auch die vier Zeilen, an denen man eine Fälschung am schnellsten erkennt. Hier geht es um den ganzen Header.

Die Received-Kette, von unten nach oben#

Die fünf Received-Zeilen im Beispiel stehen in drei Zeitzonen: -0500, -0700 und +0200. Wer sie nicht umrechnet, liest eine Mail, die angeblich einen Tag zurückgereist ist. Auf UTC gebracht, ergibt sich der Weg:

Elf Sekunden vom Skript bis ins Postfach. Hängt eine Mail fest, sieht man hier, zwischen welchen zwei Zeilen die Zeit vergangen ist, und damit, wessen Server sie aufgehalten hat.

Die Schlüsselwörter nach with sind in RFC 3848 festgelegt. ESMTPS heißt verschlüsselt mit STARTTLS, ESMTPA heißt mit Anmeldung, ESMTPSA heißt beides. LMTP ist die Übergabe an das Postfach innerhalb eines Anbieters. Steht in einer Zeile nur SMTP oder ESMTP ohne S, lief diese Übergabe nach Angabe des schreibenden Servers ohne STARTTLS.

Eine Kleinigkeit am Rand: Die unterste Zeile steht im Original zweimal, wortgleich. Am Weg ändert das nichts, aber es zeigt, warum man Zeilen nicht zählt, sondern liest.

Welchen Zeilen man glauben kann#

Jede Received-Zeile beschreibt, was der schreibende Server gesehen hat: von wem er die Mail bekam (from) und wer er selbst ist (by). Verlässlich ist das nur für Server, denen man vertraut. Die Grenze verläuft dort, wo die Mail zum ersten Mal einen Server deines eigenen Anbieters erreicht. Im Beispiel ist das Schritt 3. Alles darüber hat der eigene Anbieter geschrieben. Alles darunter hat der Absender oder sein Anbieter behauptet.

Die unterste Received-Zeile kann der Absender frei erfinden. Wer eine Mail fälscht, schreibt vor dem Versand ein paar glaubwürdige Zeilen mit einem bekannten Servernamen hinein. Entscheidend ist deshalb die Zeile, die dein Anbieter geschrieben hat, und dort der Teil in Klammern. Dort steht die IP-Adresse, von der die Mail tatsächlich kam, nicht der Name, den der einliefernde Server von sich behauptet hat.

Dasselbe gilt für Authentication-Results. RFC 8601 verlangt, dass ein Mailserver an seiner Grenze jede solche Zeile löscht, die vorgibt, von ihm selbst zu stammen. Mailprogramme sollen nur Zeilen mit der Kennung des eigenen Anbieters auswerten. Die Kennung steht direkt nach dem Doppelpunkt, im Beispiel s3out.meinehp.at. Eine Authentication-Results-Zeile mit einer fremden Kennung weiter unten ist eine Aussage eines anderen Servers, mehr nicht.

Authentication-Results Feld für Feld#

Die Zeile aus dem Beispiel enthält drei Prüfungen:

• spf=pass … smtp.mailfrom=stefan@elitegear.io sagt, dass die IP-Adresse 45.144.208.69 im SPF-Eintrag der Domain aus dem Umschlag steht. Geprüft wird die Adresse aus Return-Path, nicht die angezeigte.
• dkim=pass header.d=elitegear.io header.s=default sagt, dass die Signatur stimmt und für die Domain elitegear.io mit dem Schlüssel default gilt.
• dmarc=pass (policy=quarantine) header.from=elitegear.io sagt, dass mindestens eine der beiden Prüfungen bestanden hat und zur Domain im From: passt. policy=quarantine ist die Richtlinie, die die Domain veröffentlicht hat.

Microsoft 365 schreibt dieselben Ergebnisse etwas anders. Dort kommen compauth (ein zusammengefasstes Urteil mit dreistelligem Grundcode) und action hinzu. Bei DMARC gibt es neben pass, fail und none auch bestguesspass: Die Domain hat keinen DMARC-Eintrag, hätte aber bestanden, wenn sie einen hätte. Die Codes erklärt Microsoft in der Dokumentation zu den Anti-Spam-Kopfzeilen.

dkim=pass heißt nicht, dass die Mail vom Absender im From: signiert wurde. Es heißt nur, dass irgendeine Domain sie signiert hat und die Signatur stimmt. Welche, steht in header.d=.

DKIM-Signature: wer hat unterschrieben#

Die Felder der Signatur sind in RFC 6376 festgelegt. Für das Lesen genügen fünf:

• d= ist die Domain, die die Verantwortung übernimmt. Für DMARC muss sie zur Domain im From: passen, im Normalfall genügt dieselbe Hauptdomain.
• s= ist der Selektor. Unter s._domainkey.d liegt der öffentliche Schlüssel im DNS, hier also unter default._domainkey.elitegear.io. Wie man ihn abfragt und seine Länge prüft, steht in DKIM-Selector finden.
• h= zählt die Kopfzeilen auf, die mitsigniert sind. Steht from doppelt, kann niemand nachträglich ein zweites From: einschieben.
• bh= ist der Prüfwert des Inhalts. Ändert ein Server unterwegs den Text, etwa durch eine angehängte Fußzeile, scheitert die Signatur mit „body hash did not verify“.
• t= ist der Zeitpunkt der Signatur in Sekunden seit 1970. 1789972541 ist der 21.09.2026, 06:35:41 UTC, und passt zu Schritt 3.

Viele Mails tragen mehr als eine Signatur. In meinem Posteingang waren es 119 von 600 mit je zwei, bei 92 davon eine des Absenders und eine des Versanddienstes. Das ist in Ordnung, solange eine davon zum From: passt, und das war bei allen 119 der Fall.

In 29 Mails passte keine. 15 davon trugen nur eine Signatur für eine Domain der Form firmenname-at.<datum>.gappssmtp.com. Diese Domain liegt bei Google, nicht beim Absender. 13 weitere trugen nur die gemeinsame Signaturdomain eines Hosters. Bei allen 29 stand dkim=pass, und trotzdem zählt die Signatur für DMARC nicht. Kommen diese Absender durch, dann nur, weil SPF für ihre Domain passt. Fällt SPF einmal weg, etwa bei einer Weiterleitung, hängt die Mail in der Luft. Abhilfe ist ein eigener DKIM-Schlüssel beim Mailanbieter. Wie man ihn einrichtet, steht in DMARC einrichten.

ARC: der Stempel der Zwischenstation#

Die drei Zeilen mit ARC- stammen nicht vom Absender. Im Beispiel hat sie der empfangende Server des Hosters geschrieben, signiert mit d=cyberscale.io. ARC (RFC 8617) hält fest, wie eine Mail bei ihrer Ankunft geprüft wurde, und versiegelt das. So kann ein späterer Server das ursprüngliche Ergebnis noch sehen, wenn eine Weiterleitung oder Mailingliste unterwegs SPF oder DKIM gebrochen hat.

i=1 ist die erste Station, die siegelt. cv=none heißt, dass vorher keine Kette da war. cv=pass oder cv=fail sagt, ob die vorhandene Kette geprüft werden konnte. RFC 8617 ist als experimentell eingestuft. Ob ein Empfänger ARC berücksichtigt, entscheidet er selbst. In meinem Posteingang tragen 598 von 600 Mails ARC-Zeilen, weil mein eigener Anbieter sie anbringt. Über den Absender sagt das nichts.

Spam-Bewertung und Herstellerzeilen#

Zeilen, die mit X- beginnen, gehören keinem Standard. Jeder Server darf sie setzen, auch der Absender.

• X-Spam-Status: No, score=-5.01 und X-Spamd-Bar: ----- stammen hier vom Spamfilter Rspamd beim Hoster. Die Zeile folgt dem Muster von SpamAssassin, der Balken zeigt ein Minus je Punkt unter null. Negative Werte heißen „unverdächtig“.
• X-Forefront-Antispam-Report und X-Microsoft-Antispam setzt Microsoft 365. Dort steht unter anderem SFV:NSPM (kein Spam), SFV:SPM (Spam) oder CAT: mit der Art der Bedrohung. Microsoft schreibt selbst, dass der SCL-Wert in der Cloud nicht über den Spam-Ordner entscheidet. Dafür sind CAT und DIR maßgeblich.

Steht in einer Mail ein X-Spam-Status mit einem fremden Servernamen, hat ihn ein anderer Server oder der Absender geschrieben. Wie bei Authentication-Results gilt nur, was der eigene Anbieter oben angefügt hat.

Messung: 600 Mails aus dem eigenen Posteingang#

In eigener Sache: Am 04.10.2026 habe ich die Kopfzeilen der letzten 600 Mails in meinem Posteingang admin@cyberscale.io ausgewertet, vom 20.09. bis 03.10.2026, nur lesend über IMAP. Das sind überwiegend Benachrichtigungen (GitHub, Netlify, Upwork, Newsletter) und wenige persönliche Mails. Repräsentativ ist das nicht. Es zeigt aber, was in einem gewöhnlichen Geschäftspostfach im Header steht.

• Weg: Der Median liegt bei drei Received-Zeilen, die Übergabe ins Postfach mitgezählt. 128 Mails hatten zwei, 14 hatten fünf oder sechs.
• Dauer: Von der untersten bis zur obersten Received-Zeile vergingen im Median 5 Sekunden, bei neun von zehn Mails höchstens 7. 13 brauchten länger als eine Minute, alle von Newsletter-Plattformen und Benachrichtigungsdiensten. Die langsamste brauchte 2.199 Sekunden, gut 36 Minuten. Die Zeit verging bei allen 13 zwischen den beiden untersten Zeilen, also beim Versender, bevor die Mail sein Netz verließ.
• Prüfung: Mein Anbieter vermerkte bei 559 Mails dmarc=pass. Bei 39 stand dmarc=none, weil die Absenderdomain keinen DMARC-Eintrag hat. Bei 2 fehlte die Prüfzeile ganz.
• Signatur: 559 trugen eine DKIM-Signatur für die eigene Domain, 29 nur für eine fremde (siehe oben), 12 gar keine.
• Antwortadresse: 369 hatten ein Reply-To. Bei 16 zeigte es auf eine andere Organisation als das From:, etwa bei Formular-Benachrichtigungen, die direkt an den Einsender antworten. Ein abweichendes Reply-To allein ist also kein Alarmzeichen. Verdächtig wird es zusammen mit dmarc=fail oder einer Zahlungsaufforderung.

Namen von Absendern veröffentliche ich nicht.

Was zu tun ist#

1. Den ganzen Header öffnen, nicht die Kurzansicht des Mailprogramms.
2. Die oberste Authentication-Results-Zeile deines Anbieters suchen und spf=, dkim= und dmarc= lesen. Bei dmarc=fail ist die Absenderangabe nicht belegt.
3. header.d= mit der Domain im From: vergleichen. Passen sie nicht zusammen, hat jemand anders signiert.
4. Die Received-Zeilen von unten nach oben lesen und alle Zeiten auf UTC umrechnen. Bei Verzögerungen die Lücke suchen.
5. Bei der eigenen Domain den Stand von SPF, DKIM und DMARC im E-Mail-Check prüfen. Kommt eine eigene Mail gar nicht an, hilft der Rückläufer weiter; wie man ihn liest, steht in E-Mail abgelehnt: 550 5.7.1.

Was nicht hilft#

Die unterste Received-Zeile als Herkunft nehmen. Sie ist die einzige, die der Absender ganz allein schreibt.

dkim=pass als Echtheitsbeweis lesen, ohne auf header.d= zu schauen. Signieren kann jede Domain.

Einer Authentication-Results-Zeile mit fremder Kennung glauben. Sie ist eine Behauptung des Servers, der sie geschrieben hat.

X--Zeilen als Beleg nehmen. X-Spam-Status: No kann jeder Absender in seine Mail schreiben.

Den Header samt Text in ein fremdes Online-Werkzeug kopieren. Wer einen Analysedienst nutzt, gibt nur die Kopfzeilen weiter. Der Text der Mail gehört nicht dazu, und auch der Header enthält Adressen und interne Servernamen.

Häufige Fragen#

Wie lese ich einen E-Mail-Header?#

Von unten nach oben: Die unterste Received-Zeile ist der Anfang des Weges, die oberste die Zustellung ins Postfach. Das Prüfergebnis steht in der Authentication-Results-Zeile deines eigenen Anbieters, meist weit oben.

Woran sehe ich, von welchem Server eine Mail wirklich kam?#

An der Received-Zeile, die dein eigener Anbieter als erste geschrieben hat. Dort steht in Klammern die IP-Adresse, von der die Mail tatsächlich übergeben wurde. Alles darunter haben andere Server oder der Absender selbst geschrieben.

Was bedeutet dkim=pass, aber dmarc=fail?#

Die Signatur ist gültig, gehört aber zu einer anderen Domain als der im From:, und SPF passt auch nicht zur angezeigten Domain. Für DMARC zählt nur eine Prüfung, die zur sichtbaren Absenderdomain passt.

Warum stehen im Header verschiedene Zeitzonen?#

Jeder Server schreibt die Zeit in seiner eigenen Zeitzone, das Date: stammt vom Absender. Erst nach dem Umrechnen auf UTC ergibt die Reihenfolge Sinn.

Wenn du es nicht selbst machen willst#

In eigener Sache: cyberscale bin ich, Stefan Haun aus Tirol. Das Paket E-Mail-Schutz bringt SPF, DKIM und DMARC beim bestehenden Anbieter in Ordnung, einschließlich eines eigenen DKIM-Schlüssels statt der Signatur des Anbieters. Vorher kostenlos selbst prüfen: der E-Mail-Check.

Stand 04.10.2026. Quellen an diesem Tag abgerufen, Auswertung des Posteingangs am selben Tag.

Quellen#

• RFC 5321: SMTP, Abschnitt 4.4: Received-Zeilen werden am Anfang eingefügt und nicht verändert, Return-Path bei der Zustellung
• RFC 5322: Internet Message Format: From, Date, Message-ID, Reply-To und Ablaufzeilen
• RFC 3848: ESMTP and LMTP Transmission Types: ESMTPS, ESMTPA, ESMTPSA, LMTP
• RFC 8601: Authentication-Results, Abschnitte 4.1 und 5: nur Zeilen mit eigener Kennung auswerten, fremde mit eigener Kennung an der Grenze löschen
• RFC 6376: DKIM, Abschnitt 3.5: d=, s=, h=, bh=, b=, t=
• RFC 9989: DMARC, Abschnitt 3.2.10: Abgleich der Domains (Alignment)
• RFC 8617: ARC (experimentell): ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results, i=, cv=
• Microsoft: Anti-spam message headers: X-Forefront-Antispam-Report, SCL, SFV, CAT, compauth, bestguesspass
• Rspamd: Milter headers module: X-Spamd-Bar und X-Spam-Status
• Eigene Auswertung: Kopfzeilen der letzten 600 Mails im Posteingang von admin@cyberscale.io (20.09. bis 03.10.2026), am 04.10.2026 per IMAP nur lesend abgerufen. Veröffentlicht werden nur Summen, keine Absender. Beispielheader: eigene Mail vom 21.09.2026, gekürzt, eine doppelte Zeile gestrichen, Zeilenumbrüche für die Lesbarkeit verschoben.