All free toolsBrowser-local
DIAGNOSTICS / SKY FREE TOOLS

Email Header Analyzer

Read redacted message headers to map hops and reported authentication results.

01 / INPUT

Find the last confirmed hop.

STEP 01
Header text only—do not paste the message body. Maximum 128 KB.0 / 131,072

Analysis runs locally in this browser. No report or message is uploaded.

Your entries stay in this tab. Not sent to or saved by Sky. Export or print before closing or reloading, or your entries will be lost. Do not include passwords, API keys, recipient lists or private logs.

NEXT / INTERPRET THE EVIDENCE

Use this result with the sending path, receiver response and authorized provider signals—not as a stand-alone placement verdict.

Explore the Signal Lab
GUIDE / UNDERSTAND YOUR RESULT

How to read your Email Header Analyzer result

An email header can show which systems handled a message and what authentication results they reported. This browser-only analyzer organizes that evidence; it does not verify the message or prove where it was delivered.

Reading the result, step by step

  1. Paste header text only

    Use the message's original headers, not its body. Text after the first blank line is ignored. The result footer says Calculated in this browser; entries are not uploaded or saved by Sky. Redact private addresses or identifiers before pasting.

  2. Treat the status as a scope label

    For parsed text, the summary card says Analysis status: Analyzed locally. The summary counts fields, Received hops, and reported authentication results. It is not a trust or delivery verdict. Items in result counts displayed route records, not verified messages.

  3. Review Analysis & notes

    The tool notes Body is not analyzed or returned, Authentication results are reported, not verified, and Routing and dates are unverified. No Received fields found means there is no route outline. No Authentication-Results field found means no reported SPF, DKIM, or DMARC result was read. Some lines were skipped or Some folded lines had no field point to text the parser did not interpret.

  4. Follow route and authentication details

    Result detail lists Hop 1 (oldest first), then later hops. SMTP servers prepend Received fields, so the newest field is normally highest in the header; this tool reverses the list for reading. Technical details may show From, Return-Path, Date (reported, unverified), Received hops, and Reported SPF, DKIM, or DMARC results. Treat them as evidence to check, not verified facts.

Common problems and how to fix them

No Received fields found

Usual cause: The pasted text may be partial, or the copy may omit trace fields.

Fix: Open the message's original source or full headers and copy the header section. Leave out the body.

Some route details are incomplete

Usual cause: A Received field may lack a recognizable from and by pair, or its text may be incomplete.

Fix: Compare the original field and ask the receiving mail administrator to confirm the hop. This warning alone does not establish a routing fault.

No Authentication-Results field found

Usual cause: The receiving system may not have included a summary, or the pasted headers may be incomplete.

Fix: Check a complete copy from the receiving system. For authentication evidence, use its trusted logs or message trace rather than inferring a result from absence.

No supported authentication status was parsed

Usual cause: An Authentication-Results field exists, but its text did not include a status this analyzer recognizes for SPF, DKIM, or DMARC.

Fix: Inspect the original field and formatting. The tool reports recognized text; it does not validate syntax, signatures, or sender identity.

Authentication shows pass, but the message is missing

Usual cause: A reported result covers an authentication check, not the full delivery outcome. The tool does not contact mail servers or evaluate inbox placement.

Fix: Check the receiving provider's message trace, quarantine, SMTP response, and mailbox rules. Compare evidence for the same message and time.

Example: A reported pass is not a delivery verdict

Received: from mail.example.com (mail.example.com [192.0.2.10]) by mx.receiver.example; Wed, 01 Jan 2025 10:15:00 +0000
Authentication-Results: mx.receiver.example; spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com

The analyzer can show a route and reported SPF, DKIM, and DMARC pass values, but labels them unverified. The names and documentation address are sample text, not proof of a real route. Use the receiving system's trusted records to confirm the path and outcome.

Frequently asked questions

How do I read Received headers in order?

SMTP servers add Received fields at the top without reordering earlier fields. The raw header runs newest to oldest from top to bottom. This analyzer lists hops oldest first, so Hop 1 is the earliest displayed hop. Untrusted fields can still be incomplete or misleading.

How do I find email headers in Gmail or Outlook?

Open the message's full details or original-source view. Gmail provides Show original; Outlook exposes Internet headers through message properties or details, depending on version. Copy only the header section and redact private identifiers first.

What is Authentication-Results?

It is a structured field where a mail system reports authentication methods and results, often with an authserv-id identifying the service. Its presence does not make the contents valid. Trust it only if that identifier belongs to a receiving system you trust. This analyzer displays supplied text; it does not verify it.

What do ARC headers mean?

An ARC set contains ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal. The shared i= value identifies fields in a set; the ARC-Seal cv= value reports chain status as none, pass, or fail. ARC can preserve authentication assessments across handlers, but this analyzer does not validate ARC signatures or chain status. Ask a trusted receiver or mail administrator for that assessment.