Free Email Header Analyzer
Paste the raw headers of an email to see who really sent it, whether it passed SPF, DKIM and DMARC, and how long each server held it.
What is an Email Header Analyzer?
Every email carries headers that record who sent it, which servers handled it, and whether the sender’s domain vouched for it. This analyzer reads them and explains what they say.
It reads the receiving server’s Authentication-Results for SPF, DKIM and DMARC, follows the Received headers from the sending server to yours with the delay at each step, and decodes encoded subjects and names. It also flags the signs that trip people up in phishing emails.
Key Features
Authentication at a Glance
SPF, DKIM and DMARC verdicts from the receiving server, with the domain each one checked.
The Delivery Route
Every server hop, oldest first, with its IP address, protocol, encryption and the delay since the last hop.
Phishing Signs
A Reply-To on another domain, an address hidden in the display name, and failed or missing checks.
Readable Headers
Folded headers are joined and encoded words such as =?UTF-8?Q?…?= are decoded.
Stays Private
Headers are read in your browser. No address, IP or subject is sent anywhere.
Perfect for everyone
- IT and security teams triaging suspicious mail
- Email deliverability specialists
- Anyone checking whether a message is genuine
How to Use the Email Header Analyzer
Copy the headers from your mail client and paste them in.
Find the Headers
In Gmail use Show original, in Outlook View message source or Message details, in Apple Mail View, Message, All Headers.
Paste Them All
Copy from the first line down to the blank line before the body. A whole message works too.
Read the Summary
Check the authentication line and any warnings. A pass for all three is a good sign, not a guarantee.
Trace the Route
Switch to Hops to see where the message came from and where it was delayed.
Headers, Analysed
Each row is a block of email headers and each answer is this analyzer’s report in the mode on the chip. Decide whether you’d trust the message before you reveal it.
“Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id a12; Sun, 25 Oct 2026 09:14:06 -0700 (PDT) Authentication-Results: mx.google.com; dkim=pass header.i=@example.org header.s=20230601; spf=pass smtp.mailfrom=ada@example.org; dmarc=pass (p=NONE) header.from=example.org From: Ada Lovelace <ada@example.org> To: bob@gmail.com Subject: Notes on the engine Date: Sun, 25 Oct 2026 16:14:04 +0000 Message-ID: <CAF1x2y3@mail.gmail.com>”
“Received: from AM0PR02MB1234.eurprd02.prod.outlook.com (2603:10a6:208:5::21) by DB9PR02MB5678.eurprd02.prod.outlook.com with HTTPS; Sun, 25 Oct 2026 08:30:12 +0000 Received: from mail.example.de (192.0.2.55) by AM0PR02MB1234.eurprd02.prod.outlook.com (2603:10a6:208:5::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8000.1; Sun, 25 Oct 2026 08:30:10 +0000 Authentication-Results: spf=pass (sender IP is 192.0.2.55) smtp.mailfrom=example.de; dkim=pass (signature was verified) header.d=example.de;dmarc=pass action=none header.from=example.de; From: Jürgen Weber <juergen@example.de> To: team@example.com Subject: =?iso-8859-1?Q?Gr=FC=DFe_aus_Berlin?= Date: Sun, 25 Oct 2026 09:30:08 +0100 Message-ID: <7f3a@example.de>”
“Received: from unknown (HELO pay-pal-secure.example.net) ([203.0.113.66]) by mx.example.org with SMTP; Sun, 25 Oct 2026 08:01:10 +0000 Authentication-Results: mx.example.org; spf=softfail smtp.mailfrom=pay-pal-secure.example.net; dkim=none; dmarc=fail header.from=paypal.com From: "service@paypal.com" <alerts@pay-pal-secure.example.net> Reply-To: verify-account@mail-desk.example.info To: ada@example.org Subject: Action required: confirm your account Date: Sun, 25 Oct 2026 08:01:09 +0000”
“Received: from relay2.example.net (relay2.example.net [198.51.100.9]) by mx.example.com with ESMTPS id 9; Sun, 25 Oct 2026 11:47:30 +0000 Received: from relay1.example.net (relay1.example.net [198.51.100.8]) by relay2.example.net with ESMTP id 8; Sun, 25 Oct 2026 11:47:28 +0000 Received: from laptop.local (cpe-1.example.net [203.0.113.4]) by relay1.example.net with ESMTPSA id 7; Sun, 25 Oct 2026 09:02:11 +0000 From: Grace <grace@example.net> To: ops@example.com Subject: Weekly report Date: Sun, 25 Oct 2026 09:02:10 +0000 Message-ID: <r-42@example.net>”
“Received: from b.example.net (b.example.net [192.0.2.2]) by mx.example.com with ESMTPS; Sun, 25 Oct 2026 10:00:00 +0000 Received: from a.example.net (a.example.net [192.0.2.1]) by b.example.net with ESMTPS; Sun, 25 Oct 2026 10:04:30 +0000 From: Ops <ops@example.net> Subject: Clock check Date: Sun, 25 Oct 2026 10:04:29 +0000 Message-ID: <c-1@example.net>”
“Authentication-Results: mx.example.com; dkim=pass header.d=sendgrid.net; spf=pass smtp.mailfrom=bounces.sendgrid.net; dmarc=fail header.from=example.org Return-Path: <bounces+42@bounces.sendgrid.net> From: Example Org <hello@example.org> To: lin@example.com Subject: Welcome aboard Date: Sun, 25 Oct 2026 12:00:00 +0000 Message-ID: <w-1@example.org>”
“From: =?UTF-8?B?w4lsb2RpZSBNYXJ0aW4=?= <elodie@example.fr> To: =?UTF-8?Q?Ren=C3=A9e?= <renee@example.com> Subject: =?UTF-8?Q?R=C3=A9union_de_l=E2=80=99=C3=A9quipe?= Date: Sun, 25 Oct 2026 14:00:00 +0100 Message-ID: <e-9@example.fr>”
“Subject: A very long subject line that continues on the next line From: Sam <sam@example.com> X-Mailer: Thunderbird 128.3.1 Date: Sun, 25 Oct 2026 15:00:00 +0000”
“Hi Bob, I forwarded the email below. Thanks”
“X-Spam-Score: 0.4 X-Mailer: ExampleMailer 2.0 X-Campaign-Id: 1123”
The Headers That Matter
A message can carry dozens of headers. These ten tell you who sent it and how it got to you.
From
The author shown in your inbox. Anyone can write anything here, which is why DMARC exists.
“Is From checked by SMTP itself?”
Return-Path
Where bounces go, set from the SMTP MAIL FROM. SPF checks this domain, not From.
“Which domain does SPF check?”
Reply-To
Where replies go if it’s set. A Reply-To on an unrelated domain is a classic phishing trick.
“Does Reply-To change who sent the message?”
Received
Each server adds one at the top, so the oldest hop is at the bottom.
“Which Received header is the first hop?”
Authentication-Results
The receiving server’s verdicts on SPF, DKIM and DMARC. Trust the topmost one, added by your own provider.
“Which one should you trust?”
DKIM-Signature
A signature over chosen headers and the body. Its d= tag is the domain taking responsibility.
“Which tag names the signing domain?”
Message-ID
A unique ID the sending server creates, usually ending in its domain.
“Who creates the Message-ID?”
Date
When the sender’s client says it was written, which can be wrong. Received dates come from servers.
“Which date comes from the sender’s device?”
ARC-Authentication-Results
Results saved by a forwarder or mailing list, so later servers know the message passed before it was changed.
“When is ARC useful?”
X- Headers
Custom headers from mail software and spam filters, such as X-Mailer or X-Spam-Score. They aren’t standardised.
“Are X- headers standardised?”
Reading SPF, DKIM and DMARC Results
Each check answers a different question. Together they decide whether a domain stands behind a message.
SPF pass
The sending server’s IP is allowed by the Return-Path domain’s SPF record.
SPF softfail and fail
The IP isn’t allowed. softfail (~all) is a soft no, and fail (-all) a hard no.
DKIM pass
The signature verified, so the signed parts weren’t changed since the d= domain signed them.
DKIM none
The message wasn’t signed. Most legitimate bulk mail is signed today.
DMARC pass
SPF or DKIM passed for a domain aligned with From, so the From domain is genuine.
DMARC fail
Neither passed for the From domain. Its policy, p=none, quarantine or reject, says what receivers should do.
Phishing Signs in Headers
Headers can’t prove a message is safe, but these patterns are strong hints that it isn’t.
A Lookalike Domain
pay-pal-secure.example.net isn’t paypal.com. Read the domain after the @ letter by letter.
An Address in the Display Name
A name like service@paypal.com in quotes, followed by a different real address, is meant to fool a quick glance.
Reply-To Elsewhere
When replies go to a free or unrelated domain, the sender wants your answer somewhere they control.
DMARC Fail From a Big Brand
Major brands publish strict DMARC. A fail for their domain almost always means spoofing.
First Hop From a Home Connection
A brand’s mail rarely starts at a residential IP or an unknown HELO name.
Urgency in the Subject
Not a header problem, but “Action required” plus any of the above is the usual pattern.
When to Analyse Headers
Whenever a message’s origin matters more than its content.
Checking a Suspicious Email
See whether a message claiming to be from your bank or a colleague really came from them.
Fixing Deliverability
Find out why your own mail lands in spam by checking its SPF, DKIM and DMARC results at the recipient.
Tracing a Delay
Find which server held a late message and for how long.
Security Incident Triage
Record the sending IPs and domains of a phishing campaign for blocklists and reports.
Verifying a Migration
After moving mail providers, confirm messages now pass through the new servers and sign correctly.
Header Reading Pitfalls
Common misreadings, even by experienced admins.
Trusting Lower Authentication-Results
Anyone can add an Authentication-Results header before sending. Only the one your provider added at the top counts.
Reading Received Top Down
The top Received header is the last hop. Read from the bottom to follow the message forward.
Treating Every Mismatch as Fraud
Return-Path on a mailing service’s domain is normal for newsletters and receipts.
Blaming the Wrong Hop
A long gap can be a clock that’s off, not a slow server. Check whether a later hop is dated earlier.
Copying Only Some Headers
Without Received and Authentication-Results, there’s little to analyse. Copy the full header block.
Pass Means Safe
SPF, DKIM and DMARC prove the domain, not the intent. A phisher’s own domain can pass all three.