How the Email Header Analyzer Works
The analyzer unfolds continued header lines, separates recognized Header-Name: value pairs, reconstructs detected Received entries, and reads authentication verdict strings already present in the message. It is a parser and visualization tool rather than an independent mail-security verifier.
Email Message Header Fields & Quick Reference
A raw email header contains routing, identity and authentication metadata added by the sender's software and by mail systems that handle the message. The analyzer organizes common fields so you can inspect delivery flow without manually sorting every line.
| Header / field | What it usually contains | How this analyzer uses it |
|---|---|---|
| Received | Mail-server relay details, timestamps, hostnames, IPs and protocol information. | Builds the hop table and estimates time between parsed timestamps. |
| Authentication-Results | Recorded SPF, DKIM and DMARC verdicts from a receiving system. | Reads explicit pass/fail text; it does not independently re-verify authentication. |
| Received-SPF | A recorded SPF evaluation from a receiving system. | Used as an SPF fallback when an explicit SPF result is not found in Authentication-Results. |
| From / To | Visible sender and recipient fields. | Displays them in the summary for comparison with technical routing data. |
| Subject | The message subject line. | Shows it in the summary when present. |
| Message-ID | A message identifier commonly generated by the sending system. | Displays it for mail-flow troubleshooting and log correlation. |
| Date | The message's stated creation date. | Displays the recorded value; hop timing comes from Received timestamps instead. |
Raw email header analyzer
Paste the complete Internet-header block rather than only the visible From and Subject lines. Full headers provide the Received chain, authentication results, Message-ID and other technical fields needed for useful delivery and spoofing analysis.
Finding the originating IP address
An IP address found in an early Received header can be useful context, but it is not automatically the sender's personal or device IP. Webmail providers, outbound gateways, relays, privacy services and corporate mail infrastructure can hide or replace the original client address. Treat header IPs as routing evidence, not as definitive identity or location proof.
SPF, DKIM and DMARC header results
Email header troubleshooting workflow
For delayed mail, start with the Received-hop table and identify the largest timestamp gap. For sender-authentication questions, compare the visible From field with the recorded SPF, DKIM and DMARC results. For suspicious mail, retain the original message and use the analyzer as an organizing aid alongside mail-server logs, DNS checks and your normal security tooling.
Authentication results are recorded evidence, not a fresh verification
A displayed PASS means the pasted header contains a matching recorded verdict such as spf=pass, dkim=pass, or dmarc=pass. The analyzer does not query current DNS records, recalculate SPF authorization, retrieve a DKIM public key, verify the message body/signature, or evaluate the current DMARC policy independently.
Trust the receiving system's Authentication-Results boundary
Authentication-Results is most useful when it was added by infrastructure you trust. This analyzer cannot determine whether an arbitrary Authentication-Results line was inserted by a legitimate receiver or supplied as untrusted message content. Keep the original message intact when investigating suspected spoofing or phishing.
Received-hop delays are estimates
The current parser extracts a timestamp from the end of each detected Received line and compares adjacent parsed times. That interval can include queueing, filtering, retries, antivirus processing, policy checks and clock differences; it is not the same thing as pure network latency. If a timestamp cannot be parsed, that hop's time is shown as unavailable.
Simplified hop-field extraction
The From, By and protocol columns use lightweight pattern matching against the Received text. Real-world Received headers can contain comments, bracketed IPs, identifiers, TLS details and vendor-specific syntax, so some complex lines may be summarized imperfectly even when the raw header itself is valid.
Multiple authentication headers
A message can contain more than one Authentication-Results or ARC-Authentication-Results field. The current summary uses the first matching Authentication-Results field it finds, or the first ARC-Authentication-Results field if a standard Authentication-Results field is absent. Review the All Headers tab when several authentication fields exist.
Worked examples
Authentication-Results: mx.example;
spf=pass;
dkim=pass;
dmarc=pass
Analyzer output:
SPF: PASS
DKIM: PASS
DMARC: PASS
Meaning: recorded pass verdicts were found in the pasted header.
It is not an independent re-verification.
Received hop A: 10:00:10 -0400
Received hop B: 10:04:10 -0400
Approximate hop interval: 4 minutes
Possible causes include queueing or processing, not only network transit.
Related Utiliverse Tools
Last reviewed: October 2026 · Header unfolding, hop reconstruction, delay calculation, authentication parsing and privacy wording reviewed against the current implementation.
How to Analyze Email Headers, Delivery Hops, SPF, DKIM and DMARC
An email header is the technical record attached to a message as it moves through mail servers. Raw headers can contain the sender and recipient fields, message ID, timestamps, routing information, authentication results and a chain of Received entries added by mail systems along the delivery path. This free email header analyzer turns that raw text into a more readable summary so you can investigate routing delays and review the authentication results recorded by the receiving system.
What does an email header analyzer show?
The analyzer extracts common message fields such as From, To, Subject, Date and Message-ID. It also reconstructs the sequence of Received headers into a hop-by-hop delivery table and estimates the delay between consecutive server timestamps. This can help identify where a message spent the most time in transit when troubleshooting slow email delivery.
Reading SPF, DKIM and DMARC results
Email authentication results are commonly recorded in fields such as Authentication-Results and Received-SPF. This tool looks for the recorded SPF, DKIM and DMARC verdicts and displays whether each result appears to pass, fail or is not detected.
- SPF indicates whether the sending server was authorized for the envelope-sender domain according to the result recorded by the receiving system.
- DKIM uses a cryptographic signature so a receiving system can evaluate whether signed message content was altered in transit.
- DMARC evaluates domain alignment using SPF and/or DKIM results and the policy published for the visible From domain.
This browser tool reads authentication verdicts already present in the header. It does not perform a new DNS lookup, independently validate a DKIM signature, or guarantee that a message is safe. Treat the results as diagnostic information and investigate suspicious messages with your organization’s normal security process.
How email delivery hops are traced
Mail servers typically prepend a Received header as a message is accepted and relayed. Because newer Received lines are added above older ones, the raw list often appears in reverse chronological order. The analyzer reverses the detected hop list to present the route from the earliest detected relay toward the final receiving systems, then compares timestamps to estimate per-hop delay.
How to get raw email headers
Most email applications hide full Internet headers in the normal reading view. Look for an option such as Show original, View source, Message details, or Internet headers. Copy the complete header block, paste it into the analyzer above, and select Analyze Headers.
For the best routing analysis, include every Received line and the Authentication-Results fields. You can use the built-in sample if you simply want to see how the analyzer organizes the results before pasting your own header.
Common reasons to inspect an email header
- Trace the servers that handled a delayed message.
- Review recorded SPF, DKIM and DMARC results when troubleshooting delivery or authentication problems.
- Compare visible sender information with technical message metadata during a phishing or spoofing investigation.
- Find message IDs and timestamps useful for mail-flow troubleshooting.
- Inspect raw header fields without manually sorting through every line.
Privacy and browser-based processing
The header parsing in this page runs in your browser. The analyzer does not contain code that posts the pasted header text to a Utiliverse server. Even so, email headers can contain addresses, hostnames, IP addresses and message identifiers, so use appropriate care when working with sensitive organizational or personal information.