Email Header Analyzer

Paste raw email headers to decode authentication results, trace the message route, and flag suspicious patterns.

How to find your email headers

Gmail

Open the email → click the ⋮ (three-dot) menu → Show original → copy all the text at the top before the message body.

Outlook

Open the email → click File → Properties → copy the text from the Internet headers box.

Apple Mail

Open the email → View menu → Message → All Headers → select all and copy.

What the analyzer extracts from your headers

The analyzer reads only the header block. Folded lines are unfolded, and everything after the first blank line (the message body) is ignored. Header names are matched case-insensitively. Nothing is fetched from DNS: the tool parses and interprets the text you paste.

Header	What is pulled out
Authentication-Results	spf, dkim, dmarc and arc results (pass, fail, softfail, neutral, none, permerror, temperror) plus the property that follows, such as smtp.mailfrom or header.d
Received	Every hop: the from host, the by host and the timestamp. The time between consecutive hops is calculated
From, Reply-To, Return-Path	Used for domain comparison
Message-ID, Subject, Date	Shown for reference
X-Originating-IP	Shown if present. Otherwise the tool takes the first bracketed IPv4 address from the oldest Received header as a best guess
X-Spam-Score, X-Spam-Status	The score, and for X-Spam-Status the Yes/No verdict, score and required threshold

If a message carries more than one Authentication-Results header, the tool keeps the last result it sees for each protocol. New headers are added at the top of a message, so the last one in the block is the oldest. If the message crossed several systems, check the topmost Authentication-Results header added by your own receiving server in the raw text.

The checks and what triggers each flag

SPF fail or softfail in Authentication-Results is flagged as suspicious.
DKIM fail is flagged as suspicious. A none result is not flagged, because it only means no signature was present.
DMARC fail is flagged as suspicious.
Reply-To domain different from the From domain is flagged as a mismatch.
Return-Path domain different from the From domain is flagged as a mismatch.
X-Spam-Score above 5 is flagged as a high spam score.
More than 10 Received hops is flagged as an unusual hop count.
No Authentication-Results header at all produces an informational note: the tool cannot assess authentication from the raw headers.

The overall verdict is fail when something is flagged suspicious and either DMARC failed or both SPF and DKIM failed. It is warn when any suspicious or mismatch flag exists, and pass otherwise. Treat the verdict as a prompt to look closer, not a ruling.

A worked example

This trimmed header block is the kind of input the tool handles. Read it from the bottom up to follow the message from origin to destination.

Sample headers (example.com)

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce@mail.example.com designates 203.0.113.25 as permitted sender) smtp.mailfrom=bounce@mail.example.com;
       dkim=pass header.i=@example.com header.s=s1 header.b=AbCdEf12;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com
Received: from mta1.mail.example.com (mta1.mail.example.com. [203.0.113.25])
        by mx.google.com with ESMTPS id x12si345;
        Mon, 05 Oct 2026 09:14:07 -0700 (PDT)
Received: from app01.internal (app01.internal [10.0.0.4])
        by mta1.mail.example.com with SMTP; Mon, 05 Oct 2026 16:14:05 +0000
From: News <news@example.com>
Reply-To: support@example.com
Return-Path: <bounce@mail.example.com>
Subject: October update

Here SPF passes for the bounce domain mail.example.com and DKIM passes for example.com, so DMARC passes through DKIM alignment. The Return-Path domain (mail.example.com) differs from the From domain (example.com), which the tool will flag as a mismatch even though it is normal and aligns under relaxed DMARC. Hop timestamps are compared as absolute times, so the -0700 and +0000 offsets in this sample do not distort the delay.

Common findings: cause and fix

Finding	Likely cause	Fix
spf=fail or softfail	Sending IP not in the domain's SPF record, or the message was forwarded	Add the legitimate sender to SPF, or rely on DKIM and DMARC for forwarded mail. Use the SPF checker to audit the record
dkim=fail	Body or signed headers changed in transit (footer added by a gateway, mailing list), wrong or missing key at the selector, or an expired signature	Check the selector in the DKIM header (s=) with the DKIM checker, and make sure no system after the signer rewrites the message
dkim=none	The sending service is not signing mail	Enable DKIM in the sending platform and publish its key
dmarc=fail	Neither SPF nor DKIM passed in alignment with the From domain	Align a service's signing or bounce domain with your domain. Review DMARC aggregate reports
Return-Path mismatch	Normal for email service providers that use their own bounce domain	Only a problem if SPF is not aligned and DKIM is also failing
Reply-To mismatch	Contact forms and CRMs often set a different Reply-To. Phishing also uses this	Check whether the message was expected and whether the Reply-To domain is one you recognize
Large delay on one hop	Queueing, greylisting, rate limiting or a slow gateway	Look at which hop gap is largest and investigate that system
spam score above 5	Content or reputation signals picked up by the receiving filter	Compare with the filter's threshold (required=) and review content and blacklist status

How to get complete headers

Gmail: open the message, use the three-dot menu, choose Show original, then copy the text at the top (or use Copy to clipboard).
Outlook desktop: open the message in its own window, then File, Properties, and copy the Internet headers box.
Apple Mail: View, Message, All Headers, then select and copy.
Paste the whole header block into the analyzer. It is fine to include the body, since everything after the first blank line is discarded before parsing.
Use a message that actually failed or was delayed. Headers from a different message from the same sender may not show the problem.

What a header analyzer cannot prove

It does not verify signatures. It reports what the receiving server wrote in Authentication-Results and trusts it. That header is only trustworthy when added by a server you trust, normally the topmost one. Anyone can forge an Authentication-Results line further down the chain before the message reaches you.
Received headers below your own server's can be forged. Only the hop added by your receiving server is reliable, and everything earlier is claimed by whoever sent it.
Domain comparison is an exact text match. A subdomain such as mail.example.com versus example.com is reported as different even though relaxed DMARC alignment would accept it.
Only IPv4 addresses are picked out of the oldest Received header for the originating IP. The result is a best guess, and VPNs, webmail and relays can hide the true source.
Passing authentication proves the domain was authorized to send the message. It does not prove the content is safe, or that a lookalike domain is legitimate.
The List-Unsubscribe and List-Unsubscribe-Post headers are not summarized by this tool. If you need to check them, look for them in the raw header text.

Quick triage order

Read the three authentication results first: SPF, DKIM, DMARC.
If any failed, find which domain each result refers to (smtp.mailfrom, header.d, header.from).
Compare From, Return-Path and Reply-To domains.
Check the originating IP and the Received hop gaps if the problem is delay or a suspected spoof.
Fix the failing record, send a fresh test message and analyze the new headers.

Related tools and guides

How to read email headers

A line-by-line guide to every header that matters.

DKIM signature failed

Why dkim=fail happens and how to fix it.

SPF Checker

Audit the record behind an SPF failure.

DMARC Checker

Review your policy and reporting settings.

Frequently Asked Questions

What are email headers and why should I analyse them?

Email headers are metadata attached to every email that record how the message was sent, routed, and authenticated. They contain SPF, DKIM, and DMARC authentication results, the IP addresses of every server that handled the message, timestamps for each routing hop, and fields like From, Reply-To, and Return-Path. Analysing headers lets you verify whether an email is legitimate, detect spoofing or phishing attempts, and diagnose delivery problems.

How do I find email headers in Gmail, Outlook, or Apple Mail?

In Gmail: open the email, click the three-dot menu, choose Show original, and copy the text at the top. In Outlook: open the email, go to File → Properties, and copy from the Internet headers field. In Apple Mail: open the email, go to View → Message → All Headers, then select all and copy. Paste the copied text into this tool.

What does it mean if SPF or DKIM failed in the headers?

SPF fail means the sending server was not authorised to send email for the domain listed in the message. DKIM fail means the cryptographic signature on the message could not be verified — either the message was modified in transit or the signing key is misconfigured. Either failure is a significant red flag, especially combined with a DMARC fail result. Legitimate senders should consistently pass SPF and DKIM.

What is a suspicious Reply-To or Return-Path mismatch?

The From header shows who sent the email. Reply-To controls where replies go. Return-Path controls where bounces go. When the domain in Reply-To or Return-Path differs from the From domain, it means replies or bounces go to a completely different organisation — a technique commonly used in phishing and business email compromise (BEC) attacks. This tool flags these mismatches automatically.

What is a routing hop in email headers?

Every server that handles an email adds a Received header recording when it received the message, from where, and to where it forwarded it. Each Received header is one routing hop. A typical legitimate email has 2–5 hops. More than 10 hops can indicate a forwarding loop or an unusual delivery path. This tool traces each hop in chronological order and shows the delay between hops.