DMARC Validation Report Validate a domain's DMARC policy and check syntax, alignment and external report receivers before making stricter mail enforcement changes.
BIMI Validation Report Check a domain's BIMI readiness across DMARC, logo SVG and certificate evidence with live public DNS results plus prioritized fix notes.
DMARC DNS Record Generator Build a current or legacy DMARC TXT record with policy inheritance and reporting destinations plus DNS string splitting and rollout review.
DKIM Validation Report Check a DKIM selector in public DNS and review its record count, key strength and policy tags with clear testing and resolver evidence.

A suspicious message can carry several different identities at once. The name and address shown by a mail app come from the message content, while the envelope sender controls delivery failures and authentication systems record which domains or servers passed their checks. A reply can even be directed to a fourth address. Comparing those identities is often more useful than judging any one field by itself.

The header also records a delivery trail. Each receiving mail server normally adds a Received field above the existing ones, which puts the newest visible handoff first. Adjacent timestamps can reveal where a delay appeared, but they are not a perfect stopwatch. Servers can have unsynchronized clocks, omit useful detail, or add misleading trace text before the message enters a trusted mail system.

Evidence Useful for Important limit
Received Reconstructing visible relay order and comparing adjacent timestamps. A copied line is not trustworthy until it is inside a receiver you trust.
Authentication-Results Reading the receiver's recorded SPF, DKIM, and DMARC outcomes. The field reports prior checks; its presence does not prove the claims are genuine.
From, Return-Path, and Reply-To Comparing the visible author, bounce address, and reply destination. Different domains can be legitimate, especially for mailing services and lists.
DKIM and ARC fields Finding signing-domain and forwarding-chain context. Visible fields are not the same as a verified signature or trusted ARC chain.

SPF checks whether a sending host was authorized for an envelope domain. DKIM checks a cryptographic signature tied to a signing domain. DMARC asks whether a passing SPF or DKIM identity aligns with the visible From domain and then applies the domain owner's policy. Forwarders and mailing lists can change the route or signed content, so a failed method is a clue that needs context rather than automatic proof of spoofing.

Header analysis is especially useful for delayed mail, phishing triage, forwarding problems, and authentication troubleshooting. It cannot establish that a message body is safe, that a business request is legitimate, or that every relay line is authentic. High-risk requests involving credentials, payments, or sensitive data still need an independent verification channel.

Preserve the original message source before redacting it. Headers can expose personal addresses, message identifiers, private IP addresses, internal hostnames, and mail-gateway details that should not be posted publicly.

How to Use This Tool:

Use one original message source. A forwarded copy or screenshot often removes the trace and authentication fields needed for a useful review.

  1. Paste the complete header into Raw email header, or load one EML or TXT file. If a full message is supplied, only the fields before the first blank line are analyzed.
  2. Set Slow-hop threshold from 5 to 86,400 seconds. A delay equal to the threshold is flagged; choose a value that matches the mail flow you are investigating.
  3. Leave Newest-hop limit at 0 to review every visible hop, up to 50. Use 1 to 50 only when the receiving edge is the intended scope.
  4. Use an authentication ignore switch only for a documented exception such as forwarding or signed-content modification. The recorded result remains visible; the switch changes only the local quality score.
  5. Read Triage findings first, then compare Relay ledger with Authentication evidence. Verify any important conclusion against the receiving gateway or a fresh DNS and signature check.

Interpreting Results:

  • High-caution evidence appears when a structural or timestamp danger is found, or when DMARC records a failure without visible forwarding context. Treat it as a reason to verify, not a sender verdict.
  • Review visible exceptions means at least one warning remains, such as a slow hop, missing authentication result, sender-domain mismatch, or different reply destination.
  • Context-limited evidence covers incomplete authentication or visible forwarding/list context. ARC presence and parent/subdomain similarity do not prove alignment.
  • Coherent visible evidence means the parsed excerpt did not trigger those stronger conditions. It does not certify the content or sender.

Technical Details:

Header fields are unfolded before parsing, while repeated fields such as Received remain separate. The analysis reads the first visible Authentication-Results field, extracts the author domain from From, and compares it with the recorded SPF envelope domain and DKIM signing domain. Exact equality is reported as strict alignment. A simple parent/subdomain relationship is only a relaxed-alignment candidate because a correct organizational-domain decision needs the current DMARC discovery process and DNS data.

Rule Core:

Rule Exact behavior
Relay delay For each older visible hop, subtract its timestamp from the next newer hop and round to whole seconds. Delays greater than or equal to the selected threshold are warnings.
Negative delta A delay below 0 seconds is a danger signal. It is not added to cumulative positive delay.
Recorded authentication SPF, DKIM, and DMARC are read as recorded results. No SPF policy lookup, DKIM signature verification, DMARC DNS discovery, or ARC validation occurs.
Forwarding context Visible ARC fields, list fields, or a non-no automation marker provide context but do not validate an intermediary.
Reply mismatch A parsed Reply-To domain different from the parsed From domain is flagged for review.

Formula Core:

The 0 to 10 quality score is an advisory summary of visible evidence. Each bracket contributes 1 when its condition is true and 0 otherwise; authentication ignore switches satisfy only their matching score term.

Q= I(H>0)+ I(H>0∧N=0)+ 2I(S)+ 2I(K)+ 2I(D)+ I(A)+ I(H>1∧T<3600)

H is the analyzed hop count, N is the number of negative timestamp deltas, and T is total positive delay in seconds. S, K, and D mean SPF, DKIM, and DMARC respectively passed or were explicitly ignored for scoring. A means a passing SPF or DKIM identifier exactly matches, or has a simple parent/subdomain relationship with, the author domain. The final sum is clamped to 0 through 10.

Input is limited to 2 MiB. At most 50 Received fields enter the active review, and the body is excluded after the first blank line. These limits keep the analysis bounded but can make an excerpt incomplete.

Privacy and Limitations:

The header is processed in the browser and is not sent to a server by this analyzer. Raw header text is also excluded from the page URL. Local processing does not make a header safe to share after analysis.

  • Recorded authentication results are trusted only as far as the receiver that added them.
  • DNS, public suffix data, cryptographic keys, reputation feeds, attachments, links, and message-body content are not checked.
  • Slow-hop thresholds are local review settings, not SMTP standards or delivery guarantees.
  • Redact addresses, identifiers, internal hosts, and private IP addresses before sending results outside the incident team.

Worked Examples:

Forwarded message with mixed authentication

A message records SPF failure, DKIM pass, DMARC pass, and visible ARC fields. The SPF result remains a warning unless it is ignored for the local score, while the DKIM and DMARC passes stay visible as receiver-recorded evidence. ARC presence explains why forwarding deserves consideration, but the message still needs gateway verification because no ARC seal or DKIM signature is validated locally.

References: