Skip to content
Email Delivery Platform
Talk to engineering

/ Free Tools — Email Header Analyzer

The whole story, hop by hop.

Paste raw headers and read exactly what happened to a message: every server hop with the delay between them, SPF/DKIM/DMARC with alignment, From vs Return-Path spoofing checks, decoded subjects, and a deliverability score. Parsed in your browser, nothing sent.

Request infrastructure review How to read the hops

Everything is parsed in your browser — check your network tab, no request is made. Nothing is sent or stored.

/ What this does

Email headers are the record every mail server writes as a message travels, and they hold the answer to almost any delivery question — why it was slow, why it went to spam, whether it was really from who it claims. This analyzer reads them the way a receiver does: it reconstructs the hop-by-hop path with the delay at each step, reports SPF, DKIM, and DMARC with alignment, checks the From against the Return-Path for spoofing, decodes MIME-encoded subjects, reads any spam score, and rolls it into a deliverability score. When a message misbehaves, the headers already know why.

The delivery timeline flags the hop where a message actually waited, so a multi-hour delay stops being a mystery. The authentication panel shows green, yellow, or red at a glance, and links each protocol to its checker so you can fix the record at the source. And because it all runs in your browser, even a sensitive message's headers never leave your device.

  • Hops + delays

    Every Received header rebuilt into a chronological timeline with the delay at each hop, and the slow one highlighted.

  • Auth + alignment

    SPF, DKIM, and DMARC verdicts with alignment, color-coded, each linked to the checker that fixes it.

  • Spoofing check

    Flags a From versus Return-Path mismatch and whether alignment saves it — the line between a real sender and a forgery.

  • Browser-only

    Pure parsing, no network request. Decoded subjects, spam scores, and a deliverability score, all without your headers leaving the page.

/ Reading the hops

How do you read the Received chain?

Every server that touches a message adds its own Received header at the very top, so the stack grows newest-first. That means you read it from the bottom up: the lowest Received header is the first hop, closest to the sender, and the top one is the last server before the mailbox. Each line records where the message came from, which server took it, and a timestamp — and the analyzer flips the whole chain into plain chronological order so you don't have to read it backwards.

The timestamps are where the diagnostic value lives. By subtracting one hop's time from the next, you get the delay each server introduced, and that's what turns "the email was slow" into "it sat for four minutes at the recipient's spam filter." A few hundred milliseconds per hop is normal; a gap of thirty seconds or more points at greylisting, a filtering bottleneck, an overloaded relay, or rate limiting applied to your sending IP. Greylisting in particular is a deliberate delay — the receiver rejects an unknown sender once, then accepts the retry. The analyzer highlights the slow hop, because in a chain of six servers, the one that cost you the time is the only one you need to look at.

The bottom hop matters for a second reason: it carries the originating IP, the address the message truly came from. That's the IP whose reputation decides a lot of your placement, which is why the analyzer surfaces it and links it straight to the blacklist lookup. Received headers are also the trustworthy part of the message — a sender can forge From or Reply-To, but the receiving servers write their own Received lines, so the path they record is the honest account of where a message has been.

/ From vs Return-Path

Why do From and Return-Path differ, and when is it a red flag?

These two addresses do different jobs, and the difference is the heart of how email authentication works. The From is the friendly address your recipient sees in their client, and it can be set to anything at all. The Return-Path — the envelope sender, set during the SMTP conversation — is where bounces go, and crucially it's the domain that SPF checks. SPF never looks at the visible From; it validates the Return-Path. That single fact explains a lot of confusing results.

So a mismatch between them is normal and everywhere. When a marketing platform or a helpdesk sends on your behalf, it uses its own bounce domain as the Return-Path while displaying your brand in the From, and SPF passes for the platform's domain rather than yours. That's fine — as long as DMARC is satisfied another way. DMARC requires that an authenticated domain aligns with the visible From, so a message where SPF passes only for the sending platform still passes DMARC when DKIM signs with a key that aligns with your From domain. The analyzer shows you exactly this: the mismatch, and whether alignment rescues it.

The same mismatch is also how a spoofer operates: put your domain in the From, send from their own infrastructure with their own Return-Path, and hope no one checks. What stops them is precisely the alignment requirement — without a DKIM signature or SPF pass that aligns with your From, DMARC fails and the message is quarantined or rejected. That's why a From-to-Return-Path mismatch is neither automatically bad nor automatically fine — treat it as a prompt to check whether alignment holds. The analyzer makes that call visible so you can tell a legitimate sending service from a forgery in one look.

/ Header FAQ

How do I get an email's raw headers?
In Gmail, open the message, click the three-dot menu, and choose Show original — then copy everything. In Outlook on the web, open the message, click the three-dot menu, and choose View message source. In Apple Mail, use View, then Message, then All Headers. In Thunderbird, use View, then Message Source. Paste the whole block into the analyzer. The headers are the technical lines above the message body; they hold the routing, timestamps, and authentication verdicts, but not the message content itself.
How do I read the delivery hops?
Each server that handles a message stamps its own Received header at the top, so the chain is built newest-first — you read it bottom to top, with the earliest hop (closest to the sender) at the bottom. The analyzer reverses this into chronological order for you and calculates the delay between each hop from the timestamps. A few hundred milliseconds per hop is normal. A gap of 30 seconds or more usually means greylisting, spam filtering, an overloaded relay, or rate limiting against your sending IP — and the analyzer highlights the slow hop so you can see exactly where the message waited.
Why do the From and Return-Path addresses differ, and does it matter?
They serve different jobs. The From is the display address your recipient sees, and it can be set to anything. The Return-Path — the envelope sender set during the SMTP transaction — is where bounces go, and it's the domain SPF actually checks against. A legitimate mismatch is common: mailing lists and email service providers often send with their own Return-Path while showing your From. But a mismatch is also how spoofing works, so it only passes DMARC if DKIM signs with a domain that aligns with the visible From. The analyzer surfaces the mismatch and whether alignment saves it, which is exactly the distinction that decides inbox versus spam.
What does the authentication section tell me?
It reads the Authentication-Results header that the receiving server wrote, and reports the three verdicts that decide deliverability: SPF (was the sending IP authorized), DKIM (was the cryptographic signature valid), and DMARC (did an authenticated domain align with the visible From). Green is a pass, yellow a softfail or none, red a fail. All three passing is the gold standard. When one fails, that's almost always why a message went to spam — and the fix is in your DNS, which is what the linked SPF, DKIM, and DMARC checkers are for.
Is it safe to paste headers here?
Yes. Every part of the analysis runs in your browser with JavaScript — you can confirm it in your browser's network tab, where clicking Analyze makes no requests. Nothing is sent to our servers, stored, or logged. Headers do contain server names, IP addresses, and the sender and recipient addresses, but never the message body, attachments, or passwords, so even a sensitive message's headers stay on your device.
What is a good deliverability score here?
The score estimates how the receiving world is likely to treat the message, weighting the signals that mailbox providers weigh: SPF, DKIM, and DMARC results carry the most, with TLS on the transport and a clean From-to-Return-Path relationship adding the rest. A score in the high range means the authentication stack is doing its job; a low one points at a specific failed check you can fix at the source. It reflects this one message as its receiver saw it, so it's a diagnostic snapshot rather than a verdict on your whole domain.

Headers show you one message. We keep every message clean.

A header analysis is a snapshot of one email. Getting SPF, DKIM, and DMARC to pass on every message you send — and keeping them there as you add senders — is continuous work, and it's what we operate. Diagnose the header, then bring us the pattern.

Book infrastructure review

Related capabilities