Back to all tools
EMAIL · HEADERS · AUTHENTICATION

Email Header Analyzer

Pinpoint the sender's origin, confirm authentication, and spot spoofing straight from raw email headers.

~/pingie - email-headers
ready

Copy the headers from your email client using View Source / Show Original.

The toolkit

Every network tool you'll ever need.

Purpose-built utilities for ports, IPs, DNS and email. Completely free, all powered by external probes.

Email header analyzer: Trace routing and authentication in raw headers

Every email carries a set of headers that record its journey from the sender's mail server to your inbox. The email header analyzer at Pingie parses those raw headers and presents the routing chain, authentication verdicts, and any detected anomalies in a structured, readable format. It does not guess or summarize; it extracts the actual values the mail servers wrote into the message.

Understanding those values matters whether you are investigating a phishing attempt, diagnosing a delivery failure, or verifying that your outbound mail stack is configured correctly.

What the tool extracts from your headers

When you paste raw headers and click Analyze, the tool works through several distinct layers of the message metadata.

  • Basic info: From, To, Subject, Date, Message-ID, Return-Path, and Reply-To fields pulled directly from the header block.
  • Received chain: Every Received: header is extracted and ordered chronologically, oldest hop first, with the IP address, hostname, and timestamp for each server that handled the message.
  • Security flags: SPF, DKIM, and DMARC verdicts read from the Authentication-Results header, each reported as pass, fail, or none.
  • Warnings: Detected issues such as a mismatch between the From domain and the Return-Path domain, or more than ten Received headers (which can indicate excessive forwarding).
  • Overall security status: A single pass/fail indicator that is only positive when SPF, DKIM, and DMARC all pass and no warnings are present.

All parsing happens within the tool itself. Your header text is not forwarded to any external service.

How authentication results work

The three authentication checks each operate at a different level of the email infrastructure.

SPF (Sender Policy Framework) checks whether the IP address that delivered the message is listed as an authorized sender in the sending domain's DNS records. A pass means the connecting server had permission; a fail means it did not.

DKIM (DomainKeys Identified Mail) verifies a cryptographic signature embedded in the message headers. The receiving server fetches the domain's public key from DNS and checks whether the signature matches. This confirms the message was not altered in transit.

DMARC sits on top of SPF and DKIM. It checks whether at least one of those methods passes and whether the authenticated domain aligns with the visible From address. The domain owner publishes a DMARC policy in DNS that tells receiving servers what to do when checks fail.

You can verify a domain's published DMARC policy separately using the DMARC checker , or inspect a DKIM selector directly with the DKIM checker .

How to use the mail header analyser

  1. Open your email client and locate the option to view the original or raw source of the message. In Gmail this is "Show original"; in Outlook it is "View message source"; in Apple Mail it is "View Raw Source".
  2. Select and copy the entire header block, from the first Received: line down to the blank line before the message body.
  3. Navigate to the email header analyzer and paste the copied text into the input area.
  4. Click Analyze . The tool parses the headers and displays the basic info, received chain, security flags, warnings, and overall security status.
  5. Review the received chain to trace the path the message took. Check the security flags to confirm whether SPF, DKIM, and DMARC passed. Read any warnings to understand flagged conditions.

When an email header check is useful

There are several practical situations where inspecting raw headers gives you information you cannot get any other way.

  • Phishing investigation: A From/Return-Path domain mismatch can indicate spoofing, though it also occurs legitimately with mailing lists and forwarding services. The tool flags the mismatch and lets you decide the context.
  • Delivery troubleshooting: The received chain shows exactly which servers handled the message and when. Gaps or unexpected hops often point to misconfigured relays or spam filters rerouting mail.
  • Authentication auditing: If you have recently deployed SPF, DKIM, or DMARC on a domain, sending a test message and running an email header check confirms whether the records are working as intended.
  • Compliance verification: Security teams reviewing inbound mail can use the authentication results to document whether a message met the organization's expected authentication standards.
  • Forwarding analysis: More than ten Received headers triggers a warning. This helps identify messages that have passed through an unusual number of relay points, which is worth investigating.

How this differs from a standalone DMARC or DKIM checker

A dedicated DMARC or DKIM checker queries DNS for a domain's published records. It tells you what a domain has configured, not what happened to a specific message. The mail header analyser does the opposite: it reads what the receiving servers actually recorded about a real message in transit. The two approaches are complementary. Use the DNS-based tools to audit your configuration, and use the header analyzer to verify that a live message behaved as expected.

For broader DNS diagnostics, the DNS lookup tool lets you query any record type for any domain.

FAQ

An email header analyzer parses the raw metadata block that mail servers attach to every message in transit. Each server adds a Received: header recording its IP, hostname, and timestamp. The tool reads those headers alongside authentication records for SPF, DKIM, and DMARC, then presents the routing path and authentication verdicts in a structured format rather than as a single block of raw text.

The option varies by client. In Gmail, open the message, click the three-dot menu, and choose "Show original." In Outlook, open the message, go to File, then Properties, and copy the Internet headers box. In Apple Mail, select the message and choose View, then Message, then Raw Source. Copy the full text from the first header line to the blank line before the message body, then paste it into the analyzer.

The Received chain is the series of Received: headers written by each mail server that handled the message. The tool reverses their order so you see the route chronologically, from the originating server to your inbox. Each hop shows an IP address, a hostname, and a timestamp. Unexpected IP addresses, unfamiliar hostnames, or large time gaps between hops can indicate routing anomalies or deliberate obfuscation.

The From address is what recipients see in their mail client. The Return-Path is the envelope sender address where bounce notifications go. When those two domains differ, the tool flags it as a warning because it is a common indicator of spoofing. However, mailing list services and forwarding configurations legitimately produce this mismatch. The flag is a prompt to investigate further, not a definitive verdict of malicious intent.

The overall security status is a combined indicator. It is only marked as secure when all three authentication methods (SPF, DKIM, and DMARC) return a pass result and no warnings are present. If any single check fails, returns none, or a warning is triggered, the status is not secure. This strict requirement means the flag reflects the full authentication picture, not just one passing check.

A DMARC checker queries DNS to retrieve the policy a domain has published. A DKIM checker fetches the public key for a specific selector from DNS. Both tools tell you what a domain has configured in theory. The header analyzer reads what actually happened to a real message: the authentication verdicts the receiving servers recorded, the route the message took, and any anomalies they detected.

Each mail server that handles a message appends one Received: header. A typical direct delivery involves two to four hops. More than ten hops suggests the message passed through an unusually large number of relays. This can happen with aggressive forwarding chains, misconfigured mail loops, or deliberate header inflation used to obscure the true origin. The warning prompts you to examine each hop rather than treating the chain as normal.

No. The analyzer processes the header text you paste without forwarding it to any third-party service. The parsing, IP extraction, hostname resolution from the header text, and authentication verdict reading all happen within the tool. If you want to review the site's full data handling practices, the privacy policy covers them in detail.

Yes. Send a test message from your domain to any inbox you control, open the raw headers of the received copy, and paste them into the tool. The authentication results will show whether your SPF record authorized the sending server, whether your DKIM signature verified correctly, and whether your DMARC policy evaluated as expected. This is a practical way to confirm that a new mail configuration is working before sending to real recipients.

A result of "none" means the receiving server did not find a relevant record to check against, or the check was not attempted. For SPF, it typically means no SPF record exists for the sending domain. For DKIM, it means no signature was present in the message or no matching public key was found. For DMARC, it often means no DMARC policy is published for the domain. None is distinct from fail: it indicates absence rather than a definitive rejection.

Yes. The parser extracts both IPv4 and IPv6 addresses from each Received: header. Modern mail infrastructure increasingly uses IPv6 for delivery, so the tool handles both formats when building the received chain. Each hop displays whichever address format the sending server recorded, along with the associated hostname and timestamp.

The tool is available on Pingie without requiring an account or payment. You paste your headers, click Analyze, and receive the full structured output including the received chain, authentication flags, warnings, and overall security status. There are no usage limits advertised for the standard web interface. For questions about terms of use, the terms of service page has the relevant details.