Email Header Analyser
Paste the raw headers. We reconstruct the delivery path, parse the Authentication-Results verdict, and flag the patterns that point at spoofing or misconfiguration.
Gmail: โฎ menu → Show original. Outlook desktop: File → Properties → Internet headers. The body is stripped before the headers leave your browser.
Try an example: โ Passing (bulk sender via Brevo) ยท โ Failing: spoofed sender ยท ๐ช Phishing kitchen sink
How this email header analyser works
Every message you receive carries two stacks of evidence about how it got to you. The Received chain is the route, written in reverse chronology by every relay it passed through. The Authentication-Results header is the receiver's verdict on SPF, DKIM, DMARC and (sometimes) ARC. Paste the raw headers above and the tool reads both, reconstructs the path, and flags the patterns receivers use to decide whether a message is genuine.
Each hop gets walked in order. We pull the originating IP, identify the sending tool (Outlook desktop, PHPMailer, a marketing ESP, a cPanel mail() call), check that IP against the major RBLs, parse any ARC seal chain, inspect the TLS version each hop negotiated, and surface the server-leak headers like X-PHP-Originating-Script or X-AntiAbuse that quietly reveal the sending infrastructure. A separate phishing card pulls together From / Return-Path mismatches, display-name spoofing, look-alike domains, and the other tells receivers grade on.
What does the spf=pass / dkim=pass / dmarc=pass triple actually mean?
The verdict the receiver writes into Authentication-Results looks like this:
Authentication-Results: mx.google.com;
spf=pass smtp.mailfrom=bounce.example.com;
dkim=pass header.d=example.com header.s=s1;
dmarc=pass (p=REJECT) header.from=example.com
SPF says the sending IP is allowed to send for the envelope domain. DKIM says the cryptographic signature over the canonicalised headers and body verifies. DMARC says at least one of those two passed and aligned with the visible From: domain. A pass on all three with alignment is the result an inbox provider needs to deliver mail with any reputation behind it.
Why is the Received chain in reverse chronological order?
Each relay prepends its Received header to the top of the message. The oldest hop (the originating MTA) ends up at the bottom. The newest hop (your inbox provider) sits at the top. The tool reorders the chain into delivery order so it reads left-to-right the way the message actually travelled. Look at the bottom of the chain when you want to know where a message really came from. Look at the top when you want to know what your gateway thought of it.
When does ARC matter?
Forwarders break DKIM. A mailing list that appends a banner, a fetchmail rule that rewrites the subject, a Gmail forwarder that touches Message-ID โ any of those edits invalidates the signature. ARC (RFC 8617) seals the original Authentication-Results at each forwarding hop so the final receiver can still see the verdict from before the message was edited.
Our take: ARC is on borrowed time. The IETF has a draft to move ARC to historic in favour of DKIM2. For now, a broken ARC chain (cv=fail anywhere) is the receiver's signal to ignore forwarded auth results and judge the message on the latest hop alone.
What are the obvious header-spoofing tells?
From-header domain not matching Return-Path is the big one. Bounces and replies route via the envelope address, so when a "PayPal" message has a Return-Path of [email protected], the gap is structural, not cosmetic. Duplicate From: headers (a header-smuggling pattern), Reply-To pointing at a free-mail domain when the From claims a brand, a Message-ID generated at a host that doesn't appear anywhere in the Received chain โ these are the patterns the spoofing card looks for.
Why this matters now
Gmail and Yahoo started enforcing SPF, DKIM, DMARC, FCrDNS, List-Unsubscribe and one-click unsubscribe on bulk senders (5,000+ messages a day) in February 2024. Microsoft turned the same rule on for Outlook.com, Hotmail and Live in May 2025. Mail that fails the check bounces with 550 5.7.515. The headers are where you find out which check tripped and which hop wrote the verdict.
Where to go next
For the records the verdict relies on, see the DMARC checker, the SPF checker and the DKIM checker. When a Received header carries an explicit reject, the SMTP bounce codes reference decodes the SMTP enhanced status code. For the full list of header fields, the DNS record types reference covers the auth-adjacent ones.
Frequently Asked Questions
Common questions about email headers, authentication results, and phishing detection.
Basics
How do I get the raw headers out of my mail client?
Gmail: three-dot menu → Show original. Outlook (desktop): File → Properties → Internet headers. Outlook on the web: three-dot menu → View → View message details. Apple Mail: View → Message → All Headers. Copy the lot and paste it above. The body is stripped before the headers leave your browser, so attachments and content stay local.
What do SPF, DKIM and DMARC each prove?
SPF checks that the IP delivering the message is allowed to send for the envelope (Return-Path) domain. DKIM is a cryptographic signature over the canonicalised headers and body. DMARC requires that either SPF or DKIM passes and aligns with the visible From: domain. All three need to land for a high-volume sender to keep its reputation.
How do I read the Received chain?
Each relay prepends its Received header to the top of the message, so the chain reads in reverse chronological order in the raw source. The tool flips it for you. The bottom-most hop is the originating MTA. The top-most hop is your inbox provider. When tracing a forgery, work from the bottom up — the first hop whose IP doesn't belong to the claimed sender is usually where the forgery started.
Why does the verdict say spf=none or dkim=none?
none means the receiver looked and found nothing. The domain doesn't publish SPF, or the message wasn't DKIM-signed. That isn't the same as fail. A none verdict can't produce a DMARC pass on its own, so a domain with no SPF record and no DKIM signature can't pass DMARC regardless of how legitimate the sender is.
What is COMPAUTH and why do I only see it on Microsoft 365?
COMPAUTH (composite authentication) is Microsoft's own verdict that combines SPF, DKIM, DMARC and a few proprietary signals into a single pass/fail. The reason= code is what matters: 001 is an explicit DMARC failure (the message will be junked or rejected), 000 is a regular implicit-auth failure, 1xx means the receiver decided to trust the sender anyway. Microsoft documents the reason codes but the short version is: compauth=fail reason=001 is the one to fix.
What does the ARC chain do?
Forwarders break DKIM. ARC (RFC 8617) seals the original SPF/DKIM/DMARC verdict at each forwarding hop so the receiver can still see what authentication looked like before the message was edited. Each instance i= is one hop. A cv=fail anywhere in the chain invalidates the lot. ARC is on track to be moved to historic in favour of DKIM2, but until that lands it's the best forwarded-mail signal we have.
Phishing detection
How is the top-of-page verdict calculated?
It collapses every individual finding into a single line. The colour bands are: Looks legitimate (SPF, DKIM and DMARC all passed and aligned, nothing else flagged); Minor concerns (auth passed but a non-critical header looks off); Authentication or sending issues (one high-severity finding, treat with caution); Likely phishing or spoofed (DMARC failed, or two or more high-severity findings). The detailed cards below show the working.
What is FCrDNS and why does the originating IP need to pass it?
Forward-Confirmed Reverse DNS. The sending IP's PTR record resolves to a hostname, and looking that hostname up forward returns the same IP. Both directions have to agree. Most legitimate MTAs maintain it. Spam infrastructure on rented or compromised hosts usually doesn't. Receivers treat FCrDNS failure as a low-grade reputation hit on its own, and a strong signal when paired with anything else.
Why are Punycode and homoglyph domains dangerous?
Internationalised Domain Names get encoded with the xn-- Punycode prefix. So xn--pypal-4ve.com renders as pаypal.com — identical to the real brand at a glance but with a Cyrillic а in the middle. The tool flags every xn-- or non-ASCII domain in From, Reply-To and Return-Path so the look-alike doesn't slip past.
Why does a duplicate From: header matter?
RFC 5322 says a message gets exactly one From: header. When two show up, the security gateway parses one and the mail client renders the other. The gap is what attackers exploit. It's called header smuggling and it's a reliable phishing tell, not a rendering bug.
How does a Return-Path / From mismatch indicate spoofing?
From: is what the recipient sees. Return-Path: is the envelope address, set by the sending MTA, and the destination for bounces and reply-to-bounce filters. Legitimate transactional mail keeps the two on the same registrable domain. When From: claims [email protected] but Return-Path: reads [email protected], that's structural spoofing. The receiver's bounce stream and the user's reply stream are pointed at different operators.
What does "DKIM does not cover From / Subject" mean and why is it a replay-attack risk?
A DKIM signature lists the headers it covers in its h= tag. If the list leaves out From, Subject, To or Date, an attacker can grab a legitimately signed message off a mailing list, swap those headers, and the signature still verifies. It's called a DKIM replay attack. A narrow h= tag is the precondition.
Why is a private IP in a public hop worth flagging?
RFC 1918 ranges (10/8, 172.16/12, 192.168/16, fc00::/7) aren't routable on the public internet. A Received header that claims a private IP was delivered to a public mail server is either a forged Received header trying to hide the real origin, or an internal MTA that's accidentally exposed to the internet. Both are worth investigating.
Why are URL shorteners treated as a yellow flag?
Shorteners like bit.ly, tinyurl.com or t.co hide the real destination behind a redirect. That's the feature; that's also why phishing campaigns lean on them. URL scanners can't follow the link to the actual landing page until a user clicks. Reputable transactional senders almost never use them. The tool also flags display-vs-href mismatches, where the visible text claims one domain and the href points somewhere else — the most common phishing redirect pattern.
What does the TLS chain summary tell me?
Every public-internet hop in the Received chain should encrypt the message in transit using STARTTLS. The summary counts how many did and reports the TLS versions they negotiated. If even one public hop was plaintext, the message body and headers travelled in cleartext at that point. Anyone with network visibility on the path could have read them.
Deliverability
What does the spam score mean?
Most receivers run SpamAssassin or a derivative, and the rule of thumb threshold is 5.0. Above that, the message goes to junk or gets rejected outright. The X-Spam-Score header on the message is the receiver's score, not ours — it represents whatever filter sat on the inbound side. When the score is high, the X-Spam-Status header usually lists the rule hits that drove it.
What does the Compliance section check?
The headers Gmail, Yahoo and Outlook.com require on any sender pushing more than 5,000 messages a day: a one-click List-Unsubscribe-Post (RFC 8058), a List-Unsubscribe URL, a Feedback-ID, and Precedence: bulk on marketing mail. Gmail and Yahoo started enforcing this in February 2024. Microsoft turned it on for Outlook.com, Hotmail and Live in May 2025. Bulk mail without these gets 550 5.7.515 from Microsoft.