Free tool Email header analyzer: where a message went, and whether it was who it said
Paste the raw headers of a message: the "Show original" or "View source" text. You get the route from sender to inbox with the time spent at each hop, the SPF, DKIM and DMARC verdicts your mail server recorded, whether they line up with the From address, and the field-level problems that send mail to spam.
- Every hop and its delay
- SPF, DKIM, DMARC
- Parsed locally
Analyze headers
The sample is a shipping notice sent through an email service provider. Also try the spoofed message and the example from RFC 8601.
Gmail: ⋮ → Show original. Outlook: File → Properties → Internet headers, or ⋯ → View → View message source. Apple Mail: View → Message → All Headers. Pasting the body as well is fine; parsing stops at the first blank line.
Received hops
4
Total transit time
45 s
From the Date header (or the first hop) to the last Received.
Findings
- NoteLongest wait: +41 s before hop 3. Queues, spam filtering and greylisting usually explain a delay at one hop.
- NoteResults recorded by mx.example.org. Trust this only if mx.example.org is your own mail provider.
- OKSPF pass: em.shop.example.com lists the sending server.
- OKDKIM pass: a valid signature from shop.example.com.
- OKDMARC pass for shop.example.com (published policy p=quarantine).
- OKFrom domain shop.example.com is aligned with SPF + DKIM, which is what DMARC requires.
- OKOne-click unsubscribe is set up (List-Unsubscribe with HTTPS plus List-Unsubscribe-Post, RFC 8058).
Authentication
As recorded by the receiving servers. This tool does not query DNS or verify signatures itself.
| Check | Result | Domain | Aligned with From | Detail |
|---|---|---|---|---|
| SPF | pass | em.shop.example.com | Yes, same organisation | mx.example.org: domain of bounces+8341@em.shop.example.com designates 203.0.113.45 as permitted sender |
| DKIM | pass | shop.example.com | Yes, exact | s=s1 |
| DKIM | pass | esp.example.net | No | s=esp2026 |
| DMARC | pass | shop.example.com | — | p=QUARANTINE sp=QUARANTINE dis=NONE |
Route, oldest hop first
Times in UTC. Delay is the time since the previous hop; the first is measured from the Date header.
| Hop | From | By | With | TLS | Received (UTC) | Delay |
|---|---|---|---|---|---|---|
| 1 | app.shop.example.com [192.0.2.18] | esp.example.net | ESMTPSA | TLS | 2026-11-10 09:11:24 UTC | +1 s after Date |
| 2 | — | filter.esp.example.net | SMTP | — | 2026-11-10 09:11:26 UTC | +2 s |
| 3 | o1.em.shop.example.com [203.0.113.45] | mx.example.org | ESMTPS | TLS | 2026-11-10 09:12:07 UTC | +41 s |
| 4 | mx.example.org [198.51.100.25] | mailstore.example.org | LMTP | — | 2026-11-10 09:12:08 UTC | +1 s |
Key fields
Encoded words (=?UTF-8?…?=) decoded.
| Field | Value |
|---|---|
From | Northwind Shop <news@shop.example.com> |
Reply-To | Northwind Support <support@shop.example.com> |
To | maya@example.org |
Subject | Your order has shipped ✈ |
Date | Tue, 10 Nov 2026 09:11:23 +0000 |
Message-ID | <20261110091123.8341.4f1c@shop.example.com> |
Delivered-To | maya@example.org |
List-Unsubscribe | <https://em.shop.example.com/u/8341?t=Zx81>, <mailto:unsub-8341@em.shop.example.com> |
List-Unsubscribe-Post | List-Unsubscribe=One-Click |
MIME-Version | 1.0 |
Content-Type | multipart/alternative; boundary="b1_4f1c" |
Feedback-ID | 8341:northwind:esp |
DKIM-Signature | d=shop.example.com · s=s1 · a=rsa-sha256 · c=relaxed/relaxed · h=6 · 2048 bit · t=2026-11-10 09:11:24 UTC |
DKIM-Signature | d=esp.example.net · s=esp2026 · a=rsa-sha256 · c=relaxed/relaxed · h=5 · 2048 bit · t=2026-11-10 09:11:24 UTC |
Version v1.0Updated Update history
Three questions the headers answer
Was it delayed, was it really from the sender, and did anything look off.
Where was it delayed?
Each server that handles a message adds a Received line on top. Read bottom to top and you have the route; the time between two lines is the time spent at a hop. A few seconds per hop is typical; minutes usually mean a queue, a spam filter or greylisting at that server.
Did it pass SPF, DKIM and DMARC?
SPF checks the sending server against the bounce domain, DKIM checks a signature for a domain, and DMARC passes when either of those passes for a domain that matches the visible From address. Fail on DMARC with a p=reject or p=quarantine policy is why mail lands in spam or disappears.
Is it aligned?
Passing SPF for an email service's bounce domain or DKIM for its own domain does nothing for DMARC. One of them must be the From domain or share its organisational domain (news.shop.example.com and shop.example.com do).
What else is off?
A Reply-To pointing elsewhere, a malformed or missing Message-ID, duplicate From or Date fields, and hops without TLS. Each one has the rule it breaks next to it.
Authentication results are what the receiving servers wrote down. Anything above your own provider's line can be added by anyone, so trust only the Authentication-Results field whose authserv-id is your provider. This tool does not re-verify signatures or query DNS.
Three steps
Works with headers from any mail app.
-
1
Copy the raw headers
Open the message as received, not the copy in Sent, and use Show original, View source or Internet headers.
-
2
Paste them here
The route, authentication and findings appear immediately. Nothing is sent anywhere.
-
3
Fix what failed
For your own mail, fix SPF, DKIM or alignment in DNS or at your email provider. For a suspicious message, failed DMARC and a mismatched Reply-To are reasons to delete it.
What the analyzer reads
Each field is parsed by the standard that defines it.
- Fields and folding: RFC 5322 §2.2; dates §3.3 including the old zone names (EST, PST…); single-instance fields §3.6; Message-ID form §3.6.4
- Received: the from / by / with / id / for clauses of RFC 5321 §4.4;
with ESMTPSorESMTPSAmeans TLS (RFC 3848) - Authentication-Results: RFC 8601, including comments anywhere and quoted
reason=; ARC copies per RFC 8617 - SPF results RFC 7208, DKIM tags RFC 6376 §3.5, DMARC alignment RFC 7489 §3.1
- Organisational domain is approximated with a short list of two-part suffixes (co.uk, com.cn…) instead of the full Public Suffix List
| Requirement | All senders | More than 5,000 a day to Gmail |
|---|---|---|
| SPF and DKIM | SPF or DKIM | Both |
| DMARC | — | Required; p=none is enough |
| From aligned with SPF or DKIM | — | Required |
| TLS for transmission | Required | Required |
| RFC 5322 format, valid Message-ID | Required | Required |
| One-click unsubscribe (RFC 8058) | — | Marketing and subscribed mail |
Reading the sample newsletter
What the analyzer finds in the default headers.
| Hop | From → by | Delay | What it means |
|---|---|---|---|
| 1 | app.shop.example.com → esp.example.net (ESMTPSA) | +1 s after Date | The shop's app hands the message to its email service, authenticated and over TLS |
| 2 | (internal) → filter.esp.example.net | +2 s | The service's own filtering step |
| 3 | o1.em.shop.example.com → mx.example.org (ESMTPS) | +41 s | The longest wait: queued at the service before delivery |
| 4 | mx.example.org → mailstore.example.org (LMTP) | +1 s | Delivery into the mailbox; internal, so no TLS check |
Authentication: SPF passes for em.shop.example.com and DKIM for both shop.example.com and esp.example.net. DMARC passes because shop.example.com matches From exactly (DKIM) and em.shop.example.com shares its organisational domain (SPF). One-click unsubscribe is set up.
Misreading headers
Four traps when you look at headers by hand.
Reading top to bottom
The newest Received line is at the top. The sender is at the bottom; start there.
Trusting every result
Anyone can write an Authentication-Results line before sending. Only the one added by your own provider counts.
Passing but not aligned
SPF pass for your email service's domain is not enough for DMARC. Set up DKIM with your own domain, or a custom bounce domain.
Blaming the last hop
Clocks on different servers disagree by seconds or more. A negative delay means skew, not time travel; judge large gaps only.
Live chat that does not depend on email getting through
When visitors write outside working hours, the TapCub widget takes their email and you reply by email. During working hours the conversation happens in the chat itself.
Offline messages
A message and an email address, in the same inbox as live chats. If a visitor says your reply never arrived, check its headers here.
Learn moreAlerts where agents are
Desktop alerts, email, WeCom, DingTalk, Feishu, Slack or a webhook, so a new chat is seen even when an email is not.
Learn moreHosted chat page
A chat link for email signatures that lands in the same inbox.
Learn moreEmail header questions
Still have a question?
Chat with the team behind TapCub — we usually reply within a few hours on business days.
How do I see the full headers of an email?
Gmail: open the message, ⋮ → Show original. Outlook on the web: ⋯ → View → View message source; Outlook desktop: File → Properties → Internet headers. Apple Mail: View → Message → All Headers. Copy everything above the first blank line.
How do I read the Received lines?
From the bottom up. The lowest Received line is the first server that took the message; each one above is the next hop, ending with your own provider at the top. Each line says which server it came from, which server received it, how, and when.
What do SPF, DKIM and DMARC mean in the headers?
SPF: the sending server is allowed to send for the bounce domain. DKIM: a domain signed the message and it was not changed. DMARC: SPF or DKIM passed for a domain aligned with the visible From address, plus the sender's policy (none, quarantine or reject) for when they do not.
Why does my email go to spam even though SPF passes?
Common causes: SPF passes for your email service's domain but not one aligned with your From address, so DMARC fails; DKIM is missing or signed with the service's domain; no one-click unsubscribe on bulk mail; or the content and sending reputation. Headers show the first three.
Why is an email delayed?
Find the hop with the long delay in the route table. A wait at the sender's side is usually a queue or rate limit; at the receiver's side, spam scanning or greylisting (temporarily refusing unknown senders). Negative or odd delays are clock differences between servers.
Is it safe to paste email headers here?
Headers include names, addresses, IP addresses and sometimes tracking IDs. This page parses them in your browser, does not upload them and does not put them in a share link. Still, remove anything you would not want on your screen before sharing a screenshot.
Can it verify a DKIM signature?
No. Verifying needs the full message body and the public key from DNS. The analyzer reports what your provider recorded in Authentication-Results and reads the signature tags (domain, selector, algorithm, key size, expiry).
Update history
New features, fixes and data refreshes for this tool, newest first.
-
· v1.0
LaunchedFirst release.
Missing something or found an error? Tell us — requests that come up often go into the next update. All tool updates
Reach visitors before they need to email you
TapCub live chat answers while visitors are still on the page, with their source and current page next to the conversation.