Skip to main content
NyankoTools

Email Header Analyzer: Route, Delays & Authentication

Investigating a phishing email or a delayed message? Paste the raw headers and get the Received route with the delay at each hop, the SPF, DKIM and DMARC verdicts from Authentication-Results, and warnings when From, Return-Path and Reply-To point to different domains. Folded lines and MIME-encoded subjects or sender names are decoded too. Everything is processed in your browser, and what you paste is never sent to a server. To set up the sending side, see the SPF & DMARC Record Generator.

🔒 Runs in your browser · Your data is never sent to a server

Paste only the header block; anything after the first blank line is ignored. Any number of Received lines is fine.

How to use

  1. In your mail app, open the message source (Show original or View source) and copy the raw headers.
  2. Paste them into the "Email headers" box and click "Analyze".
  3. Read the warnings, authentication results, and route from the top. The hop with the biggest delay is where the slowdown happened.

Notes

  • Received headers can be forged by the sender. Only the top few, added by your own receiving server, can be trusted; treat the rest of the route as a hint.
  • Delays are the differences between timestamps each server wrote. If a server clock is off, the numbers will be off too. Time zones are converted using the offset in each timestamp.
  • SPF, DKIM and DMARC results are read as recorded by the receiving server in the pasted headers. This tool does not query DNS or re-verify anything. A sender can also inject fake Authentication-Results lines, so when there are several, trust only the topmost one added by your own server.
  • Everything is processed in your browser and nothing is stored or sent. Headers contain email addresses, so be careful when sharing them with others.

Glossary

Received

A trace line added at the top of the message by every server it passes through. Lower lines are closer to the sender; higher lines are closer to the recipient.

SPF

Checks whether the sending IP is on the domain’s allowed list. It is evaluated against the Return-Path (envelope) domain.

DKIM

A digital signature added by the sending server and verified with a public key in DNS, showing the body and headers were not altered in transit.

DMARC

Checks that the From domain aligns with the SPF or DKIM domain, and lets the domain owner declare what to do on failure (none, quarantine, reject).

Return-Path

The envelope address that bounces are sent to. It can differ from the From address shown in the mail app.

FAQ

Where do I get the raw headers of an email?

In Gmail, use the three-dot menu and choose "Show original". In Outlook, open the message properties and copy the Internet headers. In Apple Mail, use View > Message > All Headers. The headers are everything up to the first blank line.

Why is DMARC failing when SPF passes?

DMARC needs more than a passing SPF or DKIM: the authenticated domain must also align with the From domain. SPF checks the Return-Path domain, so when a bulk sender uses its own Return-Path domain, SPF can pass while DMARC still fails.

Why is a delay negative?

A later hop is stamped earlier than the one before it when a server clock is off or a Received line was forged. Small differences are usually clock skew. A large one is a reason to doubt the route.

Can I trust the whole Received chain?

No. A sender can add fake Received lines of their own, so only the top few lines, added by your own receiving servers, are reliable. Lines lower down, closer to the sender, cannot be verified.

Does the tool verify SPF or DKIM through DNS?

No. It makes no network requests and just reads what the receiving server wrote in Authentication-Results or Received-SPF. Since headers can be forged too, check your mail provider’s own verdict before acting on something important.

Share this page

↑↓ Select Enter Open Esc Close