Email Header Analyzer

Email headers follow RFC 5322: a block of colon-separated `Name: value` fields sitting above the message body, with long values folded onto continuation lines that start with a space or tab. Some fields appear once (From, To, Subject, Date, Message-ID); Received does not - every mail server that touched the message prepends its own Received line above whatever was already there.

Because each hop adds its line to the top, the header block reads newest-first: the Received line closest to the top of the file is the last server that handled the message before it reached the reader, and the one closest to the bottom (just above From/To/Subject) is the first hop, usually the sending client or its outbound relay. A decoder has to reverse that order to walk the chain chronologically before it can compute anything meaningful about delay.

Each Received line packs several sub-fields into one loosely structured string: `from <sending host>` (what the receiving server was told, not independently verified), `by <receiving host>`, optionally `with <protocol>` (ESMTP, ESMTPS, and so on), and - after the last semicolon - a timestamp in RFC 5322 date-time format marking when that hop's server logged receipt.

• Topmost Received line = most recent hop; bottommost Received line = first hop (chain reads newest-first)
• The timestamp always sits after the LAST semicolon in a Received line, per RFC 5322 §3.6.7
• A folded header (continuation line starting with space/tab) is one logical field split across multiple physical lines
• From, To, Subject, Date, and Message-ID normally appear once; Received and Authentication-Results can repeat once per hop

Once the Received chain is in chronological order, the gap between one hop's timestamp and the next hop's timestamp is that leg's transit time - how long the message sat somewhere, or how long a slow connection took, between the two servers. Summing every inter-hop gap from the first Received line to the last gives the total time the message spent inside the mail system, from the originating server to the final delivery hop.

A single unusually long gap - minutes where every other hop took a second or two - usually points at one specific server: a greylisting delay, a queue backed up under load, or a spam filter holding the message for content scanning. A missing timestamp on a hop (a malformed or truncated Received line) breaks the chain at that point; delay can still be computed across the hops that do parse, just not through the gap.

Clock skew between servers is a real, mundane cause of a negative or nonsensical delay reading - not every anomaly is a routing problem. A hop whose server clock is a few seconds fast relative to the next one can show a small negative gap even on entirely legitimate mail.

The Authentication-Results header (RFC 8601) is where a receiving mail server records what it decided about SPF, DKIM, and DMARC for that message - added by the server itself, not by the sender, which is why it should only be trusted when it comes from a header stack you control or from a hop you know performed the checks. The header carries one or more `method=result` pairs: `spf=pass`, `dkim=fail`, `dmarc=none`, and so on.

SPF (Sender Policy Framework, RFC 7208) checks whether the IP address that connected to deliver the message is authorized to send for the domain in the envelope-from address, by looking up that domain's SPF TXT record. A `pass` means the sending IP matched an authorized entry; `fail` or `softfail` means it did not; `neutral` means the domain's policy explicitly declines to make a judgment either way; `none` means no SPF record was published at all.

DKIM (DomainKeys Identified Mail, RFC 6376) checks a cryptographic signature attached to the message against a public key published in the signing domain's DNS. A `pass` means the signature verifies and the signed headers/body were not altered in transit; `fail` means the signature is present but does not verify (tampering, or a forwarding step that altered a signed header); `none` means the message carried no DKIM signature to check.

DMARC (RFC 7489) does not perform its own cryptographic or IP check - it is a policy layer that requires SPF or DKIM to pass AND to be in alignment: the domain that passed SPF or DKIM has to match (or be a subdomain of) the domain in the visible From address. A message can pass SPF and DKIM individually and still fail DMARC if neither of those passes is aligned with the From domain, which is exactly the gap spoofing techniques try to exploit.

Beyond the standard RFC 5322 fields, most receiving mail systems add their own non-standard `X-` headers recording a spam-filtering verdict before the message reaches an inbox. `X-Spam-Status` and `X-Spam-Score` (added by filters like SpamAssassin) report a computed score and a yes/no verdict against the receiving system's threshold; `X-Spam-Flag` is a simpler yes/no marker some filters set instead. `X-Spamd-Result` is Rspamd's equivalent, usually listing the individual rules that fired and their point contributions.

These headers reflect a decision the RECEIVING server already made about a message it accepted - they say nothing about how a different server, or a different filter with different rules, would have scored the same message. A clean X-Spam-Status on a forwarded copy does not mean the original recipient's server saw the same thing, since intermediate hops can strip or rewrite these headers entirely.

`X-Originating-IP` and provider-specific fields such as `X-MS-Exchange-Organization-SCL` (Microsoft's numeric spam confidence level) or `X-Google-SMTP-Source` surface additional context a given mail platform chose to attach. None of these are standardized the way Received or Authentication-Results are - their presence, format, and meaning vary by mail system, so they are read as supplementary signals, not as a substitute for the SPF/DKIM/DMARC verdicts.

A spoofed From address most often shows up as a mismatch between what Authentication-Results reports and what the visible From header displays: DMARC failing while the From domain looks legitimate is the single strongest signal, since it means neither an aligned SPF pass nor an aligned DKIM pass backs up the domain the reader actually sees. A first Received hop whose `from` host has no obvious relationship to the claimed sending domain is a second, independent signal worth checking against the domain's own mail infrastructure.

Unusual delay is read from the same hop-by-hop timestamps used for normal transit-time analysis - the difference is which pattern to look for. A message that shows a large total delay concentrated at one specific hop (rather than spread evenly across several) points at that one server: a queue, a greylist, or a scan step, not a general routing problem across the whole path.

None of this requires resolving a hostname, looking up geolocation for an IP, or contacting any server - every signal above is present in the pasted text itself. A header value naming a suspicious host or IP is a lead to investigate separately (with a DNS or WHOIS lookup on that specific value), not something the header block resolves on its own.