Email header:
FieldValue
{{ key }}
{{ value || '—' }}
#FromBy ProtocolDelay (s)
{{ hop.idx }} {{ hop.from }} {{ hop.by }} {{ hop.with }} {{ hop.delay ?? '—' }}
  • {{ key }}
    {{ value || 'n/a' }}
Categories: Email , Networking , Security
Export to PDF Fullscreen

Email headers are the routing footprints and policy proofs that accompany every message you receive. They preserve each server hop, authentication outcome, and content hint mandated by internet standards such as RFC 5322. Examining them is indispensable when diagnosing spoofing attempts, unexplained delivery delays, or failing compliance checks, yet manual inspection remains error-prone and time-consuming.

This analyzer accepts the raw header block, unfolds multi-line fields, and parses every record into structured sets. It computes hop-to-hop delays, extracts SPF, DKIM, DMARC, and ARC verdicts, and assembles a concise summary table. Visual timelines rendered by a lightweight charting layer reveal bottlenecks while one-click exports supply clean comma-separated reports for further study.

You might use the tool when a campaign lands in spam, an auditor requests proof of domain alignment, or a customer questions message timing. Paste the header, inspect delays and passes, and forward the CSV to operations in seconds. Avoid sharing personally identifiable addresses publicly; headers often expose sender and recipient domains.

Technical Details:

Email transport relies on a chain of Mail Transfer Agents (MTAs) that stamp a new “Received” header and, where implemented, append Authentication-Results lines for SPF, DKIM, DMARC, and ARC. These records form a chronological ledger of server hops, IP addresses, and policy verdicts. Comparing adjacent timestamps quantifies network latency, while inspecting verdict tags reveals alignment failures that degrade deliverability or enable impersonation.

Logical Sequence

  1. Unfold header lines by joining continuations defined in RFC 5322.
  2. Split into key-value pairs and normalise field names to lowercase.
  3. Extract Authentication-Results verdicts for SPF, DKIM, DMARC, and ARC.
  4. Break out individual Received clauses and derive hop order.
  5. Convert each clause’s date stamp to UTC and compute successive delays.
  6. Render hop delays in a bar chart and build CSV exports for every tab.

Output Semantics

Authentication verdicts appear as pass, fail, or n/a. Hop delays display in whole seconds; a dash indicates a missing or invalid timestamp. Summary metrics such as “Domain match” and “Auth pass count” help you spot alignment gaps at a glance.

Variables & Parameters

ParameterMeaningDatatype
header_textRaw RFC 5322 header block supplied by the userstring
receivedArray of individual Received clausesstring[]
auth_resultsExtracted SPF, DKIM, DMARC, ARC verdictsobject
hop_delayTime between consecutive hops in secondsnumber
summary_fieldsKey metrics assembled for quick reviewobject
Worked Example: A header showing five hops yields delays of 2, 0, 4, 8 seconds, total path 14 seconds; SPF, DKIM, and DMARC all report pass. The CSV export lines up each hop with its originating and receiving host for audit trails.

Assumptions & Limitations

  • Header clock skew is negligible between adjacent MTAs.
  • Parsing trusts supplied dates without cryptographic verification.
  • Only one Authentication-Results block is evaluated.
  • Non-standard vendor headers are listed but not interpreted.

Edge Cases & Error Sources

  • Folded headers missing the leading whitespace are skipped.
  • Malformed date stamps return a null delay.
  • Headers lacking any Received lines cannot compute timing.
  • Messages relayed through servers suppressing IP information hide sender origin.

Scientific Validity & References

Methodology aligns with RFC 5322 (Message Format), RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC), and RFC 8617 (ARC). Comparative studies by the Messaging, Malware and Mobile Anti-Abuse Working Group validate timestamp-derived latency for forensic analysis.

Privacy & Compliance

The tool handles only header text and performs every calculation inside your browser, supporting GDPR and similar data-minimisation principles.

Step-By-Step Guide:

Follow these steps to transform a raw header into actionable diagnostics.

  1. Paste the full header into the Header field or drop a .eml/.txt file.
  2. Press Parse Header to generate summary, path, and authentication tabs.
  3. Review the Summary tab for domain alignment and key identifiers.
  4. Switch to Received Path to inspect hop-to-hop delays in the charting layer.
  5. Copy individual rows or download complete CSVs for ticket attachments and audit logs.

FAQ:

Is my data stored?

No. All parsing and visualisation run locally; the header never leaves your device.

What file types can I upload?

The analyzer accepts plain .txt or raw .eml message files containing RFC 5322-compliant headers.

Why does a delay show “—”?

A dash means the tool could not compute a numeric delay, usually because a hop lacks a valid or sequential timestamp.

Can I process multiple headers at once?

Process one message at a time to maintain accurate sequencing; paste a new header or clear the field before analysing the next.

How do I read the authentication results?

pass means the sending domain’s policy validated; fail indicates a misalignment that may lead to spam filtering.

Glossary:

SPF
Framework that verifies sender IP against authorised domains.
DKIM
Cryptographic signature binding message parts to a domain.
DMARC
Policy that unifies SPF and DKIM results for domain control.
ARC
Authenticated Received Chain preserving auth state through forwarding.
Received header
Line added by each server documenting hand-off details.
Hop delay
Elapsed seconds between consecutive Received timestamps.
MTA
Mail Transfer Agent handling SMTP relay and routing.
Embed this tool into your website using the following code: