Email Header Analyzer

Introduction:

Email headers are structured records that show who sent a message, how it moved between servers, and what those servers concluded about authenticity. Reading them helps confirm sender identity, spot forwarding, and explain slow delivery without opening the body.

The header tells a story in timestamps and domains, so you can compare what the sender claimed with what receiving systems observed. A quick scan often reveals alignment with common authentication checks and whether routing introduced unusual delays or clock issues.

Paste a full header and review a concise summary, then look at the path hop by hop and the main authentication outcomes. If an address looks right but alignment fails, treat it with caution and seek corroboration before trusting the content.

Use consistent samples from the same source when comparing results. Repeating the check after a resend can show whether a transient network delay or a misconfigured sender caused a previous warning.

Technical Details:

Email headers (also called the Internet Message Format header) contain routing lines and verdicts added by mail transfer agents. Key mechanisms referenced here are Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), Domain‑based Message Authentication, Reporting, and Conformance (DMARC), and the Authenticated Received Chain (ARC).

The analyzer extracts each Received line to reconstruct the path and computes hop delays in seconds, a total path time, and a count of hops. It also parses SPF, DKIM, DMARC, and ARC results from Authentication‑Results, and checks relaxed DMARC alignment by comparing organizational domains using an eTLD‑plus‑one approximation.

Results are presented as pass, fail, or none for each mechanism and as simple warnings for clock inconsistencies, missing required fields, unusually high hop counts, and long end‑to‑end times. A 0–10 quality score summarizes these signals, rewarding passes and reasonable timing while penalizing missing data or anomalies.

Interpret timing and alignment together. Passing authentication with poor alignment suggests forwarding or configuration gaps, while clean alignment with long delays points to route congestion or slow intermediaries rather than spoofing.

Processing pipeline

1. Normalize line breaks and unfold header continuations.
2. Map header fields; isolate the header block from any pasted body.
3. Collect each Received line, parse from, by, with, IP, and date.
4. Compute hop delay Δt as the difference between consecutive hop timestamps.
5. Compute total path time using first and last hop timestamps; track maximum hop delay.
6. Parse Authentication‑Results for SPF, DKIM, DMARC, and infer ARC presence; list DKIM domains.
7. Derive organizational domains and evaluate relaxed alignment for SPF and DKIM; combine for DMARC.
8. Assemble a summary map and produce warnings and a 0–10 quality score.
9. Run header‑only checks for folding, duplicates, display‑name oddities, ARC sequencing, and spam‑engine hints.

Symbols & units

Worked example

Total path delay T_tot is computed as the difference between the first and last hop times. Negative hop delays indicate clock or ordering anomalies and are surfaced as warnings, not accumulated.

Units, precision & rounding

• Delays are rounded to the nearest second; totals and maxima are integers.
• Timestamps are parsed from hop dates and displayed as UTC strings in the summary.
• Cumulative charts ignore negative deltas and clamp the running total at zero.

Validation & bounds extracted from code

I/O formats & encoding

Networking & storage behavior

• Processing is client‑only; no requests are sent to a server.
• Downloads use generated blobs; clipboard actions write local strings.

Security considerations

• Untrusted header text is handled as plain text; no HTML from headers is executed.
• Results are deterministic for identical inputs; no network lookups are performed.

Assumptions & limitations

• Heads‑up Authentication verdicts are parsed from text; no cryptographic DKIM verification is performed.
• Heads‑up DNS checks for SPF/DMARC are not executed; only header statements are read.
• Organizational domain uses a lightweight eTLD‑plus‑one approximation; unusual public suffixes may be misgrouped.
• Hop parsing relies on common Received formats; atypical lines may yield partial fields.
• Negative delays can reflect unsynchronized clocks or timezone parsing quirks, not necessarily malicious behavior.
• ARC status is inferred from presence and text; chain cryptographic validity is not checked.
• Advanced toggles shown in the UI do not alter scoring unless the underlying logic reads them.
• Large headers with many hops increase chart rendering time linearly with hop count.
• Display‑name script checks are heuristic and may flag legitimate multilingual names.
• Spam‑engine fields are parsed opportunistically and may be absent.

Edge cases & error sources

• Non‑ASCII control characters in pasted text.
• Ambiguous or missing dates that fail to parse.
• Signed zero and rounding near 0.5 s when computing delays.
• Multiple singleton headers such as Date or Message‑ID.
• Headers with illegal folding or continuation lines.
• Unusual with= protocol tokens or custom notations.
• Private or bogon IPs in Received exposing internal hops.
• ARC i= sequence gaps or cv=fail notes.
• DKIM h= list missing From or Subject.
• SpamAssassin and Forefront fields present but unparsable.
• Extremely long chains (>30 hops) producing flood warnings.
• Clocks around DST transitions affecting perceived order.

Scientific & standards backing

• Internet Message Format (RFC 5322) describes header syntax and folding.
• Sender Policy Framework (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 7489) define authentication semantics.
• Authenticated Received Chain (RFC 8617) documents forwarding validation.

Privacy & compliance

No data is transmitted or stored server‑side. Use test headers when assessing sensitive messages and avoid sharing live identifiers unnecessarily.

Step‑by‑Step Guide

Email header inspection yields a routing view and authentication snapshot you can triage quickly.

1. Open the original message and copy the full header text.
2. Paste the header into the textbox or load a .eml file.
3. Run the parse and review the summary for sender, domains, and totals.
4. Check the hop list for delays and ordering; investigate any negative gaps.
5. Review SPF, DKIM, DMARC, and ARC outcomes and note alignment results.
6. Copy or export the sections you need to share with a ticket or report.

• Prefer original Received lines over forwarded copies for timing.
• Compare From and Return‑Path domains when alignment is No.
• Use ARC notes to understand mailing‑list or gateway relays.

FAQ

Troubleshooting

• No output after paste — ensure you included the full header up to the first blank line.
• Missing hops — some systems strip internal routing; check the original source.
• Dates show “Invalid” — the hop date format is non‑standard or truncated.
• All auth “none” — the domain’s results were not recorded in headers.
• ARC shows “No” — the message was not forwarded through an ARC‑aware relay.
• Large headers render slowly — reduce hop limit or export without charts.

Glossary

RFC 5322

Standard defining Internet Message Format header fields and folding.

Received header

A line added by each server showing where it got the message and when.

SPF

Sender Policy Framework; policy that states which hosts may send for a domain.

DKIM

DomainKeys Identified Mail; signatures over headers and body to bind identity.

DMARC

Policy evaluating SPF/DKIM alignment with the visible From domain.

ARC

Authenticated Received Chain; asserts prior authentication through forwarders.

Organizational domain

Effective top‑level domain plus one label used for relaxed alignment.

Message‑ID

Unique identifier for the message, typically bound to a sending host.

Path delay

Elapsed time between first and last hops derived from timestamps.

Alignment

Whether SPF or DKIM domains match the visible From at org‑domain level.