Werkzeug AT-W31REV. 2026-A
E-Mail-Header-Analyse: Warum landete die Mail im Spam oder kam zu spät?
Warum eine Mail im Spam landete oder eine halbe Stunde zu spät kam, steht fast immer in ihrem Kopf. Lesen lässt er sich schwer: Jeder Server schreibt eine Zeile dazu, oben die neueste. Die Header-Analyse zerlegt den Kopf, rechnet die Verzögerung je Station aus und übersetzt SPF, DKIM, DMARC, ARC und die Spam-Werte von Microsoft 365 und SpamAssassin in Klartext. Sie fügen den Kopf ein, den Rest erledigt Ihr Browser.
- kostenlos
- ohne Anmeldung
- liest nur im Browser
01 / ANALYSE
Kopf einfügen, Ursache lesen
Analyse · Kopf einer empfangenen Mail
Die Analyse liest, was im Kopf der Mail steht, und erklärt es. Signaturen rechnet sie nicht nach, und was ein Postfachanbieter nicht hineinschreibt, kann sie nicht sehen. Gebaut ist sie für die Frage, warum eine Mail im Spam landete oder zu spät kam, nicht für die Frage, ob eine Mail betrügerisch ist.
Befunde
Weg der Mail
| Nr. | Von → an | Eingang | Dauer | TLS | Art |
|---|
SPF, DKIM, DMARC und ARC
| Prüfung | Ergebnis | Domain | Bedeutung |
|---|
Absender-Angaben
Spam-Werte
Abmelden (List-Unsubscribe)
Alle Kopfzeilen
| Name | Inhalt |
|---|
Liest nur in Ihrem Browser. Der Kopf wird nicht gesendet und nicht gespeichert.
02 / ANLEITUNG
So kommen Sie an den Kopf der Mail
Den Kopf (englisch Header) hat jede Mail, nur zeigt ihn kein Mailprogramm von sich aus. Entscheidend ist, welchen Sie nehmen: den der Mail, wie sie beim Empfänger angekommen ist. Im Gesendet-Ordner fehlt fast alles, was hier zählt, denn die Stempel der Server und die Prüfergebnisse kommen erst unterwegs dazu.
Landen Ihre eigenen Mails bei einem Kunden im Spam, bitten Sie ihn um den Kopf. Oder Sie schicken eine Testmail an ein eigenes Konto bei Gmail oder Outlook.com und nehmen den Kopf von dort. Die Werte von Microsoft 365 (SCL, BCL, CAT) sehen Sie halt nur in einem Postfach bei Microsoft.
| Programm | So geht es |
|---|---|
| Outlook (klassisch, Windows) | Mail per Doppelklick in einem eigenen Fenster öffnen, dann Datei > Eigenschaften. Der Kopf steht im Feld „Internetkopfzeilen". Hineinklicken, Strg+A, Strg+C. |
| Neues Outlook und Outlook im Web | Mail öffnen, oben auf „Weitere Aktionen" (drei Punkte), dann Anzeigen > Nachrichtendetails anzeigen. Alles markieren und kopieren. |
| Gmail | Mail öffnen, neben „Antworten" auf die drei Punkte, dann „Original anzeigen". Am besten „In Zwischenablage kopieren" nutzen; die ganze Seite geht auch. |
| Apple Mail (Mac) | Mail auswählen, dann im Menü Darstellung > E-Mail > Rohquelle. Alles markieren und kopieren. |
| Thunderbird | Mail auswählen, dann Ansicht > Nachrichten-Quelltext (Strg+U). Alles markieren und kopieren. |
| Handy | Die Apps zeigen den Kopf meist nicht. Öffnen Sie das Postfach im Browser am Rechner, oder leiten Sie die Mail als Anhang an einen Rechner weiter. |
Der Kopf enthält Adressen, IP-Adressen und den Betreff. Die Analyse liest ihn nur in Ihrem Browser. Wenn Sie ihn jemandem schicken, dürfen Sie den Betreff vorher gern kürzen; für die Auswertung zählt er nicht.
Quellen: Microsoft-Support: Internetkopfzeilen in Outlook anzeigen · Google-Hilfe: Nachrichten mit vollständigen Headern zurückverfolgen
03 / WEG DER MAIL
Received-Zeilen von unten nach oben lesen
Jeder Server, der eine Mail annimmt, setzt eine Received-Zeile oben auf den Kopf (RFC 5321, Abschnitt 4.4). Darin steht, von wem er sie bekam, wer er selbst ist, wie die Verbindung lief und wann. Die unterste Zeile ist also die erste Station, die oberste die letzte. Aus den Zeitstempeln zweier Nachbarn ergibt sich, wie lange die Mail zwischen ihnen lag.
Im Beispiel rechts schreibt ein Kunde um 10:02:08 Uhr über den Webmailer von GMX. GMX übernimmt nach 1 s, der Server des Autohauses erst nach 32 min. Den Grund schreibt er selbst dazu: Greylisting, 31 min lang.
Dass sich das Nachmessen lohnt, zeigte schon 2005 eine Messung mit Testmails an Tausende Domains: Ein Teil ging ohne jede Rückmeldung verloren, manche Mails brauchten Tage Afergan und Beverly 2005. Der häufigste Grund für eine spürbare Verzögerung ist heute harmloser.
Typische Verzögerungen und woran Sie sie erkennen
| Ursache | Im Kopf | Dauer |
|---|---|---|
| Greylisting beim Empfänger | Große Lücke an der ersten Station beim Empfänger, manchmal mit der Zeile X-Greylist | Minuten bis Stunden; Fenster nach RFC 6647 eine Minute bis 24 Stunden |
| Erneuter Versuch nach vorübergehendem Fehler | Große Lücke an einer Übergabe, ohne weiteren Hinweis | Mindestens 30 Minuten je Versuch nach RFC 5321; aufgegeben wird nach 4 bis 5 Tagen |
| Warteschlange oder Filter | Lücke zwischen zwei Stationen desselben Systems | Sekunden bis Stunden |
| Quarantäne bei Microsoft 365 | SFV:SKQ in X-Forefront-Antispam-Report | bis zur Freigabe |
| Postausgang beim Absender | Date liegt deutlich vor der ersten Received-Zeile | beliebig |
| Uhren der Server | Negative Dauer zwischen zwei Stationen | Sekunden bis Minuten, keine echte Verzögerung |
Die Analyse meldet eine Station ab 2 min als spürbar und ab 30 min als deutlich verspätet; ab dort hat meist mindestens ein Zustellversuch nicht geklappt. Quellen: RFC 5321 · RFC 6647
Greylisting weist Mail von unbekannten Absendern beim ersten Versuch vorübergehend ab. Ordentliche Server versuchen es später erneut, viele Spam-Programme nicht. Deshalb ist das Verfahren weit verbreitet Pagani u. a. 2016. Wie lange die Mail dann wartet, entscheidet allerdings der Absender: RFC 5321 empfiehlt mindestens 30 Minuten bis zum nächsten Versuch, und gerade bei Meldungen zu Greylisting und Sperrlisten verhalten sich die meisten großen Anbieter nicht so, wie sie sollten Li u. a. 2026. Eine halbe Stunde bei der ersten Mail eines neuen Absenders ist also normal. Kommt jede Mail so spät, lohnt der Blick auf den Server des Empfängers.
Jeder Zeitstempel stammt von einer anderen Uhr. Gehen zwei Server ein paar Sekunden auseinander, ergibt das schon mal eine negative Dauer; Uhrsprünge und Gangunterschiede zwischen Rechnern sind häufiger, als man denkt Paxson 1998. Die Analyse meldet das als Hinweis und nicht als Fehler der Mail.
Verschlüsselung je Station
Ob eine Strecke verschlüsselt war, steht in der Received-Zeile: ESMTPS (das S steht für STARTTLS, RFC 3848), „using TLSv1.3" bei Postfix oder „version=TLS1_2" bei Microsoft. Die Analyse wertet das für jede Station einzeln aus, denn eine verschlüsselte erste Station sagt nichts über die zweite. Große Anbieter verschlüsseln von sich aus, bei kleineren Servern klappte das 2015 nur bei gut einem Drittel Durumeric u. a. 2015. Verschlüsselt heißt außerdem nicht geprüft: Viele Server kontrollieren das Zertifikat der Gegenseite gar nicht Foster u. a. 2015. Steht dort TLS 1.0 oder 1.1, ist der Server veraltet Holz u. a. 2016. Google verlangt TLS seit 2024 von allen Absendern.
04 / PRÜFERGEBNISSE
SPF, DKIM, DMARC und ARC im Kopf lesen
Was der Empfänger geprüft hat, schreibt er in die Zeile Authentication-Results (RFC 8601). Vorn steht, wer geprüft hat, etwa mx.google.com; Microsoft lässt diesen Teil weg. Dahinter folgen die Verfahren mit ihrem Ergebnis, etwa spf=pass, dkim=fail oder dmarc=pass. Die meisten Empfänger prüfen tatsächlich, SPF bis zu 85 Prozent Deccio u. a. 2021, und richten sich nach dem Ergebnis.
| Ergebnis | SPF | DKIM | DMARC |
|---|---|---|---|
| pass | Der sendende Server steht im SPF-Eintrag der Umschlag-Domain. | Die DKIM-Signatur ist gültig: Die Mail wurde nach dem Signieren nicht verändert. | DMARC bestanden: SPF oder DKIM bestand für eine Domain, die zum Absender passt. |
| fail | Der sendende Server steht nicht im SPF-Eintrag, und die Domain verlangt Abweisung (-all). | Die DKIM-Signatur passt nicht mehr, meist weil unterwegs Text oder Betreff verändert wurde. | DMARC nicht bestanden: Weder SPF noch DKIM bestand für eine Domain, die zum Absender passt. |
| softfail | Der sendende Server steht nicht im SPF-Eintrag; die Domain bittet nur um Markierung (~all). | – | – |
| neutral | Der SPF-Eintrag macht über diesen Server keine Aussage (?all). | Die DKIM-Signatur ließ sich nicht auswerten (Syntaxfehler o. Ä.). | – |
| none | Die Umschlag-Domain hat keinen SPF-Eintrag. | Die Mail trägt keine DKIM-Signatur. | Die Absender-Domain hat keinen DMARC-Eintrag. |
| temperror | SPF ließ sich wegen eines vorübergehenden DNS-Fehlers nicht prüfen. | Der DKIM-Schlüssel ließ sich vorübergehend nicht abrufen. | Der DMARC-Eintrag ließ sich vorübergehend nicht abrufen. |
| permerror | Der SPF-Eintrag ist fehlerhaft, etwa doppelt vorhanden oder mit mehr als zehn Abfragen. | Die DKIM-Prüfung scheiterte dauerhaft, etwa weil der Schlüssel im DNS fehlt. | Der DMARC-Eintrag ist fehlerhaft. |
Quellen: RFC 8601 · RFC 7208 · RFC 9989
Ausrichtung: der häufigste Grund für dmarc=fail
DMARC reicht es nicht, dass SPF oder DKIM besteht. Die Domain, für die eines davon bestanden hat, muss zur Domain im Absender passen (RFC 9989; gemeint ist die Organisations-Domain, newsletter.ihre-firma.de passt also zu ihre-firma.de). Genau daran scheitern Newsletter-Dienste: Sie versenden mit eigenem Umschlag und eigener Signatur, SPF und DKIM bestehen, DMARC trotzdem nicht. Die Analyse zeigt deshalb neben jedem Ergebnis die Domain und sagt, ob sie passt. Was in Ihrem DNS steht, prüft der E-Mail-Check.
Weiterleitungen, Verteiler und ARC
Leitet ein Server eine Mail weiter, etwa ein Vereinsverteiler, bricht oft beides. SPF gilt nur noch für den Weiterleiter, und bekommt der Betreff ein „[Vorstand]" vorangestellt, passt die DKIM-Signatur nicht mehr. Messungen an 20 Weiterleitungsdiensten zeigen, wie gründlich Weiterleitung die Annahmen hinter SPF, DKIM und DMARC aushebelt Liu u. a. 2023.
ARC (RFC 8617) ist die Antwort darauf: Der Weiterleiter versiegelt, wie die Mail bei ihm ankam, und der nächste Empfänger kann das lesen. Gmail und Outlook werten ARC aus, und die meisten Umsetzungen arbeiten korrekt Wang und Wang 2022. Einen Anspruch darauf gibt es aber nicht. Ob ein Empfänger dem Siegel folgt, entscheidet er selbst; bei Gmail erkennen Sie es an „dis=NONE" trotz p=REJECT, bei Microsoft an compauth mit Grund 130. Die Analyse prüft den Aufbau der Kette (Instanzen, cv-Werte), die Signaturen selbst rechnet nur der Empfänger nach.
05 / SPAM-WERTE
SCL, BCL und Spam-Punkte: was die Filter in den Kopf schreiben
Ein Teil der Anbieter schreibt sein Urteil nachlesbar in den Kopf. Microsoft 365 tut das ausführlich, SpamAssassin und Rspamd auf den Servern vieler Hoster und Firmen ebenfalls. Gmail, Apple und GMX/WEB.DE tun es nicht oder nur in Zeilen, deren Inhalt sie nicht beschreiben. Solche Zeilen zeigt die Analyse roh an, ohne sie zu deuten.
Microsoft 365: Die Kategorie entscheidet, nicht der SCL
Microsoft schreibt in die Zeile X-Forefront-Antispam-Report, welche Regel gegriffen hat (CAT), was der Spam-Filter entschied (SFV) und den älteren Spam-Wert SCL von −1 bis 9. Seit Microsoft nach Kategorien filtert, sagt der SCL in der Cloud nichts mehr darüber, ob eine Mail als Spam gilt; maßgeblich sind CAT und DIR. Für Massenmail gibt es einen eigenen Wert, den BCL in X-Microsoft-Antispam.
| Wert | Bedeutung |
|---|---|
| SPM | Spam |
| HSPM | Spam mit hoher Sicherheit |
| BULK | Massenmail |
| SPOOF | Absender nicht bestätigt (Spoofing) |
| PHSH | Phishing |
| HPHSH | Phishing mit hoher Sicherheit |
| MALW | Schadsoftware |
| BCL | Bedeutung |
|---|---|
| 0 | keine Massenmail |
| 1 bis 3 | Massenversender mit wenigen Beschwerden |
| 4 bis 7 | Massenversender mit gemischt vielen Beschwerden |
| 8 bis 9 | Massenversender mit vielen Beschwerden |
Ab BCL 7 sortiert die Standardregel von Microsoft eine Massenmail in den Junk-Ordner, mit der Voreinstellung „Standard" ab 6, mit „Streng" ab 5 und dann in die Quarantäne. Ein BCL von 7 bei einem Newsletter heißt also: Je nach Einstellung des Empfängers landet er im Junk-Ordner oder knapp nicht.
| Wert | Bedeutung |
|---|---|
| BLK | Filter übersprungen und blockiert: Der Absender steht auf der Liste blockierter Absender des Empfängers. |
| NSPM | Der Spam-Filter hat die Mail als kein Spam eingestuft. |
| SFE | Filter übersprungen: Der Absender steht auf der Liste sicherer Absender des Empfängers. |
| SKA | Filter übersprungen: Der Absender steht in der Antispam-Regel auf der Liste erlaubter Absender oder Domains. |
| SKB | Als Spam markiert: Absender oder Domain stehen in der Antispam-Regel auf der Sperrliste. |
| SKI | Filter übersprungen: Die Absender-IP steht in der Liste erlaubter IP-Adressen. |
| SKN | Filter übersprungen wegen einer Nachrichtenfluss-Regel (Transportregel). |
| SKQ | Die Mail lag in der Quarantäne und wurde von dort freigegeben. |
| SKS | Schon vor dem Spam-Filter als Spam markiert, durch eine Transportregel oder einen lokalen Exchange-Server. |
| SPM | Der Spam-Filter hat die Mail als Spam markiert. |
Dazu kommt compauth in der Zeile Authentication-Results: Microsofts Gesamturteil zur Frage, ob die Mail von der Domain im Absender stammt. Es fasst SPF, DKIM, DMARC und eigene Signale zusammen. Ein compauth=fail mit Grund 001 bei einer Domain ohne DMARC-Regel ist der typische Anfang einer Einstufung als SPOOF.
| Grund | Bedeutung |
|---|---|
| 000 | DMARC nicht bestanden, und die Domain verlangt quarantine oder reject. |
| 001 | Implizit nicht bestanden: Die Domain hat keine Authentifizierung veröffentlicht oder nur eine schwache (SPF ~all oder ?all, DMARC p=none). |
| 100 | SPF oder DKIM bestanden, und die Domains von Umschlag und Absender passen zusammen. |
| 101 | DKIM-signiert von der Domain im Absender. |
| 102 | SPF bestanden, Umschlag- und Absender-Domain passen zusammen. |
| 108 | DKIM scheiterte, weil eine vorherige, legitime Station den Text verändert hat. |
| 130 | Das ARC-Ergebnis eines vertrauenswürdigen Weiterleiters hat das DMARC-Ergebnis überstimmt. |
| 905 | DMARC nicht angewendet wegen verschachtelter Weiterleitung (etwa über einen lokalen Exchange oder einen Fremddienst). |
Quellen, Stand 14. November 2026: Microsoft Learn: Anti-Spam-Kopfzeilen · Microsoft Learn: Spam Confidence Level (SCL) · Microsoft Learn: Bulk Complaint Level (BCL)
SpamAssassin und Rspamd: Punkte gegen eine Schwelle
SpamAssassin vergibt für jede zutreffende Regel Punkte und zählt zusammen. Ab der Schwelle required, ab Werk 5, steht in X-Spam-Status „Yes", und der Server markiert die Mail. Rspamd arbeitet ähnlich, kennt aber Stufen: ab einem Wert Greylisting, darüber eine Spam-Markierung, ganz oben die Abweisung. Spam-Filter treffen erstaunlich gut Cormack 2008, aber jeder Server stellt seine Schwelle selbst ein. Darum liest die Analyse den Wert immer gegen die Schwelle des jeweiligen Filters und nennt die Regeln, die am meisten beitrugen.
| Regel | Bedeutung |
|---|---|
| RCVD_IN_PBL | Die sendende IP liegt in einem Bereich, aus dem laut Spamhaus-PBL keine Mail direkt kommen sollte, typisch für Privat- und DSL-Anschlüsse. |
| RCVD_IN_SBL | Eine Station steht auf der Spamhaus-SBL (bekannte Spam-Quellen). |
| RCVD_IN_XBL | Eine Station steht auf der Spamhaus-XBL (gekaperte Rechner). |
| RDNS_NONE | Der einliefernde Server hat keinen Reverse-DNS (PTR). |
| SPF_SOFTFAIL | SPF nicht bestanden (softfail): Der sendende Server fehlt im SPF-Eintrag. |
| SPF_FAIL | SPF nicht bestanden (fail). |
| DKIM_INVALID | Eine DKIM-Signatur ist vorhanden, aber ungültig. |
| DKIM_VALID_AU | Gültige DKIM-Signatur der Absender-Domain. |
| DMARC_REJECT | DMARC nicht bestanden; die Domain verlangt reject. |
| DMARC_MISSING | Die Absender-Domain hat keinen DMARC-Eintrag. |
| MISSING_MID | Der Mail fehlt die Message-ID. |
| MIME_HTML_ONLY | Die Mail besteht nur aus HTML, ohne Textfassung. |
| BAYES_00 … BAYES_999 | Bayes-Filter: Wahrscheinlichkeit für Spam, gelernt aus früheren Mails dieses Servers. Die Zahl im Namen ist die untere Grenze in Prozent. |
Die Regeln mit RCVD_IN und URIBL fragen Sperrlisten ab. Das ist seit zwei Jahrzehnten Alltag; schon 2004 machten solche Abfragen am MIT ein Siebtel aller DNS-Abfragen aus Jung und Sit 2004. Sie treffen den Versandweg, nicht den Text. Spam kommt überwiegend aus wenigen Bereichen des Adressraums Ramachandran und Feamster 2006, und Listen nach IP-Ruf erkennen den Großteil schon vor der Annahme Esquivel u. a. 2010. Ein Kopierer, der Scans direkt vom DSL-Anschluss verschickt, landet deshalb im Spam, so harmlos der Scan auch ist. Abhilfe schafft der Versand über den Mailserver des Anbieters, mit Anmeldung.
| Aktion | Bedeutung |
|---|---|
| no action | Zugestellt, ohne Markierung. |
| greylist | Beim ersten Versuch vorübergehend abgewiesen (Greylisting); kommt erst beim nächsten Versuch an. |
| soft reject | Vorübergehend abgewiesen; der Absender-Server muss es später erneut versuchen. |
| add header | Als Spam markiert; das Postfach sortiert die Mail meist in den Spam-Ordner. |
| rewrite subject | Als Spam markiert und der Betreff umgeschrieben. |
| quarantine | In die Quarantäne gelegt. |
| reject | Abgewiesen. |
| discard | Verworfen, ohne dem Absender etwas zu melden. |
Quellen: Apache SpamAssassin: Regeldateien (Beschreibungen der Regeln, Standardschwelle 5) · Rspamd-Doku: Aktionen und Schwellen
06 / ABMELDEN
Abmelden mit einem Klick (RFC 8058)
Newsletter brauchen eine Abmeldung, die das Postfach selbst anbieten kann. RFC 8058 legt fest, wie das mit einem Klick geht, und Gmail verlangt es von allen, die mehr als 5.000 Mails am Tag an Gmail-Adressen schicken. Fehlt die Abmeldung, bleibt Empfängern oft nur der Spam-Knopf. Und genau solche Beschwerden misst Microsoft mit dem BCL.
- List-Unsubscribe mit HTTPS-Adresse. Eine mailto-Adresse darf zusätzlich dastehen, allein reicht sie nicht.
- List-Unsubscribe-Post: List-Unsubscribe=One-Click. Genau so, ohne weitere Angaben. Das Postfach schickt diesen Text an die HTTPS-Adresse, ohne Anmeldung und ohne Weiterleitung.
- Eine gültige DKIM-Signatur über beide Zeilen. Beide müssen im h= der Signatur stehen, sonst bietet das Postfach den Klick nicht an.
Für Vereinsverteiler und ähnliche Listen gilt die Pflicht von Gmail meist nicht; die Analyse meldet die fehlende Ein-Klick-Abmeldung dort nur als Info. Quelle: Google: Richtlinien für E-Mail-Absender.
07 / VORGEHEN
Was Sie mit dem Ergebnis tun
- Sperrliste, kein Reverse-DNS, RCVD_IN_PBL. Das liegt am Versandweg. Geräte und eigene Server schicken Mail über den Mailserver Ihres Anbieters (SMTP mit Anmeldung) statt direkt vom Anschluss.
- dmarc=fail bei Ihrer eigenen Post. Fast immer sendet ein Dienst ohne DKIM für Ihre Domain: Newsletter, Shop, Rechnungsprogramm. Den Eintrag richtet man beim Dienst und in Ihrem DNS ein; was im DNS steht, zeigt der E-Mail-Check.
- Massenmail (CAT:BULK, hoher BCL). Empfängerliste pflegen, Ein-Klick-Abmeldung einbauen, gezielter senden. Einzelne Empfänger können Sie bitten, Sie als sicheren Absender einzutragen.
- Verspätung beim Übergang. Einmal nach Greylisting ist normal. Kommt jede Mail spät, gehört der Server des Empfängers (Ausnahmeliste) oder der eigene (Warteschlange, Wiederholabstand) auf den Prüfstand.
- Nichts gefunden. Gmail und Apple schreiben ihren Spam-Grund nicht in den Kopf. Dann hilft eine Testmail an ein eigenes Konto bei Microsoft, dessen Kopf mehr verrät.
Wo die Analyse aufhört
- Sie rechnet keine Signaturen nach. Ob DKIM und ARC gültig sind, entscheidet der Empfänger mit dem Schlüssel aus dem DNS. Die Analyse liest sein Urteil und prüft den Aufbau.
- Sie sieht nur, was im Kopf steht. Interne Bewertungen von Gmail, Apple oder GMX bleiben verborgen; Zeilen ohne öffentliche Beschreibung zeigt sie roh.
- Ausrichtung vereinfacht. Die Organisations-Domain bestimmt sie über eine kurze Liste von Endungen, nicht über die DNS-Abfrage aus RFC 9989. Das DMARC-Ergebnis des Empfängers geht vor.
- Keine Betrugserkennung. Ob eine Mail gefälscht oder gefährlich ist, beantwortet sie nicht.
Den Hintergrund in Ruhe erklärt der Ratgeber Warum landen meine E-Mails im Spam?. Wenn Sie es nicht selbst angehen möchten: Domain und Postfächer richten wir im Rahmen unseres IT-Supports ein, Newsletter- und Shop-Dienste binden wir gleich mit an. Bei laufender IT-Betreuung behalten wir die Zustellung im Blick.
08 / FÜR KI-ASSISTENTEN
Dieses Werkzeug aus einem KI-Assistenten nutzen
Assistenten wie Claude oder ChatGPT, die das Model Context Protocol (MCP) sprechen, können die Rechnung dieser Seite direkt aufrufen, statt sie nachzubauen. Der Server ist öffentlich, braucht keine Anmeldung und speichert nichts. Die Antwort enthält immer den Link auf diese Seite, den Stand der Daten und die Grenzen des Ergebnisses.
- Endpunkt
- https://aureum-tech.com/mcp
- Werkzeug
- werkzeug_e_mail_header_analyse
- Transport
- Streamable HTTP, nur lesend
| Name | Pflicht | Bedeutung |
|---|---|---|
| kopfzeilen | ja | Der vollständige Kopf einer empfangenen E-Mail als Text, so wie ihn Outlook („Internetkopfzeilen"), Gmail („Original anzeigen") oder Apple Mail („Rohquelle") zeigt. Eine ganze .eml-Datei geht auch; der Inhalt nach der ersten Leerzeile wird ignoriert. |
| alle_felder | nein | Optional: true liefert zusätzlich alle Kopfzeilen mit dekodierten Werten (Betreff, Namen nach RFC 2047). Standard false. |
Fragen, bei denen ein Assistent es aufrufen sollte
- „Warum landet unser Newsletter bei Kunden mit Microsoft 365 im Junk-Ordner? Hier ist der Header."
- „Diese Mail kam eine halbe Stunde zu spät an. Woran lag das? (Header eingefügt)"
- „Was bedeuten SCL 5, BCL 7 und compauth=fail reason=001 in diesem Mail-Kopf?"
- „Warum steht bei Gmail dmarc=fail, obwohl die Mail über unseren Vereinsverteiler kam?"
Wie die Anbindung funktioniert und was MCP im eigenen Betrieb leisten kann, steht auf der Seite zu MCP-Integrationen.
09 / HÄUFIGE FRAGEN
Häufige Fragen zum E-Mail-Header
Was steht im Header einer E-Mail?
Der Header (Kopf) steht über dem Text jeder Mail. Darin stehen Absender, Empfänger, Betreff und Datum, dazu eine Received-Zeile von jedem Server, der die Mail weitergereicht hat, mit Uhrzeit und Verschlüsselung. Der Server des Empfängers ergänzt, was er geprüft hat (SPF, DKIM, DMARC), und viele Spam-Filter schreiben ihr Urteil dazu. Mailprogramme blenden das aus; zeigen lässt es sich in jedem.
Wie finde ich den Header in Outlook?
Im klassischen Outlook öffnen Sie die Mail per Doppelklick und wählen Datei > Eigenschaften; der Kopf steht im Feld „Internetkopfzeilen". Im neuen Outlook und in Outlook im Web klicken Sie oben auf die drei Punkte und wählen Anzeigen > Nachrichtendetails anzeigen. In Gmail heißt der Punkt „Original anzeigen". Nehmen Sie immer den Kopf der empfangenen Mail, nicht den aus dem Gesendet-Ordner.
Warum landet meine Mail im Spam, obwohl SPF, DKIM und DMARC bestehen?
Bestandene Prüfungen belegen nur, dass die Mail von Ihrer Domain kommt. Ob sie erwünscht ist, entscheiden Filter nach Ruf und Inhalt: Sperrlisten für die sendende IP, Links auf auffällige Domains, viele Beschwerden über Massenmails oder ein Bayes-Filter, der den Text für Spam hält. Microsoft schreibt das als CAT und BCL in den Kopf, SpamAssassin als Regeln mit Punkten. Gmail nennt den Grund im Kopf nicht.
Was bedeuten SCL und BCL bei Microsoft 365?
SCL (Spam Confidence Level) reicht von −1 bis 9; ab 5 gilt eine Mail allgemein als schlecht. In Microsoft 365 entscheidet aber nicht mehr der SCL, sondern die Kategorie CAT, ob eine Mail als Spam gilt. BCL (Bulk Complaint Level) misst von 0 bis 9, wie viele Beschwerden ein Massenversender erzeugt. Ab 7 sortiert die Standardregel die Mail in den Junk-Ordner, bei strengeren Einstellungen ab 6 oder 5.
Warum kam eine E-Mail eine halbe Stunde zu spät?
Meist wegen Greylisting: Der Server des Empfängers weist Mail von unbekannten Absendern beim ersten Versuch vorübergehend ab und nimmt sie erst beim zweiten an. Wann der kommt, bestimmt der absendende Server; die Norm empfiehlt mindestens 30 Minuten Abstand. Im Kopf sehen Sie das als große Lücke zwischen zwei Received-Zeilen, manchmal mit der Zeile X-Greylist. Bei der ersten Mail eines neuen Absenders ist das normal.
Warum zeigt die Analyse eine negative Verzögerung?
Jede Received-Zeile trägt die Uhrzeit des Servers, der sie geschrieben hat. Gehen zwei Server einige Sekunden oder Minuten auseinander, liegt die spätere Station rechnerisch vor der früheren. Das sagt nichts über die Mail aus. Die Analyse meldet es ab einer Minute Abweichung als Hinweis.
Was bedeutet dmarc=fail bei einer weitergeleiteten Mail?
Weiterleitungen und Verteiler brechen oft beide Prüfungen: SPF gilt nur noch für den Weiterleiter, und ein geänderter Betreff macht die DKIM-Signatur ungültig. Dann scheitert DMARC, obwohl der ursprüngliche Absender alles richtig eingerichtet hat. Mit ARC versiegelt der Weiterleiter das ursprüngliche Ergebnis; Gmail und Microsoft können dem folgen, müssen aber nicht. Sicher ist ein Verteiler, der den Absender umschreibt oder die Mail nicht verändert.
Wo hört die Header-Analyse auf?
Sie liest und erklärt, was im Kopf steht, und zwar nur in Ihrem Browser. Signaturen rechnet sie nicht nach, und was ein Anbieter nicht hineinschreibt, kann sie nicht sehen. Für die Frage, ob eine Mail betrügerisch ist, ist sie nicht gebaut. Wenn Ihre eigenen Mails bei Kunden im Spam landen, prüfen wir Domain, Versanddienste und Mailserver und stellen sie richtig ein, vor Ort im Vogtland oder per Fernwartung.
10 / STUDIEN UND QUELLEN
Worauf sich das Werkzeug stützt
Die Richtwerte und Hinweise oben beruhen auf diesen 14 wissenschaftlichen Arbeiten. Jede ist über ihren DOI bzw. die Seite des Verlags geprüft (zuletzt am 14. November 2026): Es gibt sie, sie ist nicht zurückgezogen, und ihr Befund trägt für die Frage heute noch.
Afergan, M.; Beverly, R. (2005): The state of the email address. ACM SIGCOMM Computer Communication Review 35 (1), S. 29–36
Befund Einen Monat lang wurden Testmails an beliebte, zufällige und Fortune-500-Domains geschickt und wie mit einem Traceroute verfolgt. Ergebnis: spürbare Verluste ohne Rückmeldung, Laufzeiten bis zu mehreren Tagen und überraschende Fehler.
Im Werkzeug Begründet, warum die Analyse jede Station einzeln misst: Dass Mail „einfach funktioniert", ist nicht selbstverständlich.
doi.org/10.1145/1052812.1052822 · Fachzeitschrift
Li, R.; Li, E.; Liu, M. u. a. (2026): When Delivery Meets Error: Exploring Email Delivery Retry Strategies and Defects. Proceedings of the 2026 ACM Internet Measurement Conference, S. 487–494
Befund Untersucht, wie 11 Mail-Anbieter und 8 freie Mailserver nach Fehlern erneut zustellen. Viele Umsetzungen haben Mängel: Bei Meldungen zu Sperrlisten und Greylisting wiederholen die meisten Anbieter nicht angemessen, sechs Systeme verteilen die Versuche bei IPv4 und IPv6 schlecht auf die MX-Server.
Im Werkzeug Erklärt im Ergebnis, warum eine Verzögerung beim Empfänger oft am Wiederholverhalten des absendenden Servers hängt und nicht nur an der Sperre selbst.
doi.org/10.1145/3777912.3839798 · Konferenzbeitrag
Pagani, F.; De Astis, M.; Graziano, M. u. a. (2016): Measuring the Role of Greylisting and Nolisting in Fighting Spam. 46th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), S. 562–571
Befund Erste umfassende Messung von Greylisting und Nolisting: weltweite Verbreitung, Wirkung gegen Spam-Schadsoftware und Folgen für normale Mails. Beide Verfahren nutzen aus, dass Spam-Programme die Wiederholregeln von SMTP oft nicht einhalten.
Im Werkzeug Greylisting ist kein Exot: Die Analyse prüft deshalb bei jeder Verzögerung am Übergang zum Empfänger, ob sie zu einer Greylisting-Pause passt.
doi.org/10.1109/DSN.2016.57 · Konferenzbeitrag
Paxson, V. (1998): On calibrating measurements of packet transit times. Proceedings of ACM SIGMETRICS 1998, S. 11–21
Befund Laufzeiten, die mit zwei getrennten Uhren gemessen werden, sind fehleranfällig: In einer großen Zahl von TCP-Verbindungen waren Uhrsprünge und Gangunterschiede zwischen Sender und Empfänger so häufig, dass sie unerkannt zu großen Messfehlern führen.
Im Werkzeug Jede Received-Zeile stammt von einer anderen Uhr. Negative oder unplausible Abstände meldet die Analyse deshalb als Uhrenabweichung, nicht als Fehler der Mail.
doi.org/10.1145/277851.277865 · Konferenzbeitrag
Durumeric, Z.; Adrian, D.; Mirian, A. u. a. (2015): Neither Snow Nor Rain Nor MITM… An Empirical Analysis of Email Delivery Security. Proceedings of the 2015 Internet Measurement Conference, S. 27–39
Befund Die großen Anbieter verschlüsseln und authentifizieren Mail von sich aus. Von über 700.000 übrigen Mailservern richteten nur 35 Prozent die Verschlüsselung erfolgreich ein; weil SMTP im Zweifel unverschlüsselt weiterliefert, kamen in sieben Ländern über 20 Prozent der eingehenden Gmail-Nachrichten im Klartext an.
Im Werkzeug Darum zeigt die Analyse TLS für jede Station einzeln: Eine verschlüsselte erste Station sagt nichts über die nächste.
doi.org/10.1145/2815675.2815695 · Konferenzbeitrag
Foster, I. D.; Larson, J.; Masich, M. u. a. (2015): Security by Any Other Name: On the Effectiveness of Provider Based Email Security. Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, S. 450–464
Befund Gemessen an jeder Station des Mailwegs: Mehr als die Hälfte der 20.000 größten Empfangsserver beherrschte TLS, prüfte aber keine Zertifikate. SPF war verbreitet, wurde aber selten durchgesetzt; wenige Absender signierten mit DKIM, noch weniger Empfänger wiesen ungültige Signaturen ab.
Im Werkzeug Begründet zwei Grenzen im Ergebnis: TLS im Kopf heißt verschlüsselt, nicht geprüft, und ein Fehlschlag bei SPF oder DKIM führt je nach Empfänger zu ganz verschiedenen Folgen.
doi.org/10.1145/2810103.2813607 · Konferenzbeitrag
Holz, R.; Amann, J.; Mehani, O. u. a. (2016): TLS in the Wild: An Internet-wide Analysis of TLS-based Protocols for Electronic Communication. Network and Distributed System Security Symposium (NDSS) 2016
Befund Internetweite Scans und passive Messung von Mail- und Chat-Servern, auch zwischen Servern: Große Anbieter schützen ihre Nutzer gut, der meiste Verkehr ist unterwegs aber schwach gesichert, mit Mängeln in der Kryptografie und bei der Anmeldung.
Im Werkzeug Die Analyse markiert Stationen mit TLS 1.0, 1.1 oder SSL als veraltet, statt jede Verschlüsselung als gleich gut zu zählen.
doi.org/10.14722/ndss.2016.23055 · Konferenzbeitrag
Deccio, C.; Yadav, T.; Bennett, N. u. a. (2021): Measuring email sender validation in the wild. Proceedings of the 17th International Conference on emerging Networking EXperiments and Technologies (CoNEXT), S. 230–242
Befund Erste große Messung, welche Empfangsserver Absender tatsächlich prüfen: Bis zu 85 Prozent prüfen SPF, mehr als die Hälfte alle drei Verfahren SPF, DKIM und DMARC, teils mit Abweichungen von der SPF-Norm.
Im Werkzeug Darum gewichtet die Analyse die Prüfergebnisse im Kopf hoch: Die meisten Empfänger werten sie aus, und ein Fehlschlag hat Folgen.
doi.org/10.1145/3485983.3494868 · Konferenzbeitrag
Liu, E.; Akiwate, G.; Jonker, M. u. a. (2023): Forward Pass: On the Security Implications of Email Forwarding Mechanism and Policy. 2023 IEEE 8th European Symposium on Security and Privacy (EuroS&P), S. 373–391
Befund Messung an 20 Weiterleitungsdiensten (16 große Anbieter, vier Verteiler-Dienste): Automatische Weiterleitung und Verteiler brechen die Annahmen, auf denen SPF, DKIM und DMARC beruhen.
Im Werkzeug Erkennt die Analyse eine Weiterleitung oder einen Verteiler, erklärt sie einen DMARC-Fehlschlag zuerst damit und nicht mit einem falschen Eintrag beim Absender.
doi.org/10.1109/EuroSP57164.2023.00030 · Konferenzbeitrag
Wang, C.; Wang, G. (2022): Revisiting Email Forwarding Security under the Authenticated Received Chain Protocol. Proceedings of the ACM Web Conference 2022, S. 681–689
Befund Auswertung von 600.000 Mails und kontrollierte Versuche: ARC ist noch nicht weit verbreitet, wird aber von großen Anbietern wie Gmail und Outlook genutzt; die meisten Umsetzungen sind korrekt, einzelne Anbieter deuten ARC-Ergebnisse falsch.
Im Werkzeug Die Analyse zeigt ARC als zweite Meinung des Weiterleiters und sagt dazu, dass der Empfänger selbst entscheidet, ob er ihr folgt.
doi.org/10.1145/3485447.3512228 · Konferenzbeitrag
Jung, J.; Sit, E. (2004): An empirical study of spam traffic and the use of DNS black lists. Proceedings of the 4th ACM SIGCOMM Conference on Internet Measurement, S. 370–375
Befund Mitschnitte am MIT von 2000 und 2004: Das Mailaufkommen stieg um 866 Prozent, und Abfragen bei DNS-Sperrlisten machten 2004 rund 14 Prozent aller DNS-Abfragen aus, gegenüber 0,4 Prozent im Jahr 2000.
Im Werkzeug Sperrlisten sind seit zwei Jahrzehnten Alltag im Mailempfang. Trifft eine Sperrlisten-Regel, stellt die Analyse sie deshalb nach vorn.
doi.org/10.1145/1028788.1028838 · Konferenzbeitrag
Ramachandran, A.; Feamster, N. (2006): Understanding the network-level behavior of spammers. Proceedings of ACM SIGCOMM 2006, S. 291–302
Befund Über zehn Millionen Spam-Mails aus 17 Monaten: Der meiste Spam kommt aus wenigen Bereichen des IP-Adressraums, oft von kurzlebigen gekaperten Rechnern. Filter nach Netzmerkmalen sind beständiger als Filter nach Inhalt.
Im Werkzeug Erklärt, warum ein Kopierer oder Server, der direkt vom DSL-Anschluss sendet, wegen seiner IP im Spam landet, egal was in der Mail steht.
doi.org/10.1145/1159913.1159947 · Konferenzbeitrag
Esquivel, H.; Akella, A.; Mori, T. (2010): On the effectiveness of IP reputation for spam filtering. 2010 Second International Conference on Communication Systems and Networks (COMSNETS), S. 1–10
Befund Unterscheidet Filter vor der Annahme (IP-Reputation) und danach (Inhalt). Eigene Reputationslisten, unter anderem aus SPF-Einträgen gebaut, erkannten rund 90 Prozent von Spam und erwünschter Mail; die Listen müssen aber laufend erneuert werden.
Im Werkzeug Die Analyse trennt Ursachen beim Ruf (IP, Sperrliste, Reverse-DNS) von Ursachen im Inhalt, weil beide an verschiedenen Stellen behoben werden.
doi.org/10.1109/COMSNETS.2010.5431981 · Konferenzbeitrag
Cormack, G. V. (2008): Email Spam Filtering: A Systematic Review. Foundations and Trends in Information Retrieval 1 (4), S. 335–455
Befund Übersicht über Spam-Filter und wie gut sie wirken: Filter sind bemerkenswert treffsicher, obwohl Spam sich kaum formal definieren lässt. Der Filter ist dabei nur ein Baustein in einem größeren System aus Nutzern, Absendern und Diensten.
Im Werkzeug Darum liest die Analyse einen Spam-Wert immer gegen die Schwelle des jeweiligen Filters und nennt die tragenden Regeln, statt eine eigene Gesamtnote zu erfinden.
doi.org/10.1561/1500000006 · Übersichtsarbeit
Normen, Behörden und Herstellerangaben
- RFC 5322: Internet Message Format · RFC Editor (IETF)
- RFC 5321: Simple Mail Transfer Protocol · RFC Editor (IETF)
- RFC 3848: ESMTP and LMTP Transmission Types · RFC Editor (IETF)
- RFC 2047: kodierte Wörter in Kopfzeilen · RFC Editor (IETF)
- RFC 8601: Authentication-Results · RFC Editor (IETF)
- RFC 8617: Authenticated Received Chain (ARC) · RFC Editor (IETF)
- RFC 9989: DMARC (ersetzt RFC 7489) · RFC Editor (IETF)
- RFC 7208: Sender Policy Framework (SPF) · RFC Editor (IETF)
- RFC 6376: DKIM-Signaturen · RFC Editor (IETF)
- RFC 8301: rsa-sha1 in DKIM abgeschafft · RFC Editor (IETF)
- RFC 8058: Abmelden mit einem Klick · RFC Editor (IETF)
- RFC 8314: TLS für Mail (Klausel „tls" in Received) · RFC Editor (IETF)
- RFC 8996: TLS 1.0 und 1.1 abgekündigt · RFC Editor (IETF)
- RFC 6647: Greylisting · RFC Editor (IETF)
- Microsoft Learn: Anti-Spam-Kopfzeilen · Microsoft
- Microsoft Learn: Spam Confidence Level (SCL) · Microsoft
- Microsoft Learn: Bulk Complaint Level (BCL) · Microsoft
- Microsoft-Support: Internetkopfzeilen in Outlook anzeigen · Microsoft
- Google-Hilfe: Nachrichten mit vollständigen Headern zurückverfolgen · Google
- Google: Richtlinien für E-Mail-Absender · Google
- Apache SpamAssassin: Regeldateien · Apache Software Foundation
- Rspamd-Doku: Aktionen und Schwellen · Rspamd-Projekt
11 / WEITERE WERKZEUGE
Noch eine Frage offen?
- AT-W2 · Privat & Betriebe
Windows-10-Check
Bekommt dieser PC noch Sicherheitsupdates, und was ist bis Oktober 2027 zu tun? - AT-W3 · Privat & Betriebe
WLAN-Planer
Wie viele Access Points oder Mesh-Punkte braucht Ihr Haus, Büro oder Ihre Halle? - AT-W4 · Betriebe
IT-Notfall-Check
Wie schnell wäre Ihr Betrieb nach einem Ausfall wieder arbeitsfähig? - AT-W5 · Betriebe
E-Mail-Check
Landen Ihre E-Mails im Spam? SPF, DKIM und DMARC Ihrer Domain im Klartext. - AT-W6 · Betriebe
USV-Rechner
Welche USV hält Server, Router und Kasse bei einem Stromausfall lange genug am Laufen? - AT-W7 · Privat
Vorsorgeblatt digitaler Nachlass
Welche Konten, Geräte und Verträge sollen Ihre Angehörigen kennen?
Sie wissen jetzt, woran es hängt, und wollen es loswerden? Schicken Sie uns das kopierte Ergebnis. Wir richten Domain und Versanddienste so ein, dass Ihre Mails ankommen, in Rodewisch und im ganzen Vogtland.
+49 3744 4399760[email protected]Mo–Fr 8–17 Uhr · Straße der Jugend 5, 08228 Rodewisch