| Field | Value | Copy |
|---|---|---|
| {{ key }} | {{ value || '—' }} |
| # | From | By | Protocol | Delay (s) | Cumulative | Context | Copy |
|---|---|---|---|---|---|---|---|
| {{ hop.idx }} | {{ hop.from || '—' }} | {{ hop.by || '—' }} | {{ hop.with || '—' }} | {{ hop.delay ?? '—' }} | {{ hop.cumulative ?? '—' }} |
{{ hop.routeLabel }}
{{ hop.routeNote }}
|
|
| No Received headers found. | |||||||
| Mechanism | Result | Domain / Scope | Alignment | Evidence | Copy |
|---|---|---|---|---|---|
| {{ row.label }} | {{ row.result || '—' }} | {{ row.scope || '—' }} | {{ row.alignment || '—' }} | {{ row.evidence || '—' }} |
| Field | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} |
| Check | Severity | Result |
|---|---|---|
| {{ item.label }} | {{ item.severity }} | {{ item.result }} |
{{ headerBlock }}
Email headers are the transport record attached to a message before you ever read its body. They matter because display names and subject lines are easy to fake, while routing lines, timestamps, and authentication verdicts show what mail systems actually observed as the message moved between servers.
This analyzer turns that evidence into something you can read quickly. It extracts the visible sender fields, reconstructs the relay path from the Received chain, summarizes SPF, DKIM, DMARC, and ARC outcomes, and surfaces timing or alignment warnings that would otherwise be buried in raw header text.
That is useful in very ordinary situations. A billing notice may look familiar but still arrive through an unexpected route. A delayed password reset may be legitimate yet take too many hops. A forwarded mailing-list message may break DMARC alignment even though it is not a spoof. The point of the page is to help you separate those cases instead of treating every warning as the same kind of problem.
The package also goes beyond a flat field dump. It builds a hop table, a delay chart, a cumulative delay timeline, an alignment reference, a DKIM coverage donut, and a grouped set of header-only findings for sanity checks, clock math, routing semantics, ARC sequencing, mailing-list hints, security leaks, and common spam-engine headers.
That extra structure does not make it a verdict engine. The current package reads only the header text you paste or upload. It does not query DNS, verify DKIM cryptography, inspect message body content, or decide whether the message is safe. Treat the result as an organized reading of the evidence in front of you, not as proof of legitimacy.
Start with the summary box rather than the raw header. It gives you the subject, visible sender and recipient fields, the number of authentication passes, the total route delay, warning count, score, and high-level tags such as Spoof risk, Forwarded/ARC, or Mailing list. That first pass tells you whether you are looking at a routine delivery question, a forwarding case, or something that needs closer scrutiny.
When the main question is delivery path, go next to Received Hop Details and the two timing charts. The hop table is where you confirm which system handed the message to which relay, while the charts make it easier to spot one slow handoff versus a generally long route. A large total delay with otherwise clean authentication usually points you toward congestion, relaying, or queueing rather than impersonation.
When the main question is sender trust, focus on Authentication Outcomes and Domain Alignment Reference. Passing SPF or DKIM alone is less important than whether the authenticated domain aligns with the visible From domain under relaxed DMARC rules. If the visible sender looks right but alignment fails, you should pause before trusting the message, even if one mechanism still says pass.
The Zero-Lookup Findings tab is best read as a density view, not a full report. It shows how many checks in each group landed as OK, warning, fail, or informational. If you need the underlying grouped findings themselves, use the JSON export, because the current package includes the full per-check details there even though the visible analysis tab summarizes only the totals.
From but the Return-Path domain, SPF domain, or DMARC alignment disagree, verify through a trusted channel before acting on links or attachments.Date or Message-ID is missing, treat the score more cautiously because the package explicitly counts those absences as quality warnings.Internet mail headers combine author fields such as From, To, and Subject with trace fields added by transport systems as the message moves across the network. In practical terms, that means the header can answer two different questions at once: who the message claims to be from, and what the relays along the way reported about it.
The analyzer begins by isolating the header block from the pasted text, normalizing line endings, and unfolding continuation lines. It then builds a field map, extracts every Received line in order, and parses common relay markers such as from, by, with, sender IP, and the hop timestamp. The first hop in the table is treated as the most recent relay, and each later row is compared with the one above it to calculate hop delay and a cumulative running total.
Authentication logic is intentionally header-side only. The package reads Authentication-Results, Received-SPF, DKIM-Signature, ARC-Seal, and ARC-Authentication-Results when they are present. SPF domain is taken from smtp.mailfrom when available, otherwise from Return-Path. DKIM domains are taken from the visible signature data. Relaxed DMARC alignment is then treated as satisfied when the organizational domain of From matches either the SPF domain or at least one DKIM signing domain.
The score is a small package-specific rubric, not an industry standard. It awards points for having relay evidence, avoiding negative time deltas, passing SPF, DKIM, and DMARC, keeping relaxed alignment, and keeping total path delay under one hour. Warnings are raised for missing Date or Message-ID, no Received headers, negative hop delays, failed SPF or DKIM, failed DMARC when present, failed relaxed alignment, end-to-end delay above 3600 seconds, and routes longer than 30 hops.
The timing model is straightforward: each hop is compared with the hop before it, and the cumulative line adds only positive delays so a bad timestamp does not drive the chart below zero.
| Item | How the package derives it | Why it matters |
|---|---|---|
| Hop delay | Difference in seconds between adjacent Received timestamps. |
Shows whether one relay added most of the delay. |
| Total path delay | Difference between the newest and oldest parsed hop time. | Flags long delivery chains; > 3600 seconds becomes a warning. |
| Authentication outcomes | SPF, DKIM, DMARC, and ARC values read from header text. | Shows what receiving systems already concluded, without rerunning those checks. |
| DMARC relaxed alignment | Organizational domain match between From and SPF or DKIM domains. |
Distinguishes an authenticated message that still fails visible-sender alignment. |
| Quality score | Bounded 0 to 10 sum of route, auth, alignment, and timing conditions. | Useful for triage, but it is only this package's own weighting model. |
The grouped zero-lookup review adds another layer. It checks control characters and suspicious folding, duplicate singleton headers, sender clock skew against the first hop, protocol tokens from with=, TLS hints in the route, From versus Return-Path, display-name oddities, whether the Message-ID domain matches the visible sender, DKIM signed-header coverage, ARC sequence and verdict fields, mailing-list markers, originating-IP exposure, private or bogon route addresses, and common anti-spam header verdicts.
A few boundaries are important. The package does not perform DNS lookups, message-body hashing, signature validation, or public-suffix-list grade organizational-domain logic. It uses a lightweight eTLD-plus-one style approximation for alignment. The advanced Hop limit and Ignore SPF/DKIM/DMARC in score controls are also currently exposed in the form without being consulted by the parser or scorer, so the visible results still come from the full header text as pasted.
.eml or .txt file so the package can isolate the header block automatically.Return-Path, sender IP, hop count, first and last hop time, DKIM selector, and DKIM domain.A score near the top of the 0 to 10 scale usually means the pasted header has a normal trace chain, no negative hop math, and strong authentication and alignment. That is useful evidence, but it is still only header evidence. Compromised systems, lookalike domains, or socially engineered content can still produce messages that authenticate well.
Mid-range results usually mean mixed signals rather than obvious fraud. Common examples are legitimate forwarding that breaks DMARC alignment, a mailing-list path with ARC headers, a clean authentication set paired with a long delivery route, or a message that is structurally ordinary except for missing metadata such as Message-ID.
| Visible cue | Read it as | Check next |
|---|---|---|
| DMARC aligned = No | The authenticated SPF or DKIM domain does not match the visible sender under relaxed alignment. | Compare From, SPF domain, DKIM domain, ARC count, and mailing-list headers. |
| Total path delay > 3600 s | The package sees more than one hour between oldest and newest parsed relay time. | Use the hop table and charts to locate the slow segment before treating the whole route as suspicious. |
| Negative hop delay | At least one relay timestamp appears out of order. | Think clock skew, timezone issues, or bad trace ordering before assuming tampering. |
| Received hops > 30 | The route is unusually long for the package's warning threshold. | Look for forwarding chains, list expansion, scanning gateways, or loops. |
The most important false-confidence warning is simple: three authentication passes are not the same as "safe message." This page tells you whether header evidence is internally coherent and how it was routed. It does not know whether the sender account was compromised, whether the content is honest, or whether the destination action is wise.
Suppose the header shows three Received hops, SPF, DKIM, and DMARC all at pass, DMARC aligned = Yes, total path delay of 18 seconds, and no missing core fields. The score lands near the top because the route looks coherent and the visible sender aligns with authenticated domains.
That does not guarantee the message is harmless, but it does mean the transport evidence does not immediately contradict the claimed sender.
Now imagine a message with Forwarded/ARC and Mailing list tags, one or two extra hops, and DMARC aligned = No even though DKIM or SPF still has a pass result. The grouped findings also show list headers and ARC chain presence.
That pattern often points toward mediation rather than impersonation. You still need judgment, but the package is telling you to consider list or forwarding behavior before treating the failure as a straightforward spoof.
Assume From shows a known company, yet Return-Path points elsewhere, SPF and DKIM do not pass, relaxed alignment is No, and the header also exposes an X-Originating-IP or a suspicious display name. Even without body analysis, that combination produces a low score and multiple warnings.
That is the right moment to stop clicking, verify through a trusted contact path, and treat the message as untrusted until something stronger than the header says otherwise.
No. It reads the verdicts already written into the pasted header and analyzes their relationships. It does not perform DNS lookups, DKIM cryptographic verification, or live SMTP testing.
Because intermediaries can add hops, rewrite envelope details, and sometimes break DMARC alignment on the visible sender. ARC and mailing-list headers are clues that a mediator handled the message after the original submission.
Total path delay is based on the newest and oldest parsed hop times. The cumulative chart adds only positive hop delays, so negative or invalid deltas are not allowed to push the running total below zero.
The visible analysis tab summarizes counts by group. The JSON export includes the grouped item details that the package computed behind those totals.
Not in the current package logic. Those controls are rendered in the form, but the parser and scorer still derive the visible result from the full pasted header without consulting those values.
From address.