Free tool
What does this message header say?
Paste the full header and you get the servers it crossed, the time spent between each one, and whatever the receiving server wrote about SPF, DKIM and DMARC. This is reading, not checking: nothing is looked up online.
Before reading anything
A header reads from the bottom up
It is the one thing to know before looking at any result, and nobody says it. Here are the four stamps of one message: first as they appear in the text, then put back into travel order.
Received: by mx-in-02.example.net with ESMTPS id 4C2F81A0C3; Wed, 16 Sep 2026 09:41:12 +0200Received: from relais-02.example.org by mx-in-02.example.net with ESMTPS id 8B4D3C107A; Wed, 16 Sep 2026 09:41:09 +0200Received: from file-attente.example.org by relais-02.example.org with ESMTP id 2A9E15D882; Wed, 16 Sep 2026 09:40:55 +0200Received: from poste-marc.example.com by file-attente.example.org with ESMTPSA id k7sm914203; Wed, 16 Sep 2026 09:02:31 +0200
The last server is written first. Each one added its stamp above the one already there — so the bottom line is where the journey starts.
An example built for this page: the names are domains reserved for documentation, and the times are consistent with one another. The “Received” lines are shown on one line each; in a real header they are folded over two or three.
Before you paste
Where to find that header
It never shows up on its own. Every client files it somewhere else, and none of them call it the same thing.
Gmail
Open the message, click the three dots at the top right of the message, then “Show original”. A page opens with the full header and a “Copy to clipboard” button — the safest route, since it takes the whole text with no chance of an incomplete selection.Outlook for Windows
Open the message in its own window by double-clicking it, then go to File, then Properties. The header sits in the “Internet headers” box at the bottom of the window that opens. That box is small: select all of its contents before copying.Mail on the Mac
Select the message, then View, then Message, then All Headers. The full header is then shown above the message, and the setting stays on until you switch back to “Default Headers”.Any other mail client
Look for “message source”, “view source” or “full headers”. The test is simple: if all you can see is the subject, the sender and the recipient, it is not the header. You are missing the “Received” lines, and those are precisely the ones that tell the story.
Reading the result
What you will see, and what it is worth
Six cases come up again and again. Three are verdicts copied from the header, three are observations made about the route.
- spf=pass, dkim=pass, dmarc=pass
- All three checks passed at delivery time. That is as reassuring as a header gets — and it says nothing about the domain's current state, only about that day.
- spf=pass, dkim=pass, but dmarc=fail
- The most common case, and the most confusing. Both technical checks pass, yet neither authenticated domain matches the one shown in “From”. That is what alignment means, and it is what sends messages to the spam folder.
- No authentication line at all
- The receiving server recorded no verdict, or the copy stopped too early. When in doubt, go back to the source and copy the header in full.
- A hop longer than sixty seconds
- The message waited somewhere. The server to look at is the one named just before the wait: that is the one holding it, not the one that received it afterwards.
- No Received line
- There is no route in this text. More often than not, the message preview was copied — subject, sender, recipient — instead of the full header.
- Hops with no time on them
- Some servers write their stamp without a readable date, or in a format nothing can parse. The hop still appears on the route, simply with no delay beside it.
Common mistakes
Five ways to copy the wrong text
Almost every empty result comes from the copying, not from the analysis.
The message preview was copied, not the header
What causes it: Mail clients show a summary at the top of a message — subject, sender, recipient, date — that looks like a header and is not one.
What fixes it: Use “Show original”, “View source” or “All headers”, depending on your software. A real header runs to dozens of lines and starts with “Received” lines.
The copy stops halfway
What causes it: On a long header, dragging a selection with the mouse usually breaks at the first scroll, so you keep only the top of the text — which is the end of the journey.
What fixes it: Gmail offers a “Copy to clipboard” button on the “Show original” page: it takes everything, with no selection to get wrong. Elsewhere, select the whole box from the keyboard before copying.
You are analysing a forwarded message
What causes it: When someone forwards you a message so you can look at it, the header you receive is the header of the FORWARD. The original route ends up inside the body, as plain text.
What fixes it: Ask for the original as an attachment (“Forward as attachment”) rather than a plain forward: the original header then arrives intact.
A slow hop, and the wrong server gets the blame
What causes it: A stamp is written by the server that RECEIVES. So the delay shown beside a stop is the time spent at the previous server.
What fixes it: Read the name just before the wait. That is the one that held the message — a full queue, a virus scan, or rate limiting imposed by the recipient.
Concluding that the domain is fine
What causes it: A header is an archive: it says what the receiving server observed on that day, not what the domain publishes today.
What fixes it: For the current state of the records, query the domain directly — which is what our email authentication and DNS lookup tools do.
The lines that matter
What each header actually says
A header sometimes runs to a hundred lines. Six of them are enough to understand everything.
| Header | What it says | What the tool does with it |
|---|---|---|
| Received | One server's stamp: who it received the message from, who it is, and at what time. Each server adds its own ABOVE the previous ones. | The lines are put back into travel order, and the gap between two times becomes the delay for that stop. |
| Authentication-Results | The verdict the receiving server wrote itself on SPF, DKIM and DMARC, at the moment it accepted the message. | The three values are copied as they stand. Nothing is recomputed, nothing is checked again online. |
| Message-ID | The unique identifier set at sending time. It never changes afterwards, however many servers the message crosses. | Shown as it stands: this is the reference to give a host's support team so they can find the message in their logs. |
| Return-Path | The address bounces come back to. This is the one SPF checks, and it is often different from the one shown in “From”. | Not displayed, but it explains most of the “spf=pass” results that come with a “dmarc=fail”. |
| Date | The time claimed by the sending software. It comes from the sender's machine, not from a server. | Not displayed. A large gap with the first stamp points to a wrong clock, not to a delay. |
| DKIM-Signature | The signature added by the signing domain, with the selector and the domain it used. | Not displayed, but its domain is the one that appears in the DKIM verdict above. |
Lines starting with “X-” belong to each host: they are standardized nowhere, and their meaning changes from one service to the next.
The vocabulary of verdicts
The words you will read in Authentication-Results
Seven possible values, defined by the authentication results standard (RFC 8601). Only three of them call for action.
| Value | What the server observed | Does it need attention? |
|---|---|---|
| pass | The check succeeded. | No. |
| fail | The check failed outright: the sending server was not authorized, or the signature does not match. | Yes. On DMARC, this is what decides whether a message lands in spam. |
| softfail | The domain says “this server should not be sending for me”, without asking for a rejection. | Yes, eventually: this is an SPF record still being run in (it ends with ~all). |
| neutral | The domain publishes a record that takes no position on this server. | Rarely. It is a deliberately permissive setup. |
| none | The domain publishes nothing at all on this point. | Yes, if it is your domain: nothing protects it from being impersonated. |
| temperror | A passing failure prevented the check — most often a DNS query that went unanswered. | No, unless it keeps happening. |
| permerror | The record exists but is invalid: broken syntax, or too many chained lookups. | Yes. This is a configuration error, not an incident. |
Questions we get asked
Six questions about email headers
Where do I find a message's full header?
In Gmail: open the message, click the three dots at the top right of the message, then “Show original” — a page opens with the full header and a button to copy it. In Outlook for Windows: open the message in its own window, then File, then Properties; the header sits in the “Internet headers” box at the bottom. In Mail on the Mac: select the message, then View, Message, All Headers.
Is the content of my message sent anywhere?
To be precise, because a lot of tools are not honest about this. The text you paste is sent to our server to be analysed there — it does not stay in your browser. But it is not stored there, no third-party service receives it, and the analysis triggers no outbound request at all: no DNS lookup, no call to a reputation database. The reading is purely textual.
Why are the “Received” lines upside down?
Because each server writes its stamp at the top of the header, above the ones already there. So the last “Received” line in the text is the FIRST server of the journey, and the first line is the last. The tool puts them back into travel order, which is the only order in which the delays mean anything.
SPF passes, DKIM passes, and DMARC fails: how?
This is the most common case, and on the surface nothing looks wrong. DMARC is not satisfied by the checks merely succeeding: it requires the domain they authenticated to be the SAME as the one shown in “From”. A sending platform that authenticates and signs under its own name therefore makes SPF and DKIM pass while making DMARC fail. The fix is to have the platform sign in your domain's name.
Why did my message take forty minutes?
The header says so, and it is the only thing that can. Each stop carries the time a server received the message; the gap between two stops is the time spent at the one before. A long wait almost always comes from a full queue, a virus scan, or rate limiting imposed by the receiving server to protect itself.
Can this tell me whether a message is fake?
Partly, and it is worth being honest about the limit. A “dmarc=fail” on a message claiming to be from a bank is a very strong signal. But a “dmarc=pass” does not prove the sender is acting in good faith: it only proves the displayed domain really did send it. A domain registered yesterday that looks like the real one will pass every check.
What this tool does not do
Nothing is looked up online.
The analysis is purely textual: it reads what the servers wrote at the time, and goes nowhere to check whether any of it still holds today. The text is analysed on our server, and it is not stored there.
- noDNS query, no WHOIS, no reputation database
- nothird-party service receives the text
- nothingis kept once the answer is sent
The vocabulary
The words you meet inside a header
They all turn up, and mail clients explain none of them.
Received- One server's stamp. It says who it received the message from, who it is, and at what time. It is the only line that exists in several copies.
Authentication-Results- The verdict written by the receiving server on
SPF,DKIMandDMARC. Written once, on delivery, and never touched afterwards. Message-ID- The unique identifier set at sending time. This is the reference to give a host's support team so they can find the message.
Return-Path- The address delivery errors come back to. This is the one
SPFchecks, and it is often different from the one shown in “From”. MTA- Mail transfer agent: the program that moves a message from one server to the next. Every stop on the route is one.
ESMTPS- Written inside a stamp, it means that stop was made over an encrypted connection. Without the final “S”, it was made in the clear.
The threshold
When a hop counts as slow
60seconds
Past that, the tool marks the hop as a wait.
Moving from one server to the next normally takes tenths of a second. Sixty seconds is therefore a generous threshold, chosen on purpose: anything flagged really did wait somewhere. It is the value this page's engine applies.
A header says what happened when the message was sent, not what is true now.