Mail Header Analyzer — Manual

Zurück zur Übersicht: Mail Header Analyzer · Tool live öffnen: www.jpkc.com/tools/mail-header/

Dieses Manual beschreibt den Mail Header Analyzer vollständig: wie die Oberfläche aufgebaut ist, was jeder der fünf Tabs anzeigt, welche Befunde das Tool meldet, wie es die Header intern zerlegt und welche Grenzen der reine Browser-Betrieb mit sich bringt. Die Oberfläche des Tools ist auf Englisch — die Labels werden hier deshalb in ihrer englischen Original-Schreibweise genannt (mit deutscher Erläuterung), damit du dich im echten Interface zurechtfindest.

Aufbau der Oberfläche

Das Tool besteht aus einer Karte mit fünf Reitern (Tabs):

Parse — die Eingabe-Ansicht, in der du die Header einfügst und die Analyse startest.
Overview — Befunde, Zusammenfassung und die wichtigsten Felder.
Route — der Zustellweg als Zeitachse.
Security — Authentication-Results, Received-SPF, DKIM-Signaturen, ARC und Spam-Filter.
All Headers — durchsuchbare Tabelle aller Header.

Beim Start ist nur der Parse-Tab aktiv; die vier Auswertungs-Tabs sind ausgegraut und werden erst freigeschaltet, sobald du erfolgreich analysiert hast. Nach der Analyse springt das Tool automatisch zum Overview-Tab und meldet, wie viele Header-Felder es gelesen hat („… header fields analysed."). Ein Clear deaktiviert die vier Tabs wieder und bringt dich zurück zur Eingabe.

Ablauf

Der typische Ablauf hat drei Schritte:

Header beschaffen — die rohen Kopfzeilen aus deinem Mail-Programm holen (siehe Header beziehen). Du darfst auch die ganze Nachricht nehmen; gelesen wird nur der Header-Abschnitt.
Einfügen oder hochladen — in das große Textfeld einfügen, eine Datei über Upload wählen oder sie per Drag-and-drop ablegen.
Analyze klicken (oder Strg+Enter bzw. Cmd+Enter im Textfeld). Die vier Auswertungs-Tabs füllen sich, und du landest in der Übersicht.

Parse-Tab

Der Parse-Tab ist die Kommandozentrale. Ein Hinweis oben fasst die Regeln zusammen: Header — oder die ganze Nachricht — einfügen und Analyze klicken; alles läuft im Browser, nichts wird hochgeladen. Darunter steht ein großes, dunkles Textfeld in Monospace-Schrift (Raw Email Headers). Im Kopf der Karte sitzt eine Knopfgruppe:

Recent — erscheint nur, wenn du den Verlauf eingeschaltet hast und schon Einträge existieren (siehe Verlauf: Remember, Recent und Forget).
Upload — öffnet einen Datei-Dialog für .eml- und .txt-Dateien. Die Datei wird lokal gelesen, ihr Header-Abschnitt ins Textfeld übernommen (siehe Datei-Upload) und sofort analysiert.
Example — füllt das Feld mit einem realistischen Beispiel-Header und analysiert ihn sofort: eine Mail, die von einem internen Anwendungsserver über ein Postfix-Gateway zu Google lief, mit ARC, Authentication-Results, Received-SPF, DKIM-Signatur, kodiertem Absender und Betreff sowie SpamAssassin-Headern.
Clear — leert das Feld, setzt alle Ansichten und das Suchfeld zurück und deaktiviert die Auswertungs-Tabs.

Unter dem Textfeld liegen der Analyze-Knopf, der Schalter Remember analysed headers in this browser und der Knopf Forget. Du kannst eine Datei außerdem direkt auf das Textfeld ziehen — beim Drüberziehen hebt es sich optisch hervor, beim Loslassen wird die Datei gelesen und analysiert.

Ganz unten erklärt eine Hilfe-Karte (How to get email headers), wie du an die Header kommst — siehe Header beziehen.

Fügst du nichts ein und klickst Analyze, weist dich ein Hinweis darauf hin („Please paste email headers first."). Lässt sich aus dem Text keine einzige Kopfzeile herauslesen, kommt „No header fields found — expected lines like "Name: value"."

Verlauf: Remember, Recent und Forget

Der Verlauf ist opt-in und standardmäßig ausgeschaltet. Erst wenn du den Schalter Remember analysed headers in this browser aktivierst, legt das Tool jede analysierte Nachricht im localStorage deines Browsers ab — und zwar nur den Header-Abschnitt, nie einen mitkopierten Body. Gespeichert werden höchstens zehn Einträge; eine erneut analysierte Nachricht rückt nach oben, statt doppelt zu erscheinen.

Die Einträge erreichst du über das Dropdown Recent. Jeder Eintrag ist mit dem dekodierten Betreff beschriftet (ersatzweise mit der ersten Zeile), gekürzt auf 70 Zeichen; ein Klick lädt die Header ins Textfeld und analysiert sie erneut.

Forget löscht alle gemerkten Header („Remembered headers deleted.").
Schalter aus löscht den Verlauf ebenfalls sofort.
Einträge aus einer Zeit ohne Einwilligung werden beim Laden der Seite entfernt — es bleibt nur, was du ausdrücklich gemerkt hast.

Overview-Tab

Die Übersicht besteht aus drei Karten.

Findings — die Befunde der Analyse, sortiert nach Schwere: rote Fehler, orangefarbene Warnungen, violette Hinweise. Hier landen fehlende Pflichtfelder, verdächtige Absender-Konstellationen, fehlgeschlagene Authentifizierung, Datums-Ungereimtheiten und Clock-Skew. Gibt es nichts zu melden, steht dort mit grünem Haken: „Nothing conspicuous in the header — no proof of a genuine message, only no known warning signs." Alle Regeln stehen unter Befunde im Detail.

Summary — die Kernaussagen in einer Liste:

Sender — Anzeigename und Adresse aus From (dekodiert).
Sending server — die ermittelte Sende-IP mit Einordnung (z. B. Public (globally routable) oder Documentation (TEST-NET-2)), dem Hostnamen aus der Received-Zeile und einem Kopier-Symbol. Wie das Tool sie bestimmt, steht unter Received-Zeilen, TLS und Sende-IP.
Client IP — der Wert aus X-Originating-IP, falls vorhanden.
Authentication — Badges für SPF, DKIM, DMARC und ARC aus dem obersten Authentication-Results-Feld, dazu „by" und der Name des prüfenden Servers.
Spam filters — die Urteile der erkannten Spam-Filter als Badges (spam, ham, bulk, trusted).
Delivery — Zahl der Hops und, sobald es mindestens zwei Hops gibt und der erste und der letzte einen Zeitstempel tragen, die Gesamt-Laufzeit („in transit").

Key fields — eine Tabelle der zentralen Kopfzeilen, sofern sie vorkommen: From, Sender, Reply-To, To, Cc, Subject, Date, Message-ID, Return-Path, List-Id, List-Unsubscribe, Precedence, X-Mailer, User-Agent, MIME-Version und Content-Type. Die Werte erscheinen dekodiert (siehe Kodierte Wörter), jeder mit einem Kopier-Symbol. Kommt ein Feld mehrfach vor, zeigt die Tabelle jedes Vorkommen. Eine Zusatzzeile Date (local) rechnet das Date-Feld in deine lokale Zeit um und nennt den ursprünglichen Offset (UTC+01:00).

Route-Tab

Der Route-Tab rekonstruiert den Zustellweg aus den Received-Feldern. Mailserver setzen ihre Zeile jeweils oben auf (neueste zuerst); das Tool dreht die Reihenfolge um, sodass die Zeitachse vom ersten Hop (grün) zum letzten Hop (blau) läuft. Zwischenstationen sind grau nummeriert. Ein Hinweis über der Zeitachse erinnert daran, dass nur die obersten Received-Felder von deinem eigenen Provider stammen — die unteren kann der Absender fälschen.

Hat die Nachricht ein gültiges Date-Feld, beginnt die Zeitachse mit einem Startpunkt Written: dem Zeitpunkt, zu dem die Mail laut Absender geschrieben wurde.

Pro Hop zeigt eine Karte:

from und by — der einliefernde und der annehmende Server.
IP-Adresse des einliefernden Servers mit Badge: grau internal für private, Loopback-, Link-local-, CGN- und reservierte Adressen, sonst blau mit der Einordnung aus der IP-Bibliothek der IP-Tools.
Protokoll — der Inhalt der with-Klausel, z. B. ESMTP, ESMTPS oder SMTP.
TLS-Status — ein grünes Schloss mit TLS-Version (z. B. TLS 1.3) oder schlicht TLS, wenn die Zeile eine Verschlüsselung belegt. Fehlt jeder Hinweis bei einem Hop mit from-Angabe, dessen IP nicht als intern erkannt ist (oder der gar keine IP nennt), erscheint orange „no TLS recorded". Interne Hops (etwa localhost) und Zeilen ohne from bekommen keine Warnung.
for und id — Empfänger-Adresse und Queue-ID, sofern der Server sie notiert hat.
Zeitstempel — wann dieser Server die Nachricht annahm, umgerechnet in deine lokale Zeitzone. Daneben steht der ursprüngliche Offset, den der Server protokolliert hat (z. B. UTC+01:00 oder UTC-08:00).

Zwischen zwei Hops zeigt das Tool die Wartezeit als Lücke an: „waited 1m 52s at mail-gw.example.com". Der Zeitstempel markiert immer, wann ein Server die Nachricht annahm — die Differenz gehört also zur Wartezeit beim vorherigen Server (Queue, Greylisting), nicht zu einem einzelnen Hop. Die Lücken sind nach Dauer eingefärbt: unter 10 Sekunden grün, unter 1 Minute violett, unter 5 Minuten orange, ab 5 Minuten rot. Ist eine Differenz negativ, gehen die Server-Uhren auseinander; das Tool meldet dann einen Clock skew („the real waiting time is unknown") statt einer erfundenen Wartezeit.

Dauern rundet das Tool ab, nicht auf, und zeigt höchstens zwei Einheiten: Eine Wartezeit von 1 Stunde, 59 Minuten und 59 Sekunden erscheint als 1h 59m, unter einer Sekunde als <1s, ab einem Tag als 1d 2h.

Gibt es mindestens zwei Hops und tragen der erste und der letzte einen Zeitstempel, fasst am Ende ein Kasten die Gesamt-Laufzeit („Total transit") samt Zahl der Hops zusammen. Gibt es dabei mindestens eine positive Wartezeit, nennt er auch die längste Wartezeit („Longest wait") und den Server, an dem sie auftrat. Fehlen Received-Felder, erscheint stattdessen „No Received fields found.".

Security-Tab

Ein Hinweis oben stellt klar: Das Tool zeigt die Ergebnisse, die die empfangenden Server notiert haben — es prüft keine Signaturen und fragt kein DNS ab. Und nur das oberste Authentication-Results-Feld stammt von deinem Provider. Darunter folgen bis zu fünf Bereiche:

Authentication-Results — für jedes dieser Felder eine eigene Karte, betitelt mit dem Namen des prüfenden Servers (authserv-id, z. B. mx.google.com). Ein Badge ordnet die Karte ein: grün „topmost — from your provider" für das oberste Feld, orange „added on the way — can be forged" für alle weiteren. Die Tabelle listet jede Prüfung mit Method (spf, dkim, dmarc, arc und alle weiteren Methoden, die der Server notiert), Result als farbiges Badge (pass grün, fail/permerror rot, softfail/temperror/policy orange, neutral/bestguesspass violett, none grau) und Details — die Eigenschaften wie smtp.mailfrom=, header.from=, header.i= oder header.s= sowie einen reason. Enthält ein Feld keine Prüfung, steht „No results (none).". Fehlt das Feld ganz, erklärt ein Hinweis, dass der empfangende Server keine SPF-, DKIM- oder DMARC-Prüfung notiert hat.

Received-SPF — falls vorhanden, eine Tabelle mit Result, Client IP, Envelope from und dem Kommentar des prüfenden Servers.

DKIM signatures — jede DKIM-Signature als Zeile: Domain (d=), Selector (s=), Algorithm, Matches From (ob die signierende Domain zur Organisation der From-Domain passt: grün yes, orange no) und Signed fields. Der Kartenkopf erinnert daran, dass die Signatur selbst nur der Empfänger prüft — das Ergebnis steht in den Authentication-Results.

ARC chain — bei vorhandenen ARC-Seal-Feldern deren Anzahl, die höchste Instanz i=, das Ergebnis der Kettenprüfung cv= und die versiegelnde Domain. ARC lässt Weiterleitungen und Mailinglisten bestätigen, welche Authentifizierungs-Ergebnisse sie gesehen haben.

Spam filters — eine Tabelle mit Filter, Field, Value und Verdict für alle erkannten Spam-Header (siehe Spam-Header). Findet das Tool keinen, steht dort „No SpamAssassin, Rspamd or Microsoft spam fields found.".

Auf dem Smartphone werden die Tabellen dieses Tabs gestapelt: Jede Zeile wird zu einem Block beschrifteter Werte, statt seitlich zu scrollen.

All-Headers-Tab

Hier siehst du jede geparste Kopfzeile in der Reihenfolge, in der sie in der Mail stand — durchnummeriert, mit Header-Name und Wert, jeder Wert mit Kopier-Symbol. Über der Tabelle:

ein Suchfeld (Search headers...), das die Tabelle live filtert (Treffer in Nummer, Name oder Wert; Groß-/Kleinschreibung egal);
der Schalter Show raw values (encoded words not decoded) — zeigt die Werte so, wie sie in der Mail stehen, also mit =?UTF-8?B?…?= statt dekodiertem Text; die Suche bleibt dabei erhalten;
Copy All — legt den Header-Abschnitt als Text in die Zwischenablage;
Download — speichert den Header-Abschnitt als Textdatei email-headers.txt.

Eine Zeile unter der Tabelle nennt die Zahl der Header-Felder und ob die Werte dekodiert („encoded words decoded") oder roh („raw") angezeigt werden. Auch dieser Tab zeigt Dubletten vollständig, etwa alle Received-Zeilen.

Header beziehen

Die Hilfe-Karte im Parse-Tab fasst zusammen, wie du an die rohen Header kommst:

Gmail — Mail öffnen → More (Drei-Punkte-Menü) → Show original → Header kopieren.
Outlook — Mail öffnen → File → Properties → aus Internet Headers kopieren.
Thunderbird — Mail öffnen → Strg+U → Header (oberhalb der Leerzeile) kopieren.

Wichtig ist nur der Header-Teil — alles bis zur ersten Leerzeile. Kopierst du die ganze Nachricht samt Body, schneidet das Tool ihn selbst ab und meldet das als Hinweis in den Befunden.

Wie geparst wird

Die Auswertung folgt den einschlägigen Standards: RFC 5322 für Header und Datum, RFC 2047 für kodierte Wörter, RFC 5321 für Received-Zeilen und RFC 8601 für Authentication-Results.

Header-Format und Unfolding

Der Header-Abschnitt endet an der ersten Leerzeile (auch einer, die nur Leerzeichen oder Tabs enthält); alles danach ist Body und wird ignoriert. Vorher normalisiert das Tool Zeilenenden (\r\n → \n), entfernt ein Byte-Order-Mark und eine mbox-Trennzeile, die mit From (ohne Doppelpunkt) beginnt.

Danach zerlegt es den Abschnitt in Name: Wert-Paare. Ein Feldname darf aus allen druckbaren ASCII-Zeichen außer dem Doppelpunkt bestehen — also auch Namen wie X_Custom werden erkannt. Zeilen, die mit einem Leerzeichen oder Tab beginnen, sind Fortsetzungen der vorherigen Kopfzeile und werden wieder an sie angehängt (Unfolding) — so bleiben lange, umgebrochene Header wie Received oder DKIM-Signature als Einheit erhalten. Zeilen, die weder Kopfzeile noch Fortsetzung sind, ignoriert das Tool und meldet sie als Befund mit den ersten Zeilennummern. Reihenfolge und Dubletten bleiben erhalten — wichtig, weil Received mehrfach vorkommt.

Kodierte Wörter (RFC 2047)

Betreff, Anzeigenamen und andere Felder mit Umlauten oder fremden Schriften stehen in der Mail als Encoded Words, etwa =?UTF-8?B?…?= (Base64) oder =?UTF-8?Q?J=C3=B6rg?= (Quoted-Printable). Das Tool dekodiert beide Varianten mit dem Zeichensatz, den das Wort angibt. Leerraum zwischen zwei direkt aufeinanderfolgenden Encoded Words entfällt, wie es der Standard verlangt; aufeinanderfolgende Wörter im gleichen Zeichensatz werden vor dem Dekodieren zusammengefügt, damit über die Wortgrenze geteilte UTF-8-Zeichen nicht zerbrechen. Die Rohform zeigt der Schalter im All-Headers-Tab.

Datumsangaben und Zeitzonen

Date und die Zeitstempel der Received-Zeilen liest ein eigener RFC-5322-Parser. Er versteht Kommentare, zweistellige Jahre (unter 50 → 20xx, sonst 19xx), numerische Offsets und die alten Zonennamen UT, GMT, Z, UTC, EST, EDT, CST, CDT, MST, MDT, PST und PDT. Der Offset -0000 und unbekannte Zonennamen gelten als „Zeitzone unbekannt"; das Tool liest die Zeit dann als UTC. Beim Date-Feld meldet es das als Hinweis in den Befunden, ebenso einen Wochentag, der nicht zum Datum passt; bei den Received-Zeitstempeln bleibt beides ohne Meldung.

Received-Zeilen, TLS und Sende-IP

Jede Received-Zeile wird in ihre Klauseln from, by, via, with, id und for zerlegt; was nach dem letzten Semikolon steht, ist der Zeitstempel. Kommentare in Klammern gehören zur Klausel davor — ein from innerhalb eines Kommentars wird also nicht als Absender missverstanden. Die IP-Adresse stammt aus einem Adress-Literal wie [198.51.100.42] bzw. [IPv6:…] oder aus dem Kommentar hinter from.

Als verschlüsselt gilt ein Hop, wenn die with-Klausel ESMTPS, ESMTPSA, UTF8SMTPS, UTF8SMTPSA, LMTPS oder LMTPSA lautet oder die Zeile Hinweise wie TLS, SSL, version=TLS…, cipher= oder HTTPS enthält. Die Version liest das Tool aus version=TLS1_3 oder TLSv1.2.

Die Sende-IP ist die IP des ältesten Hops, die nicht intern ist — private Netze, Loopback, Link-local, Carrier-Grade-NAT und reservierte Bereiche überspringt das Tool, weil sie nie der eigentliche Absender-Server sind. Adressen aus Dokumentationsnetzen zählen (sie kommen in Beispielen vor), werden aber als solche beschriftet.

Authentication-Results, DKIM und ARC

Jedes Authentication-Results-Feld wird einzeln ausgewertet: Name des prüfenden Servers, alle Prüfungen mit Ergebnis, Eigenschaften und reason. Vertrauenswürdig ist nur das oberste Feld — es hat der Server deines Providers geschrieben. Weiter unten stehende Felder hat jemand unterwegs hinzugefügt, im Zweifel der Absender selbst; ein gefälschtes dkim=pass dort kann das Tool deshalb nicht täuschen. Nur das oberste Feld speist die Badges in der Übersicht und die Befunde.

DKIM-Signature- und ARC-Seal-Felder liest das Tool als Tag-Listen (d=, s=, a=, h=, i=, cv=). Ob eine Domain „passt", entscheidet ein Vergleich der Organisations-Domain: die letzten zwei Labels, bei Endungen wie co.uk oder com.au die letzten drei. Das ist bewusst grob — DMARC selbst nutzt die Public Suffix List — und genügt für Hinweise.

Spam-Header

Erkannt werden drei Filter-Familien:

SpamAssassin — X-Spam-Status (Status mit Score und Schwelle, Urteil spam/ham aus Yes/No, dazu die Liste der Tests), X-Spam-Score und X-Spam-Flag.
Rspamd — X-Spamd-Result (Score / Schwelle, spam ab Erreichen der Schwelle), X-Rspamd-Score und X-Rspamd-Action (no action = ham, jede andere Aktion = spam).
Microsoft — die SCL (Spam Confidence Level) aus X-MS-Exchange-Organization-SCL oder X-Forefront-Antispam-Report (ab 5 spam, −1 trusted), das Filter-Urteil SFV (SPM = spam), die verbindende IP (CIP) und der BCL-Wert für Massenmails aus X-Microsoft-Antispam (ab 7 bulk).

Andere Spam-Header, etwa X-Spam-Level, wertet das Tool nicht aus; du findest sie im All-Headers-Tab.

Datei-Upload

Upload und Drag-and-drop akzeptieren .eml- und .txt-Dateien bis 25 MB. Das Tool liest die Datei lokal als Text, übernimmt nur den Header-Abschnitt ins Textfeld und meldet „Read the header section of …" — mit dem Zusatz „(body left out)", wenn ein Body abgeschnitten wurde. Anschließend startet die Analyse automatisch. Enthält die Datei keinen Header-Abschnitt, kommt „No header section found in the file.".

Outlook-.msg-Dateien sind ein Binärformat und werden abgelehnt; die Fehlermeldung erklärt den Ausweg: die Mail in Outlook öffnen und die Internet-Header über File → Properties kopieren. Andere Endungen quittiert das Tool mit „Please choose a .eml or .txt file.".

Befunde im Detail

Die Karte Findings im Overview-Tab sammelt alles, was an einem Header auffällt. Ein Befund ist ein Hinweis, kein Urteil: Auch legitime Mails lösen manche aus, und eine Mail ohne Befund ist nicht automatisch echt.

Fehler (rot)

Kein From-Feld (Pflicht nach RFC 5322).
SPF, DKIM, DMARC oder ARC mit fail oder permerror laut oberstem Authentication-Results.

Warnungen (orange)

Zeilen, die weder Kopfzeile noch Fortsetzung sind (mit Zeilennummern).
Kein Date-Feld; keine Message-ID — legitime Server setzen sie fast immer.
From, Date, Subject, Message-ID, Sender, Reply-To oder To kommen mehrfach vor — Programme zeigen dann womöglich unterschiedliche Werte.
Date ist kein gültiges RFC-5322-Datum oder liegt mehr als 15 Minuten nach der letzten Zustellung (fehlen Received-Felder oder hat der letzte Hop keinen lesbaren Zeitstempel: nach der aktuellen Uhrzeit).
Der Anzeigename enthält eine E-Mail-Adresse, die nicht die echte Absender-Adresse ist — ein klassischer Phishing-Trick.
Reply-To zeigt auf eine andere Domain als der Absender.
Es gibt DKIM-Signaturen, aber keine von der Domain des Absenders.
SPF, DKIM, DMARC oder ARC mit softfail oder temperror.

Hinweise (violett)

Der Text enthielt einen Body; analysiert wurde nur der Header-Abschnitt.
Ein Bcc-Feld ist vorhanden (wird normalerweise vor der Zustellung entfernt).
Der Wochentag im Date-Feld passt nicht zum Datum; das Date-Feld hat keine verwertbare Zeitzone.
Der erste Server hat die Mail mehr als 24 Stunden nach ihrem Date angenommen.
Return-Path gehört zu einer anderen Domain als From — normal bei Newslettern und Versanddiensten; DMARC besteht dann nur über eine passende DKIM-Signatur.
Der empfangende Server hat kein DMARC-Ergebnis notiert; es gibt mehrere Authentication-Results-Felder; oder es gibt gar keins (gemeldet nur, wenn Received-Felder vorhanden sind).
Ein Hop hat seine Zeit mehr als eine Minute vor dem vorherigen protokolliert (Clock-Skew).

Betriebsgrenzen und Datenschutz

Vollständig clientseitig: Parsen, Routen-Berechnung, Authentifizierungs- und Spam-Auswertung sowie das Datei-Lesen laufen ausschließlich im Browser. Es gibt kein Backend, kein API, keinen Upload-Endpunkt — deine Header verlassen den Rechner nicht.
Verlauf nur auf Wunsch: Ohne den Schalter Remember analysed headers in this browser speichert das Tool nichts. Eingeschaltet legt es bis zu zehn Header-Abschnitte im localStorage ab; Forget oder das Ausschalten löscht sie (siehe Verlauf).
Header-Werte gelten als feindlich: Header stammen aus fremden, oft bösartigen Mails. Das Tool gibt jeden Wert nur als Text aus, nie als HTML — ein präparierter Betreff oder Absender kann im Tool keinen Code ausführen.
Standardnahes Parsen mit Grenzen: Die Zerlegung folgt den RFCs, die Mail-Server schreiben Received-Zeilen aber teils sehr frei. Unübliche Formate können unvollständig erkannt werden — der All-Headers-Tab zeigt dann immer noch den Rohwert. Die Domain-Zuordnung nutzt eine grobe Organisations-Domain statt der Public Suffix List.
Keine DNS-Live-Prüfung: Das Tool liest nur, was in den Headern steht. Es fragt keine DNS-Einträge ab und verifiziert keine DKIM-Signatur kryptografisch — es zeigt die Ergebnisse, die die empfangenden Mailserver bereits in Authentication-Results notiert haben.

Für den Einstieg und die Zielgruppen siehe die Übersichtsseite. Konkrete Durchläufe stehen in den Beispielen, Strategie und Stolperfallen in den Tipps & Tricks. Ausprobieren kannst du alles direkt im Tool.