Email Header Forensics — Spoof-Resistant Header Analysis
Analyze raw email headers: trace the Received path and read SPF/DKIM/DMARC results, ignoring fake passes an attacker plants in quotes or extra headers. Takes pasted raw email headers and reports the Received delivery path (hops listed oldest to newest, with total transit time and clock-skew flags) and the SPF/DKIM/DMARC verdicts from Authentication-Results. Each Authentication-Results header is parsed on its own with quote- and comment-aware rules, so a planted string like dkim=pass inside an address or a second injected header cannot fake a pass; a header with an open quote or comment is reported as malformed and not used. It raises coded findings (for example dkim_fail, auth_results_malformed, timestamp_out_of_order), compares the From, Return-Path and DKIM domains, and states its limits. Everything is done locally in the conversation. It does not do DNS lookups or verify signatures, does not replace your mail provider's verification or a full phishing assessment, and lower Received lines may be forged.
Example input
Use the Email Header Forensics on this (a sample I wrote). I got an "invoice overdue" email that looks off. Here are the raw headers (all addresses are placeholders). Where did it come from, and did it pass SPF/DKIM/DMARC? Received: from mail-out.example.net (mail-out.example.net [192.0.2.45]) by mx.example.com (Postfix) with ESMTPS id AB12CD34; Tue, 14 Oct 2026 09:12:41 +0000 Received: from relay.example.org (relay.example.org [198.51.100.7]) by mail-out.example.net with ESMTP id 7f3a; Tue, 14 Oct 2026 09:12:30 +0000 Received: from [203.0.113.9] (unknown [203.0.113.9]) by relay.example.org with SMTP; Tue, 14 Oct 2026 09:12:35 +0000 Authentication-Results: mx.example.com; spf=pass smtp.mailfrom="billing+dkim=pass@example.net"; dkim=fail header.d=example.net; dmarc=fail header.from=example.com Authentication-Results: evil.example.org; dkim=pass header.d=exampl"e.com; dmarc=pass From: "Example Billing" <billing@example.com> To: user@example.com Return-Path: <bounce@example.net> Subject: Invoice overdue Please pay immediately at the link below.
Example output
## Delivery path (oldest → newest) 1. from [203.0.113.9] (unknown [203.0.113.9]) → by relay.example.org — Tue, 14 Oct 2026 09:12:35 +0000 2. from relay.example.org → by mail-out.example.net — Tue, 14 Oct 2026 09:12:30 +0000 3. from mail-out.example.net → by mx.example.com — Tue, 14 Oct 2026 09:12:41 +0000 Hops: 3 · Transit: 11 seconds (09:12:41 latest − 09:12:30 earliest) Note: hop 2 (09:12:30) is earlier than hop 1 (09:12:35), see findings. Only the top Received line, added by your own server mx.example.com, is reliable. The lower two may have been inserted by the sender, so the origin hop (203.0.113.9) is not proven. ## Authentication SPF: pass | DKIM: fail | DMARC: fail Details: - Header 1 (authserv-id mx.example.com) parsed cleanly: its three items are `spf=pass ...`, `dkim=fail ...`, `dmarc=fail ...`. The text `dkim=pass` inside `smtp.mailfrom="billing+dkim=pass@example.net"` sits inside a quoted string after the `spf=pass` verdict and was not counted. - Header 2 (authserv-id evil.example.org) is malformed: the quote opened in `header.d=exampl"e.com` is never closed. I did not use it at all, so its claimed `dkim=pass` and `dmarc=pass` are ignored. - authserv-id check: header 1 (`mx.example.com`) matches the `by` host of the top Received hop; header 2 (`evil.example.org`) does not. With two headers, the choice of which one a trusted server wrote is still unverified from text alone, but the matching one is the one reported above. ## Findings - [warning] dkim_fail — DKIM result is "fail": possible spoofing or a sender misconfiguration. - [warning] dmarc_fail — DMARC result is "fail": possible spoofing or a sender misconfiguration. - [warning] auth_results_malformed — the structure of the second Authentication-Results header is broken (open quote); verify the original message with your mail provider. - [info] timestamp_out_of_order — in the oldest → newest list, hop 2 (09:12:30) is earlier than hop 1 (09:12:35): clock skew or a forged Received header. - Domain comparison (a lead for a human, not proof): From domain is example.com, Return-Path domain is example.net, DKIM header.d is example.net. The visible sender domain differs from the domains that handled the mail and the signing domain, which fits SPF passing for example.net while DMARC fails for example.com. ## What this cannot tell you - Received lines below your own server may be forged. - These verdicts are copied from headers; I did not re-run DNS or signature checks. …
Real output from running the skill on a sample problem, shortened. The skill file itself is not published here.