Email Header Analyzer:
Trace a Message and Spot a Forgery
Paste the raw headers or drop an .eml file. This email header analyzer rebuilds the delivery path in order, marks which hops you can actually trust, decodes display names hidden with encoding, works out SPF, DKIM and DMARC alignment itself rather than repeating the verdict, and reads the spam filter’s own score out of the X-headers.
Quick Answer: How Do You Read Email Headers?
Email headers record every server that handled a message, in reverse order: the bottom Received line is the first hop and the top one is your own mail server. Paste them below and the analysis reorders them into delivery order, shows which hops are attested and which the sender could have invented, and reports what SPF, DKIM and DMARC actually concluded. Nothing is uploaded.
Or drop a saved .eml or .txt file here — . The file is read in this tab and never uploaded.
Everything happens in this browser tab. No upload, no logging, no network request — you can disconnect and it still works.
Message
Authentication
DMARC alignment, computed here
Derived from the domains in this message rather than copied from the receiving server’s verdict. This is what explains a pass that still fails.
| Check | Domain compared | Relaxed | Strict |
|---|
What stood out
What the receiving filter decided
Read out of the X-headers the filter wrote. This is usually the answer to “why did this land in spam”.
Delivery path
Hop 1 is where the message started
Abuse report draft
Send this to the abuse address published by the network that owns the origin IP. The ASN lookup linked further down returns that contact alongside the network name.
Every header field
| Field | Value |
|---|
Last verified 8 August 2026. The parser was tested against 370 assertions covering RFC 5322 unfolding, RFC 2047 decoding, alignment maths, trust-boundary detection, spam-verdict decoding and real message samples from Gmail, Microsoft 365 and phishing. It makes no network request of any kind.
Robert Harrison
OSINT & Network Utility Expert
The message that taught me to compute alignment myself came from a finance team in January. Their supplier notification emails had started landing in spam and the header said spf=pass, so everyone assumed authentication was fine and went looking at content filters instead. It was not fine. The mail went out through a marketing platform whose bounce domain had nothing to do with the From domain, so SPF authorised the server while DMARC refused the alignment. Two weeks lost to a line that said pass.
One limit worth stating before you rely on any of this. Headers are plain text and anyone can edit them before handing them to you. Nothing in a pasted block proves it came from a real mailbox. For anything that might end up in an investigation, get the original message file from the mail server rather than a forward, and keep a record of where it came from. This tool reads whatever you give it and has no way to know whether it is genuine.
View all articles by Robert HarrisonWhat Email Headers Are and Why They Settle Arguments
Every message carries a block of technical lines above the part you read. Each mail server that touches the message adds its own line to the top of that block, so by the time it reaches your inbox the headers hold a complete record of the route, the timings, and what each server concluded about the sender's identity.
That record matters because the From: line is not evidence of anything. It is a display field, and a sender writes whatever they like in it. What cannot be freely invented is the chain of servers that actually handled the message and the authentication verdicts those servers recorded. To analyze email headers is simply to read that part instead of the part designed to be read. The block is also called the message header, and a tool that parses it is variously a header analyzer, a header checker, or an RFC 5322 parser — all the same job.
Three situations bring people here. A message looks like it came from a bank and they want to know whether it did. Their own mail has started landing in spam and they need to see what receiving servers are concluding. Or an abuse desk needs the originating address to file a report. The same block of text answers all three.
The single most useful habit: read every Received header from the bottom upward. The bottom-most one is the first hop, closest to the sender. Each line above it was added later. Reading top-down is the most common mistake, and it inverts the entire story. The tool above reorders them so hop 1 is genuinely first.
Before you can read anything, you need the raw text, and every mail client hides it somewhere different.
How to Get Raw Email Headers Out of Any Client
The block you need starts at the very top of the message source and ends at the first completely blank line. Everything after that blank line is the body, and you do not need it.
| Client | Where to click |
|---|---|
| Gmail (web) | Open the message → three dots at top right → Show original |
| Outlook.com / Outlook web | Open the message → three dots → View → View message source |
| Outlook desktop | Open the message in its own window → File → Properties → Internet headers |
| Apple Mail | View → Message → Raw Source |
| Thunderbird | Select the message and press Ctrl+U (Cmd+U on macOS) |
| Proton Mail | Three dots on the message → View headers |
| Yahoo Mail | Three dots → View raw message |
Do not use a forward. Forwarding a message rewrites the headers. The chain you end up analysing belongs to the forward, not the original, and the original authentication results are gone. If somebody else received the message, ask them for the raw source or the .eml file rather than asking them to forward it.
Once you have the text, the first thing worth understanding is which parts of it you are allowed to believe.
Which Hops You Can Trust, and Which the Sender Wrote
This is the part most tools skip, and it changes how you read everything else. Headers are added by each server in turn, but the sender's own machine adds the first ones. A sender who wants to mislead you can write convincing Received lines that look exactly like legitimate internal routing before the message ever leaves their control.
The boundary sits at the first server the recipient's side controls. Everything from that point upward was written by infrastructure you or your provider operate, and it can be believed. Everything below it is a claim made by whoever sent the message.
| Position in the chain | Who wrote it | How much weight it carries |
|---|---|---|
| Hop 1, the bottom line | The sender's own system | A claim. Can be entirely fabricated |
| Middle hops before your provider | Relays in between | Depends on who runs them |
| Your provider's first server | Gmail, Microsoft 365, your own MX | Attested. This one saw the real connection |
| Everything above that | Your own infrastructure | Attested |
The practical consequence: the IP address recorded by the first server you control is the one that matters, because that server watched the connection open. Anything claimed below it is unverified. The analysis reports that address as the attested origin, and if a lower line names a different one it shows that separately rather than merging the two. In relayed mail the two differ as a matter of course, so the distinction is a labelling one rather than an alarm. Reporting the lowest address in the chain, which several tools do, is how an abuse complaint ends up aimed at a network that never sent anything.
Finding that boundary means working out which hostnames belong to the receiving side, which the analysis infers from the chain and the recipient address. It says so when the inference is less certain rather than presenting a guess as a fact.
What to do with that address: once you have the attested origin IP, our IP geolocation and ISP lookup tells you which network it belongs to, and the IP blacklist checker shows whether it already appears on spam blocklists. For an abuse report you want the network operator behind it, which our ASN lookup resolves along with the published abuse contact.
The other half of the picture is what the receiving server concluded about the sender's identity, and that is where most confusion lives.
SPF, DKIM and DMARC: What Each Verdict Actually Means
Three mechanisms, three different questions. Conflating them is why people misread results.
SPF asks: was this server allowed to send for this domain?
SPF compares the sending server's IP address against a list the domain owner publishes in DNS. Critically, the domain it checks is the envelope sender, which lives in Return-Path, not the address shown in From. Those are frequently different, and that difference is the source of most confusion.
DKIM asks: was this message signed, and is the signature intact?
DKIM puts a cryptographic signature in the headers, signed by a key published in the signing domain's DNS. A pass tells you the message was not altered in transit and that the signing domain vouched for it. It says nothing about whether the signing domain is the one in the From line.
DMARC asks: do those results line up with what the reader sees?
DMARC is the layer that connects the other two to the From address. It requires that either SPF or DKIM passed and that the domain involved aligns with the From domain. Alignment comes in two flavours: relaxed, where the organisational domains have to match, and strict, where they have to be identical.
| What you see | What it means | What to do |
|---|---|---|
spf=pass dmarc=pass | Authorised and aligned | Authentication is healthy |
spf=pass dmarc=fail | Authorised for a different domain than the one displayed | Fix alignment, not the SPF record |
spf=fail dkim=pass dmarc=pass | Normal for forwarded mail. DKIM carried it | Nothing. This is the system working |
spf=none | The domain publishes no SPF record at all | Publish one |
dkim=none | The message was not signed | Enable signing at the sending platform |
No Authentication-Results | The receiver recorded no verdict | Nothing can be concluded from these headers |
The row that costs people weeks: spf=pass alongside dmarc=fail. It looks contradictory and it is not. SPF authorised the server for the bounce domain; DMARC then noticed the bounce domain is not the From domain and refused the alignment. The analysis above computes both alignments itself and names this case when it appears, because reading the verdict alone leads people to conclude authentication is fine when it is not.
Once you understand alignment, the spoofing patterns become easy to recognise.
Seven Spoofing Patterns and How They Show Up in Headers
None of these require sophistication. All seven forms of email spoofing appear in ordinary phishing every day, and every one leaves a trace in the headers.
1. The display name says one thing, the address says another
The most common trick and the easiest to spot once you look. A mail client shows Your Bank Security and hides the actual address behind it. Worse, the display name itself is often encoded so a naive parser shows base64 gibberish instead of what the victim saw. The tool decodes it.
2. Reply-To points somewhere else entirely
The From line survives casual inspection, but replies quietly go to an attacker-controlled address. A mismatch between the two domains is a strong signal and costs nothing to check.
3. Return-Path belongs to a throwaway domain
Bounces go where the sender wants them. When Return-Path and From are unrelated domains, SPF can pass for the throwaway while DMARC fails on alignment. This is exactly the pattern in the phishing sample above.
4. A lookalike domain
Character substitution, an extra hyphen, a different top-level domain. Headers show the exact domain string, so compare it character by character rather than at a glance. Our punycode converter reveals domains that use non-Latin characters to imitate a familiar name.
5. Fabricated hops below the trust boundary
Invented Received lines that suggest the message came from somewhere respectable. They sit below the first server you control, which is precisely why that boundary is worth marking.
6. Two of a header that should appear once
A message carrying two From lines, or two Subject lines, is exploiting the fact that a security gateway and a mail client may not pick the same one. The gateway inspects the harmless copy, the client displays the other. Nothing legitimate needs a second From line, so the analysis treats a duplicate as a serious signal.
7. A compromised but genuine account
The hardest case. Authentication passes because the message genuinely came from the real account. Headers will look clean. This is the reason a pass means authenticated, not trustworthy, and the reason header analysis is one signal rather than a verdict.
Worth repeating: a DMARC pass proves the message came from a server authorised by the domain. It does not prove the human behind it means well. Treat authentication as one input alongside the content, the context and whether you were expecting the message at all.
Reading the Timeline: Delays, Skew and What They Tell You
Each Received line carries a timestamp, so the chain doubles as a delivery timeline. Most of the time it is unremarkable, and the exceptions are informative.
A gap of several minutes between two hops
Usually greylisting. The receiving server deliberately rejected the first attempt and accepted the retry, which is a normal anti-spam measure. A four-minute pause between two hops is far more likely to be greylisting than anything sinister.
A gap of hours
A queue. Something downstream was unreachable and the sending server held the message. Common during outages and worth correlating with your own monitoring rather than reading as an attack.
A negative delay
A hop that appears to have received the message before the previous hop sent it. This looks alarming and is almost always clock skew: mail server clocks drift, and a server running a few seconds behind stamps a time that reads as earlier. The analysis names it as skew rather than leaving you to draw the dramatic conclusion.
No timestamps at all
Some minimal or handwritten headers omit them. The chain is still readable; only the timing is lost.
Do not build a case on timing alone. Clock differences of seconds are routine and mean nothing. Real tampering shows up as authentication failures, domains that do not line up, and hops that contradict each other, not as a few seconds of drift between two servers.
One more header type deserves attention, because it explains failures that otherwise make no sense.
ARC: Why Forwarded Mail Fails DMARC, and How It Survives
Forwarding breaks email authentication. When a mailing list or a forwarding rule passes a message along, the relay becomes the sending server, so SPF now checks the relay rather than the original sender and fails. If the relay modified anything, a subject prefix or a footer, DKIM breaks too. A perfectly legitimate message then fails DMARC.
ARC, the Authenticated Received Chain, exists to solve exactly this. Each intermediary records the authentication results it saw before touching the message and seals that record cryptographically. A receiving server further down can look at the ARC chain, decide whether it trusts the intermediary, and honour the original verdict rather than the broken one.
| Header | What it holds |
|---|---|
ARC-Authentication-Results | The SPF, DKIM and DMARC results this intermediary observed |
ARC-Message-Signature | A signature over the message as the intermediary received it |
ARC-Seal | A signature over the ARC set itself, chaining it to any earlier ones |
Each set carries an instance number, i=1 for the first intermediary and upward from there. Seeing ARC headers in a message that failed SPF is usually the explanation rather than a problem: the message was forwarded, and the chain is doing its job. The analysis counts the seals and says so.
If you are on the sending side and want your own domain's authentication in order before any of this matters, our DNS record lookup shows the SPF, DKIM and DMARC records a domain currently publishes, and the guide to SPF, DKIM and DMARC blocklists covers what receiving servers do with them.
What Changed in 2026: Enforcement, and a New DMARC Specification
If you are reading headers because your own mail stopped arriving, the ground moved recently and it is worth knowing exactly how. Two separate things happened: the big mailbox providers stopped being polite, and the specification itself was rewritten.
Rejection replaced deferral
Gmail moved from temporary deferrals to permanent rejections for non-compliant bulk mail in November 2025, and Outlook applied its own hard rejection the same month. Yahoo follows the same rules. A message that fails now does not sit in a queue or land in spam — the receiving server refuses it outright. Microsoft's refusal carries a specific code worth recognising in a bounce: 550 5.7.515 Access denied, sending domain does not meet the required authentication level. A recipient adding you to their safe-sender list does not override it, because the check runs before personal allow lists are consulted.
The threshold that triggers all of this is 5,000 messages a day to a given provider's consumer addresses. Below that you have more latitude, and above it SPF, DKIM, DMARC and a working one-click unsubscribe are simply required.
DMARCbis, published May 2026
The IETF published an updated DMARC specification in May 2026 as RFC 9989, 9990 and 9991, which together make the original RFC 7489 obsolete. Two things matter for anyone reading headers or maintaining records.
Nothing you have breaks. Records still begin with v=DMARC1 and there is no such thing as DMARC2. Existing published records remain valid exactly as they are.
A few tags changed. The most useful addition is np, which sets a policy for mail claiming to come from subdomains that do not exist at all. That closed a real spoofing gap: an attacker could send as invoices.yourdomain.example when no such subdomain had ever been created, and the original specification had no clean way to cover it. There is also a t tag, a plain yes-or-no flag marking a policy as provisional while you test it.
| Tag | Status after DMARCbis | What it does |
|---|---|---|
v=DMARC1 | Unchanged | Still the required opening tag |
p | Unchanged | Policy for the domain: none, quarantine or reject |
sp | Unchanged | Policy for subdomains that exist |
np | New | Policy for subdomains that do not exist |
t | New | Marks a policy as provisional while testing |
And a reason it is no longer optional
PCI DSS version 4.0 introduced requirement 10.4.1.1, which obliges organisations handling cardholder data to run anti-phishing controls that explicitly include DMARC. It became mandatory during 2025 and is being enforced through 2026. For a business that takes card payments, an expired or misconfigured DMARC record is now a compliance problem rather than an IT preference.
The sequencing that saves you: get SPF and DKIM passing cleanly for a few days and confirm they are stable before you turn DMARC enforcement on. Publishing p=reject on top of an authentication setup you have not verified is the fastest way to block your own legitimate mail. Check what your domain currently publishes with the DNS record lookup linked in the previous section, then use the analysis at the top of this page to see what receiving servers are actually concluding about real messages.
Five Mistakes People Make Reading Headers
Ordered by how often they happen rather than how serious they are.
1. Reading the Received chain top-down
The top line is your own mail server, the last one to touch the message. Reading downward tells the story backwards and points you at the wrong origin entirely. The tool reorders them so hop 1 is genuinely first.
2. Treating spf=pass as proof the sender is who they claim
SPF authorised a server for the bounce domain. If that domain is not the From domain, the message can still be a forgery with a perfectly valid SPF pass. Alignment is the check that matters.
3. Believing hops below the trust boundary
Anything the sender's own systems wrote is a claim. Convincing internal-looking routing is trivial to fabricate.
4. Analysing a forward instead of the original
Forwarding rewrites the headers. You end up analysing the forwarding path and the original authentication results are simply gone. Always ask for the raw source or the .eml file.
5. Concluding an attack from a negative delay
Clock skew. Mail server clocks drift by seconds routinely and it means nothing.
A workable order of operations: get the raw source rather than a forward, read the chain bottom-up, find the first hop your own provider recorded, check alignment rather than raw verdicts, then look up the attested origin IP. Five steps, and they answer most questions people bring to a suspicious message.
Email Header Analysis: Frequently Asked Questions
What is an email header analyzer?
It is a parser for the technical block of text that sits above every email message. Those lines record which servers handled the message, when each one received it, and what the receiving mail system concluded about SPF, DKIM and DMARC. Reading them by hand is slow and easy to get backwards, so a parser lays the same information out in order and explains what each part means.
How do I get the raw headers out of my email?
In Gmail, open the message, click the three dots and choose Show original. In Outlook on the web, open the message, click the three dots and choose View, then View message source. In Apple Mail it is View, then Message, then Raw Source. In Thunderbird press Ctrl+U. Copy everything from the top down to the first blank line and paste it in.
Which part of the headers can I actually trust?
Only the hops added by servers the recipient controls. Anything below that point was written by whoever sent the message, and a sender can invent convincing Received lines that look like internal routing. The analysis marks that boundary so you know which lines are attested and which are simply claims.
Why did SPF pass but DMARC still fail?
SPF checks the envelope sender, which is the address bounces go to, not the address shown in the From line. If a message is sent from an authorised server for one domain while displaying a different domain in From, SPF passes and DMARC fails because the two do not align. The tool computes that alignment itself rather than only reprinting the verdict, and names it when it happens.
Does this tool send my headers anywhere?
No. The entire analysis is JavaScript running in your browser. There is no upload, no API call and no logging. You can open the page, disconnect from the network, and it still works. That matters because headers routinely contain real names, internal hostnames, private IP addresses and message identifiers.
Can I find the sender's physical location from the headers?
You can find the IP address of the first server that handled the message, and that address can be looked up. What it gives you is where that server sits, which is often a data center in another country entirely. It is not the sender's home address, and for anything sent through a webmail provider it is only the provider's infrastructure.
Why did my message land in spam when authentication passed?
Authentication and filtering are separate decisions. A message can pass SPF, DKIM and DMARC and still be scored as spam on content, reputation or complaint history. Most filters write their score into the headers, so the analysis reads it back out: a SpamAssassin score against its threshold, or a Microsoft SCL and BCL value with what each number means. That is usually the answer rather than anything in the authentication lines.
What does an ARC seal mean?
ARC records that a message was forwarded and that an intermediary vouched for the authentication results it saw before forwarding. Mailing lists and forwarding rules break SPF and DKIM, so without ARC a legitimate forwarded message can fail DMARC. Seeing ARC seals usually explains an otherwise confusing authentication failure.
A hop shows a negative delay. Has the message been tampered with?
Almost certainly not. Mail server clocks drift, and a server whose clock runs slightly behind the previous one will stamp a time that looks earlier. The analysis names this as clock skew rather than leaving you to draw an alarming conclusion from it. Tampering shows up as authentication failures and inconsistent domains, not as a few seconds of clock difference.
Related Email & Network Tools
Follow the trail with the rest of the TrustMyIP toolkit.
Stop Guessing Whether That Message Is Real
The Headers Already Know
Paste the raw headers and get the delivery path, the trust boundary, decoded display names and computed alignment. Nothing leaves your browser.