Free tool
Email header analyzer
Paste the headers of an email and read what they actually say: what the receiving server reported for SPF, DKIM and DMARC, whether the visible sender matches the domain that authenticated, the route the message took and where it lost time.
No headers found in that text
Nothing in what you pasted looks like an email header — this is the usual first try. Headers are the technical lines above the message, each one starting with a name and a colon: Received:, From:, Authentication-Results:. Your mail client hides them by default; the steps below show how to reveal them in the one you use.
How to find the headersResult
- From
- Subject
- Sent
What the receiving server reported
These lines were written by the server that received the message. Sentinely reads them — it does not re-run the checks, and it could not: the headers you pasted are the only evidence here.
These headers carry no authentication results
That is not a failure — it means nothing was reported, so nothing can be said about SPF, DKIM or DMARC. It is normal for a copy taken from the Sent folder, and for a paste that stops before the receiving server had its say.
Does the visible sender match?
This is what DMARC actually asks: the domain your reader sees in the From line has to match the domain that authenticated. A message can pass SPF and still fail DMARC, because it passed for somebody else’s domain.
These headers carry no visible From address, so there is nothing to align against.
Visible From domain
Signing domains seen
One domain is a subdomain of the other, which satisfies DMARC’s default (relaxed) alignment. Confirming the organisational domain exactly would need the public suffix list, which is deliberately not consulted here — nothing you paste triggers a lookup.
What stands out
The route it took
Every server that handled the message stamped a line on the way. Read top to bottom — oldest first, with the time each step took.
These headers carry no Received lines, so there is no route to show.
Total time
Hops
Slowest step
At least one server’s clock disagrees with the one before it, so some steps cannot be timed. The timestamps below are read exactly as written.
| # | From | Received by | Delay | Transport | Timestamp |
|---|
Timestamps are shown in your own time zone.
Show the individual headers
- To
- Reply-To
- Return-Path
- Message-ID
Getting the headers
Where the headers hide, client by client
Every mail client keeps them one menu away from the message. Copy everything you see — the block is long, and the useful lines are usually at the top.
Gmail (web)
Open the message, click the ⋮ menu at the top right of the message itself (not the one in the toolbar) and choose “Show original”. The page that opens has a “Copy to clipboard” button — it copies the whole message, which is fine.
Outlook (Windows, desktop)
Open the message in its own window, then File → Properties. The headers are in the “Internet headers” box at the bottom: click inside it, select all, copy.
Outlook on the web / Outlook.com
Open the message, click the ⋯ menu at the top right and choose “View” → “View message details”. Copy everything in the panel.
Apple Mail (macOS)
Select the message, then View → Message → All Headers (⇧⌘H). For the complete block use View → Message → Raw Source (⌥⌘U) and copy from the top down to the first blank line.
Thunderbird
Select the message and press Ctrl+U (⌘U on macOS) for the source, or View → Headers → All to see them inline.
Yahoo Mail
Open the message, click the ⋯ (More) menu and choose “View raw message”. Copy the whole page.
Reading the result
What the answer tells you — and what it cannot
The results are claims, not checks
SPF, DKIM and DMARC results sit in the headers because the receiving server wrote them there when the message arrived. Reading them tells you what that server concluded at that moment. Nobody can re-run the check afterwards: the message has already been delivered, and DNS may have changed since.
Missing is not failing
Headers with no authentication results have not failed authentication — nothing was reported. A copy from your Sent folder has none, and neither does a paste that stops too early. Read silence as “unknown”, never as “bad”.
Alignment is the part that bites
SPF can pass for the platform that sent the message while the address your reader sees is yours. DMARC only accepts a pass whose domain matches the visible From — which is why a message can pass SPF and still be rejected.
The delays are real, the clocks may not be
Each Received line carries the time its server stamped. Add them up and you can see where a message waited. But those clocks belong to different organisations: when one disagrees with the one before it, that step is flagged rather than guessed.
One message is one message
A header block describes a single delivery to a single recipient. It cannot tell you how much mail leaves your domain, who else sends as you, or whether yesterday’s campaign authenticated — that lives in the aggregate reports mailbox providers already send about your domain.
Nothing here is looked up
The analysis reads the text you paste and nothing else: no DNS query, no connection to any server named in the headers, no signature verification. That is what keeps it fast and private, and it is also the limit — a domain written in a header is a claim like everything else.
Questions
About this tool
Do you store the headers I paste?
No. They go from your browser to the analysis API, which reads them and returns the result without writing them to a database, a file or a log. The page keeps nothing either: no history, no browser storage, nothing sent to analytics. Reload and it is gone.
Do I need an account?
No. No sign-up, no email address to leave, no limit per person — just a cap of a few analyses per minute, so the tool stays open to everyone.
Can I paste the whole email, body and all?
Yes. Everything after the first blank line is the body: your browser drops it before sending, so only the header block ever leaves your machine. If the block itself is enormous, the tool says so before sending anything.
It says “no headers found” — what did I do wrong?
Almost always the message was forwarded instead of exported. Forwarding writes fresh headers and buries the originals in the body. Go back to the message you received and use “Show original” (Gmail), “Properties” (Outlook) or “Raw source” (Apple Mail).
SPF says pass but DMARC says fail. How?
Because they look at different domains. SPF checks the envelope sender, which usually belongs to the platform that sent the message. DMARC only counts a pass whose domain matches the From address your reader sees. When the two differ and DKIM does not cover it either, DMARC fails.
Does this tell me whether my domain is protected?
No — it reads one message. What leaves your domain every day, who else sends in your name and whether that mail authenticates lives in the DMARC aggregate reports mailbox providers already send about your domain. That is what Sentinely does the rest of the time.
That was one message. What about all the others?
Mailbox providers already report on every message sent in your name. Publish one DNS record and Sentinely turns those reports into the same kind of plain answer — for the whole domain, every day.