Email Header Forensics — Spoof-Safe Analysis

How it works

Email Header Forensics reads the raw headers of a suspicious email and reports the delivery path and the SPF/DKIM/DMARC verdicts, using parsing rules that text planted by an attacker cannot fake.

1. Isolate the headers. It stops at the first blank line, unfolds continued lines and keeps duplicate headers instead of merging them.

2. Rebuild the Received chain. Hops are listed oldest to newest with transit time per hop and a clock-skew flag. It also tells you which hops you can trust: only the top one, added by your own server.

3. Parse Authentication-Results character by character. Quotes, nested comments and escapes are handled, so a fake spf=pass hidden inside a quoted address or a comment is never counted as a verdict.

4. Report findings. A findings table (spf_fail, dkim_fail, dmarc_fail, auth_results_malformed, missing_from and more) plus an authserv-id check against the top Received hop.

Sample output

Real run of this Skill on a sample set of headers we wrote (a fake "invoice overdue" email where SPF and DMARC fail and a second Authentication-Results header hides spf=pass inside a quoted value). The Skill's actual output, unedited:

Delivery path (oldest → newest)

1. from localhost → by mail.example-billing.test — Tue, 6 Oct 2026 09:14:05 +0000 (UTC)
2. from mail.example-billing.test → by mx.recipient-corp.test — Tue, 6 Oct 2026 09:14:07 +0000 (UTC)
   Hops: 2 · Transit: 2 seconds

Authentication

SPF: fail | DKIM: none | DMARC: fail

Notes on the two Authentication-Results headers (each parsed on its own, both well-formed):

• Header 1 (authserv-id mx.recipient-corp.test): spf=fail, dkim=none, dmarc=fail (p=none).
• Header 2 (authserv-id mx.recipient-corp.test): the only verdict at the start of an item is dkim=pass. The text spf=pass sits inside the quoted string header.d="acme-invoices.test; spf=pass", so it is free text and not an SPF verdict.
• The two headers disagree on DKIM (none vs. pass). I used the first item in header order (dkim=none). Both authserv-ids match the by host of the top Received hop (mx.recipient-corp.test), but which header was really added by your trusted server is unverified. The second header looks suspicious because it carries a planted "spf=pass" inside a quoted value.

Findings

• [warning] spf_fail — SPF result is "fail": the sending server is not authorized for smtp.mailfrom [email protected]; possible spoofing or a sender misconfiguration.
• [warning] dmarc_fail — DMARC result is "fail" (policy p=none, so the message was not rejected by policy): possible spoofing or a sender misconfiguration.
• [info] Domain comparison — From domain is acme-invoices.test and smtp.mailfrom is acme-invoices.test, but the message was relayed by mail.example-billing.test (a different domain). The DKIM header.d (acme-invoices.test) appears only in the second, unverified Authentication-Results header. There is no Return-Path header to compare. A mismatch is a lead for the human, not proof of fraud.
• [info] Conflicting Authentication-Results — two headers give different DKIM results (none vs. pass); the choice between them is unverified.

What this cannot tell you

• Received lines below your own server may be forged. Only the top hop (added by mx.recipient-corp.test, your receiving server) is reliable; the "localhost" hop and the origin side are not proven.
• These verdicts are copied from headers; I did not re-run DNS or signature checks.
• Which Authentication-Results header was added by a trusted server cannot be determined from text alone.
• This is not a complete phishing assessment; confirm with your mail provider or security team.

Use cases

• Check whether an "invoice" or "password reset" email really came from where it claims
• Explain to a colleague why a message failed SPF, DKIM or DMARC
• Get a second look at headers whose Authentication-Results may have been tampered with

FAQ

Does it look up DNS or check signatures? No. It reads the verdicts your receiving server already wrote into the headers. It does not re-run DNS or cryptographic checks.

Does it send my headers anywhere? No. It runs inside your own agent and the Skill itself sends nothing to an external service. Headers contain personal data, so redact what you do not need to share.

Is it a full phishing verdict? No. It reports the path, the verdicts and suspicious signals. Confirm with your mail provider or security team.