Beliebte Tools

Design

E-Mail-Header-Analyzer

Der Email Header Analyzer zeigt, welchen Weg eine E-Mail genommen hat, wie lange jeder Hop gedauert hat und was die SPF-, DKIM- und DMARC-Prüfungen Ihres Providers gemeldet haben. Fügen Sie dazu einfach die Header ein.

Im Browser gelesen · nur öffentliche Server-IPs werden nachgeschlagen, die Absender-Domain nur auf Ihren Wunsch · nichts wird gespeichert

Ihre Header verlassen Ihr Gerät nie. Nur die unter dem Ergebnis aufgelisteten IP-Adressen und Domains werden nachgeschlagen.

Was Sie sehen werden

  • Wer wirklich gesendet hat, beurteilt allein nach den eigenen Prüfungen Ihres Providers
  • Jeder Server auf dem Weg, die Verzögerung bei jedem und ob er TLS genutzt hat
  • SPF, DKIM, DMARC und ARC, und ob sie zur From-Adresse passen
  • Lookalike-Domains, gefälschte Ergebnisse und weitere Anzeichen, jedes mit seinem Beleg
  • Spam-Header von Microsoft 365, Gmail und SpamAssassin, entschlüsselt
  • Die Regeln von Gmail und Yahoo für Massenversender, einschließlich One-Click-Abmeldung

Was ist ein E-Mail-Header?

Ein E-Mail-Header ist der Block von Zeilen über dem Nachrichtentext: wer sie gesendet hat und an wen, wann, und ein Protokoll jedes Servers, der sie bearbeitet hat. Mail-Apps verstecken das meiste davon; „Original anzeigen“ oder „Quelltext anzeigen“ zeigt alles.

Jede Zeile besteht aus einem Namen, einem Doppelpunkt und einem Wert; ein langer Wert setzt sich in Zeilen fort, die mit einem Leerzeichen beginnen (RFC 5322). Die Header enden an der ersten Leerzeile. Alles danach ist der Nachrichtentext, den dieses Tool nie liest.

Drei Arten von Autoren schreiben sie: die App des Absenders (From, To, Subject, Date), jeder Server auf dem Weg (je eine Received-Zeile) und Ihr Provider (Authentication-Results, Spam-Urteile). Nur Letztere werden von jemandem geprüft, dem Sie vertrauen.

Das Newsletter-Beispiel30 Felder · 4,6 KB

Hinzugefügt von Ihrem Provider (Google)11 Felder

  1. 1Delivered-To: reader@example.com
  2. 2Received: by 2002:a05:6214:5a0b:… with SMTP id kq11csp1342871qvb; Wed, 21 Oct 2026 07:02:48 -0700
  3. 3–7 X-Google-Smtp-Source, X-Received, ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results
  4. 8Return-Path: <bounces+48213-9f1c-reader=example.com@sendgrid.net>
  5. 9Received: from o1.ptr1234.example.org ([167.89.118.37]) by mx.google.com with ESMTPS id …; Wed, 21 Oct 2026 07:02:47 -0700
  6. 10Received-SPF: pass (google.com: domain of …@sendgrid.net designates 167.89.118.37 as permitted sender) client-ip=167.89.118.37;
  7. 11Authentication-Results: mx.google.com; dkim=pass …; dkim=pass …; spf=pass …; dmarc=pass …

Hinzugefügt von Servern unterwegs (SendGrid, example.org)5 Felder

  1. 12DKIM-Signature: v=1; a=rsa-sha256; d=example.org; s=s1; h=content-type:from:…
  2. 13DKIM-Signature: v=1; a=rsa-sha256; d=sendgrid.info; s=smtpapi; h=content-type:from:…
  3. 14Received: by filterdrecv-7d9c8b5f6-2kqzr with SMTP id … 2026-10-21 14:02:13.517 +0000 UTC
  4. 15Received: from app-01.example.org ([198.51.100.24]) by geopod-ismtpd-3 (SG) with ESMTPSA id …; Wed, 21 Oct 2026 14:02:12.902 +0000
  5. 16Received: from localhost ([127.0.0.1]) by app-01.example.org (Postfix) with ESMTP id 4Xc9Fq2Lb1z9vKs; Wed, 21 Oct 2026 14:02:10 +0000

Von der App des Absenders geschrieben14 Felder

  1. 17Content-Type: multipart/alternative; boundary=8a1f4c2e9b7d3a6c5e0f
  2. 18Date: Wed, 21 Oct 2026 14:02:04 +0000 (UTC)
  3. 19From: Example Weekly <news@example.org>
  4. 20Mime-Version: 1.0
  5. 21Message-ID: <3qX0b1wZTcO2pN9sKd4ZfA@geopod-ismtpd-3>
  6. 22Subject: This week at Example: five things worth reading
  7. 23List-Unsubscribe: <https://u48213.ct.sendgrid.net/lu/unsubscribe?…>, <mailto:unsubscribe@example.org?…>
  8. 24List-Unsubscribe-Post: List-Unsubscribe=One-Click
  9. 25–29 List-Id, Feedback-ID, X-SG-EID, X-SG-ID, X-Entity-ID
  10. 30To: reader@example.com

Leerzeile: Hier beginnt der Nachrichtentext, den dieses Tool nie liest

Gekürzt: eine Zeile pro Feld, nummeriert wie in den Headern. Farben wie im Ergebnis: Ihr Provider, Server unterwegs, der Absender.
E-Mail-Header-Analyzer: Ergebnis für eine PayPal-Lookalike-Nachricht mit Urteil, Befunden und Zustellweg mit 41 Minuten PauseE-Mail-Header-Analyzer: Ergebnis für eine PayPal-Lookalike-Nachricht mit Urteil, Befunden und Zustellweg mit 41 Minuten PauseDas UrteilWer gesendet hat, beurteilt allein nach den Authentication-Results Ihres Providers, mit dem Server, der geprüft hat.Was auffälltJeder Befund mit Schweregrad, Begründung und der genauen Header-Zeile, aus der er stammt.Der ZustellwegJeder Server vom Date-Header bis zum Posteingang, die Abstände maßstabsgetreu und die Vertrauensgrenze darüber.Die FaktenWie lange die Zustellung gedauert hat, wie viele Hops es waren, ob jeder externe Hop TLS nutzte und welchen Ordner Microsoft gewählt hat.
Das verdächtige Beispiel: Die eigenen Prüfungen von Microsoft 365 bestätigen den Absender nicht, die Befunde nennen ihre Belege und der Weg zeigt, wo die Nachricht gewartet hat. Wählen Sie eine Nummer, um zu sehen, was der jeweilige Teil zeigt.

E-Mail-Header auslesen: von unten nach oben lesen

Um E-Mail-Header zu analysieren, lesen Sie die Received-Zeilen von unten nach oben. Jeder Server setzt seine Zeile über die bereits vorhandenen, die unterste ist also der erste Hop, und die oberste ist Ihr Provider, der die Nachricht an das Postfach übergibt (RFC 5321 §4.4).

Eine Zeile nennt, wer empfangen hat (by), von welchem Server und welcher Adresse (from, die auf der Verbindung gesehene Adresse), wie (with: ESMTPS bedeutet STARTTLS, ESMTPSA STARTTLS plus Anmeldung) und wann. Server stempeln ihre eigene Ortszeit, rechnen Sie also jede in UTC um, bevor Sie subtrahieren: 07:02:47 -0700 ist 14:02:47 UTC.

Sicher sind nur die Zeilen, die Ihr Provider geschrieben hat. Alles unter seiner ersten Zeile stammt von Servern, die Sie nicht prüfen können, und ein Absender kann eigene Zeilen hinzufügen.

Im Header · oben ist am neuesten

Die Reise · Hop 1 zuerst

#2 by 2002:a05:6214:5a0b:…with SMTP id kq11csp…07:02:48 -0700
5Google intern14:02:48 UTC+1 s
#9 from o1.ptr1234.example.org [167.89.118.37]by mx.google.com with ESMTPS07:02:47 -0700
4mx.google.com14:02:47 UTC+33 s

Vertrauensgrenze

#14 by filterdrecv-7d9c8b5f6-2kqzrwith SMTP id filterd…2026-10-21 14:02:13.517 +0000 UTC
3SendGrid Filter14:02:13 UTC+0,6 s
#15 from app-01.example.org [198.51.100.24]by geopod-ismtpd-3 (SG) with ESMTPSA14:02:12.902 +0000
2SendGrid14:02:12 UTC+2,9 s
#16 from localhost [127.0.0.1]by app-01.example.org (Postfix) with ESMTP14:02:10 +0000
1app-01.example.org14:02:10 UTCerster

Nach oben lesen: Jeder Server fügt seine Zeile oben hinzu

Die fünf Received-Zeilen des Newsletters. Hop 1 ist die Newsletter-App; die 33 s zwischen SendGrid und Google sind der größte Abstand.

SPF, DKIM und DMARC im E-Mail-Header prüfen

SPF fragt, ob der sendende Server für die Envelope-Domain (den Return-Path) senden darf. DKIM fragt, ob eine Domain die Nachricht signiert hat und die Signatur noch passt. DMARC fragt, ob eine Domain mit bestandenem SPF oder DKIM zur From-Adresse passt, die Sie sehen.

Ihr Provider schreibt die Antworten in Authentication-Results. Vertrauen Sie dem Block, den Ihr Provider neben seiner eigenen Received-Zeile geschrieben hat. Andere Kopien, ARC-Kopien und alle, die zwischen den Zeilen des Absenders stehen, kann jeder hinzugefügt haben (RFC 8601).

Ein Pass belegt die Domain, nicht ihre Absichten: examp1e.com kann alle drei für sich selbst bestehen.

Authentication-Results, zerlegtNewsletter · danach das verdächtige Beispiel
Authentication-Results: mx.google.com;1

Wer geprüft hatdie authserv-id: der eigene Server Ihres Providers

dkim=pass header.i=@example.org header.s=s1 header.b=Xk3Pq9aZ;2

DKIM: example.org hat signiertsein Schlüssel liegt bei s1._domainkey.example.org

dkim=pass header.i=@sendgrid.info header.s=smtpapi …;3

Eine zweite Signaturdie des sendenden Dienstes; sie kann nicht zu example.org passen

spf=pass (google.com: … designates 167.89.118.37 as permitted sender) smtp.mailfrom=…@sendgrid.net;4

SPF: darf für sendgrid.net sendendie Envelope-Domain (Return-Path), nicht From

dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.org5

DMARC: Die From-Domain passt zu ②p=quarantine ist, was example.org Empfänger bei Fehlschlägen tun lässt

#3 Authentication-Results: spf=softfail (sender IP is 198.51.100.77) … dkim=none … dmarc=none action=none … compauth=fail reason=001ZähltMicrosoft 365 hat es geschrieben, über der ersten Received-Zeile, die es hinzugefügt hat.

Vertrauensgrenze

#7 Authentication-Results: protection.outlook.com; spf=pass … dkim=pass … dmarc=pass action=none … compauth=pass reason=100IgnoriertEs nennt Microsoft, steht aber unter jeder Received-Zeile: Es kam mit der Nachricht. Ein Empfänger schreibt dort nie.
Unter der Linie: die beiden Authentication-Results des verdächtigen Beispiels. Die Position entscheidet, welches zählt.

Ist diese E-Mail echt oder gefälscht?

Header können nicht sagen, ob ein Angebot ehrlich ist, aber sie zeigen, ob die From-Domain die Nachricht wirklich gesendet hat und ob sie eine fremde nachahmt. Beginnen Sie mit dem Urteil, das Ihr Provider geschrieben hat, und suchen Sie dann diese Anzeichen.

Keines davon beweist für sich allein Phishing, und mehrere häufige Abweichungen sind normal. Microsoft weist darauf hin, dass eine Lookalike-Domain SPF, DKIM und DMARC bestehen kann, wenn ihr Inhaber sie eingerichtet hat (Microsoft).

  • Eine From-Domain als LookalikeHoch

    paypa1-billing.examplestattpaypal.com

    Eine Ziffer oder ein ähnlicher Buchstabe wurde getauscht. Sie kann SPF, DKIM und DMARC für sich selbst bestehen.

  • Buchstaben aus einer anderen SchriftHoch

    xn--pypal-4ve.exampleerscheint alspаypal.example

    Das а ist kyrillisch. Header behalten die xn--Form (Punycode), die es verrät.

  • Ihr Provider meldet failHoch

    compauth=fail reason=001 · spf=softfail

    Der Empfänger konnte die From-Domain nicht dem Server zuordnen, der gesendet hat.

  • Ein Name, der eine andere Adresse enthältMittel

    "accounts@example.com" <notice@mailer.example>

    Apps zeigen den Namen, nicht die Adresse. Der wahre Absender steht in den Klammern.

  • Das eigene Urteil des FiltersMittel

    CAT:PHSH · dest:J · SFTY:9.25

    Microsoft hat es als Phishing eingestuft und in Junk abgelegt; 9.25 ist der Hinweis zum Erstkontakt.

  • Pass-Ergebnisse unter der LinieMittel

    #7 Authentication-Results: protection.outlook.com; spf=pass dmarc=pass

    Unter jeder Received-Zeile geschrieben, also hat der Absender es geschrieben. Nur die Ihres Providers zählen.

Normal, für sich genommen keine Warnzeichen

  • Return-Path weicht von From ab

    sendgrid.netstattexample.org

    E-Mail-Dienste senden für Sie; DKIM trägt die Übereinstimmung.

  • Reply-To weicht von From ab

    Reply-To: support@example.org

    Antworten gehen an einen Helpdesk. Nur dann einen Blick wert, wenn diese Domain eine andere nachahmt.

  • Eine Zeit, die rückwärts läuft

    09:47:12 → 09:47:11 (−1 s)

    Jeder Server stempelt seine eigene Uhr, und Uhren können um eine Sekunde oder mehr abweichen.

  • Ein Server in einem anderen Land

    CTRY:US · 209.85.208.54

    Dort steht der Server, nicht die Person. Große Provider senden von überall.

Anzeichen aus dem verdächtigen Beispiel und erfundenen Varianten. Keines beweist für sich allein Phishing.

Warum kam meine E-Mail verspätet an?

Ziehen Sie jede Received-Zeit von der darüberliegenden ab, in UTC. Der größte Abstand zeigt, wo die Nachricht gewartet hat. Ein Abstand von 30 Minuten oder mehr passt zu einem Wiederholungsversuch (RFC 5321 empfiehlt, mindestens 30 Minuten zu warten).

Der Date-Header stammt vom Gerät des Absenders, die Zeit vom Date bis zum ersten Server enthält also eine nachgehende Uhr oder einen Entwurf, der lange vor dem Senden geschrieben wurde. Zeiten können auch um eine Sekunde zurückspringen, wenn die Uhren zweier Server abweichen.

Kein Standard legt fest, wie lang zu lang ist.

Das verdächtige BeispielZeiten in UTC
Date-Header09:05:44 UTC
+7 s
mail.paypa1-billing.example09:05:51 · erster Server
41 Min. 21 s≥ 30 Min.: ein Wiederholungsversuch

Microsoft 365

  • 09:47:12Edge, erste Zeile
  • 09:47:11intern · −1 s
  • 09:47:13Mailbox-Server
  1. 09:05:44Date-Headerdie Uhr des Absenders
  2. +7 s
  3. 09:05:51mail.paypa1-billing.exampleerster Server
  4. 41 Min. 21 s≥ 30 Min.: passt zu einem Wiederholungsversuch
  5. 09:47:12Microsoft 365 Edgeerste Zeile, die Microsoft geschrieben hat
  6. −1 sUhren weichen ab
  7. 09:47:11Microsoft intern
  8. +2 s
  9. 09:47:13Microsoft Mailbox-Server
ab dem Date-Header
41 Min. 29 s
ab dem ersten Server
41 Min. 22 s
Das Newsletter-Beispiel · 44 swohin die Zeit ging
  • Date → erster Server 6 s
  • in SendGrid 2,9 s
  • SendGrid-Filter 0,6 s
  • SendGrid → Google, der größte Abstand 33 s
  • innerhalb von Google 1 s

Spam-Header von Microsoft 365 und Gmail, entschlüsselt

Microsoft 365 schreibt das Urteil seines Filters in X-Forefront-Antispam-Report: CAT ist das Urteil, SFV wie die Spam-Filterung entschieden hat, und X-Microsoft-Antispam-Mailbox-Delivery nennt den Ordner, in den die Nachricht ging.

SCL wird weiterhin geschrieben, aber laut Microsoft entscheidet er in Microsoft 365 nichts mehr: Lesen Sie stattdessen CAT (Microsoft). BCL bewertet Massenmail nach Beschwerden von 0 bis 9, und der Schwellenwert Ihrer Richtlinie (standardmäßig 7) entscheidet.

Gmail schreibt kein dokumentiertes Spam-Urteil. Server mit SpamAssassin fügen X-Spam-Status mit Score, Schwellenwert und den ausgelösten Regeln hinzu.

X-Forefront-Antispam-Reportdas verdächtige Beispiel
CIP:198.51.100.77CTRY:LANG:en3SCL:5SRV:5IPV:NLI2SFV:SPMH:mail.paypa1-billing.examplePTR:mail.paypa1-billing.example1CAT:PHSH4SFTY:9.25SFS:(13230040)(376014)(1800799024)(8096899003)6DIR:INB
  1. 1CAT:PHSH das Urteil: Phishing (SPM Spam, SPOOF, BULK, HPHSH…)
  2. 2SFV:SPM die Spam-Filterung hat es als Spam markiert (NSPM: kein Spam)
  3. 3SCL:5 eine Eingangsgröße der Filterung, in Microsoft 365 nicht die Entscheidung
  4. 4SFTY:9.25 der Sicherheitshinweis zum Erstkontakt wurde angezeigt
  5. 5IPV:NLI die IP steht auf keiner Reputationsliste
  6. 6DIR:INB eingehend; SFS und ARA sind interne Diagnosedaten von Microsoft

Bulk Complaint LevelBCL:0

01–3 wenige4–7 gemischt8–9 viele

Schwellenwerte 5 strict, 6 standard, 7 Standard: ab diesem Wert ist es Massenmail.

Wohin es gingdest:J

Junk-E-MailX-Microsoft-Antispam-Mailbox-Delivery

dest:I ist der Posteingang. ucf, jmr und ENG sind intern.

Gmail und SpamAssassin

Gmail schreibt kein dokumentiertes Spam-Urteil: X-Received, X-Google-Smtp-Source und X-Gm-* sind intern.

X-Spam-Status: No, score=2.307 required=6.31

SpamAssassin: Spam erst ab dem erforderlichen Score.

Jeder Wert aus dem verdächtigen Beispiel, gelesen mit den Anti-Spam-Header-Tabellen von Microsoft.

E-Mail-Header in Gmail, Outlook, Apple Mail und anderen finden

Kopieren Sie die vollständigen Header oder die ganze Originalnachricht an einem Computer oder in einem Webbrowser. Fügen Sie sie dann oben ein oder speichern Sie die Nachricht als .eml-Datei und laden Sie sie hoch.

Jede App versteckt sie in einem anderen Menü. Wählen Sie Ihre: Die Schritte folgen der jeweiligen Hilfeseite des Providers.

  1. 1Nachricht öffnen
  2. 2Mehr ⋮
  3. 3Original anzeigen
  4. 4In die Zwischenablage kopieren

Quelle: support.google.com/mail/answer/29436

Auf dem Handy? Die Apps von Gmail, Outlook und Apple Mail zeigen keine vollständigen Header. Öffnen Sie die Nachricht in einem Browser (Gmail, Outlook im Web) oder einer Desktop-App oder leiten Sie sie als Anhang weiter und laden Sie die .eml hier hoch.

E-Mail zurückverfolgen: was eine IP verrät und was nicht

Um eine E-Mail zurückzuverfolgen, nehmen Sie die from-Adresse in der ersten Received-Zeile, die Ihr Provider geschrieben hat: den Server, der die Nachricht übergeben hat. Schlagen Sie nach, wem er gehört, und Sie wissen, wessen Server das war, was ein Weiterleiter statt des ursprünglichen Absenders sein kann.

Die Header zeigen Mailserver und nur manchmal das eigene Netzwerk des Absenders, in X-Originating-IP.

Selbst diese Adresse verweist auf ein Netzwerk und grob ein Land, nie auf eine Person oder eine Straße.

Das Gmail → Outlook-Beispielaus Ihrem Browser nachgeschlagen
Anas Computernicht in den Headern
209.85.208.54mail-ed1-f54.google.com
Microsoft 365erste Received-Zeile, die es geschrieben hat

Was 209.85.208.54 Ihnen sagt

Inhaber
Google LLC · 209.85.128.0/17 (ARIN)
Land
Vereinigte Staaten, wo der Server steht
Rolle
ein sendender Gmail-Server, der, den SPF geprüft hat

Was sie Ihnen nicht sagen kann

Wer
Ana oder jemand anderes bei example.net
Wo
ihre Stadt oder Straße
Gerät
ihr Computer oder Handy
Der Analyzer schlägt nur die öffentlichen Adressen der Server bei ihrer Registry nach und zeigt genau, was er gefragt hat.

E-Mail-Header: Fragen und Antworten

Wie kann ich einen Header analysieren?

Kopieren Sie die vollständigen Header aus Ihrer Mail-App, fügen Sie sie oben ein und wählen Sie „Header analysieren“. Die Analyse liest sie dann von unten nach oben: das Urteil, das Ihr Provider geschrieben hat, den Weg Server für Server mit der Verzögerung bei jedem und die Befunde mit ihren Belegen.

Ist es unbedenklich, E-Mail-Header hier einzufügen?

Die Header werden in Ihrem Browser gelesen und nie an uns gesendet. Nachgeschlagen werden nur die öffentlichen Server-IPs: ihr Inhaber bei den Registries (RDAP, von Ihrem Browser abgefragt) und ihr Land aus DB-IP-Dateien, die von unserer eigenen Website geladen werden, unser Server sieht also, welcher Adressbereich abgefragt wurde. Die Absender-Domain wird nur auf Ihren Wunsch bei dns.google nachgeschlagen. Header enthalten Adressen und Servernamen, geben Sie sie also mit Bedacht weiter.

Lassen sich E-Mail-Header fälschen?

Ja: alles, was geschrieben wurde, bevor Ihr Provider die Nachricht übernommen hat. Jeder Server setzt seine Zeile obenauf, daher kann ein Absender gefälschte Received-Zeilen darunter und sogar ein gefälschtes Authentication-Results mit pass einfügen. Die eigenen Zeilen Ihres Providers oben und die Ergebnisse, die er daneben geschrieben hat, sind der Teil, dem Sie vertrauen können; der Analyzer zeigt den Rest als Behauptungen.

Woran erkenne ich, ob eine E-Mail gefälscht ist?

Beginnen Sie mit den Authentication-Results Ihres Providers: Ein DMARC fail oder in Microsoft 365 ein compauth fail bedeutet, dass die From-Domain nicht bestätigt wurde. Lesen Sie dann die Domain selbst: Eine Lookalike-Domain wie paypa1-billing.example kann jede Prüfung für sich selbst bestehen. Sehen Sie zuletzt nach, wohin Antworten gehen und welcher Server die Nachricht übergeben hat; der Analyzer listet jeden Befund mit seinem Beleg auf.

Kann ich die IP-Adresse des Absenders aus einer E-Mail herausfinden?

Sie finden den Server, der die Nachricht an Ihren Provider übergeben hat: die from-Adresse in der ersten Received-Zeile Ihres Providers, die, die SPF geprüft hat. Es ist meist ein Mailserver, nicht der Computer der Person. Manche Provider fügen außerdem X-Originating-IP hinzu, meist das Gerät oder Netz des Absenders, und selbst das verweist auf ein Netz und ungefähr ein Land, nie auf eine Person.

Warum zeigt Gmail die IP-Adresse des Absenders nicht an?

Nachrichten, die aus dem Web und den Apps von Gmail gesendet werden, tragen meist nur die Server von Google: Die erste Received-Zeile hat keinen from-Teil, daher steht die eigene Adresse des Absenders nicht in den Headern. Die Adresse, die Sie sehen können, gehört dem Google-Server, der die Nachricht weitergegeben hat, dem, den SPF geprüft hat; eine Abfrage zeigt also Google als Inhaber, nicht das Netz des Absenders.

SPF hat bestanden, warum ist DMARC trotzdem fehlgeschlagen?

SPF prüft die Envelope-Domain (Return-Path), die von dem From abweichen kann, das Sie sehen. DMARC verlangt, dass SPF oder DKIM für eine Domain bestehen, die zu From passt, genau oder innerhalb derselben Organisation; gehört die bestandene Domain jemand anderem, etwa der Bounce-Domain eines E-Mail-Dienstes, schlägt DMARC fehl. Eine DKIM-Signatur der From-Domain besteht DMARC allein.

Was bedeutet eine negative Verzögerung zwischen Hops?

Ein späterer Server hat eine frühere Zeit gestempelt als der davor. Jeder Server schreibt die Zeit seiner eigenen Uhr, und diese Uhren können abweichen, daher zeigt der Analyzer eine Uhrenabweichung statt einer Verzögerung. Zeiten in den Zeilen unter denen Ihres Providers können auch gefälscht sein, behandeln Sie daher ihre Reihenfolge und Abstände als Behauptungen.

Was bedeuten SCL und BCL?

Beides sind Scores von Microsoft 365 in dessen Anti-Spam-Headern. BCL bewertet Massenmail nach ihrem Beschwerdeniveau, von 0 (nicht von einem Massenversender) bis 9. SCL wird weiterhin geschrieben, ist in Microsoft 365 aber eine Eingangsgröße der Filterung, nicht die Entscheidung: CAT trägt das Urteil, und SFV sagt, wie die Spam-Filterung die Nachricht behandelt hat.

Zeigen E-Mail-Header BCC-Empfänger?

Nein. Blindkopien werden nie in die Header geschrieben: Der sendende Server liefert sie über den Envelope aus, und die Zeilen To und Cc zeigen nur die sichtbaren Empfänger. Eine for-Klausel in einer Received-Zeile kann einen Empfänger nennen, weshalb Server sie nur mit Vorsicht verwenden sollen. Delivered-To kann außerdem das Postfach zeigen, das die Nachricht erreicht hat.

Ist das dasselbe wie der Message Header Analyzer von Microsoft?

Nein. Der Message Header Analyzer von Microsoft ist ein Outlook-Add-in und eine Webseite, die die Header einer Nachricht dekodiert. Dieses Tool liest dieselben Microsoft-Header und außerdem die von Gmail, die von SpamAssassin und den Weg jedes Hops, entscheidet nach ihrer Position, welchen Ergebnissen es vertraut, und läuft vollständig in Ihrem Browser.

Warum gibt es mehrere Authentication-Results-Header?

Jeder Server, der eine Nachricht prüft, kann einen hinzufügen, und Absender können gefälschte hinzufügen, daher trägt eine Nachricht oft mehrere. Nur der, den Ihr Provider geschrieben hat, zählt: oben, neben seiner eigenen Received-Zeile, mit dem Namen seines eigenen Servers. ARC-Authentication-Results sind Ergebnisse, die ein Weiterleiter versiegelt hat, damit der nächste Server sehen kann, was bestanden hat, bevor die Weiterleitung die Nachricht veränderte.

Fehlt Ihnen etwas?Funktion oder neues Tool vorschlagen

Weitere E-Mail-Tools