How to Read Email Headers
Email headers record how a message travelled and what checks were made on the way. They are useful, but each line was written by a machine you may not control, and reading them well means knowing which lines to trust.
Getting the full headers
Mail clients show a short summary by default. Look for 'show original', 'view source' or 'message properties' to see the raw header. Copy from the first line down to the blank line that separates the header from the body. Long fields are folded across lines that begin with spaces, so do not trim indentation. Headers contain addresses, IP addresses and internal host names, so share them only with people who need them. The header analyzer processes pasted text in memory and does not keep it.
The Received chain
Each server that handles a message adds a Received line at the top. This means the chain reads upward: the oldest hop is at the bottom and the newest at the top. A line says which host the server received the message from, which server it is, the protocol used (for example ESMTPS when TLS was used) and a timestamp.
Only the topmost line, added by your own receiving system, is firmly under your control. Lines below it were written by other servers and describe what those servers claim. A sender can add fake Received lines at the start so that they appear lower in the stack. Timestamps that run backwards often indicate clock skew, but may also show editing. Private addresses in the chain are normal inside organisations and unremarkable in themselves.
Authentication-Results
This header, defined in RFC 8601, is where a receiving system records the verdicts it reached. It starts with an authserv-id naming the system that made the checks, followed by results such as spf=pass smtp.mailfrom=example.net, dkim=pass header.d=example.net header.s=selector1 and dmarc=pass header.from=example.com. The property after each result says which identifier was tested, and that is what matters for alignment.
A header can contain several of these lines. Only the one whose authserv-id is your own mail system is the result you should rely on, and well-run receivers remove any pre-existing lines claiming to be theirs before adding their own. If the message arrived through a provider you do not control, the line may simply be text from elsewhere.
Why header results are claims, not proof
Anyone who can send a message can include a header saying dkim=pass. Nothing in the text proves a verification took place. The only protection is that your receiving server discards such lines and writes its own. Even correct entries are limited: they record what was checked at delivery time, using DNS as it was then.
Because of this, the header analyzer labels everything it reads as claimed by the header, does not turn a header statement into a pass, and does not cryptographically verify DKIM or ARC signatures. Its optional live DNS lookups show what a domain publishes today, which may differ from delivery time.
SPF, DKIM and alignment in a header
- SPF:
smtp.mailfromorsmtp.heloshows which envelope identity was tested. A pass says the connecting IP was allowed for that domain, not for the From domain. - DKIM:
header.dis the signing domain andheader.sthe selector. A valid signature by an unrelated domain does not help DMARC. - DMARC:
header.fromis the domain being protected. A pass means SPF or DKIM passed with an aligned domain. - Received-SPF: an older style line with similar claims and the evaluated IP.
- ARC: a set of
ARC-Seal,ARC-Message-SignatureandARC-Authentication-Resultslines added by intermediaries such as forwarders, to preserve earlier results. ARC records an intermediary's claim; whether to trust it depends on whether you trust that intermediary.
Warning signs worth checking
- A
Reply-Topointing to a different domain thanFrom. - A display name containing a different email address from the real one.
- More than one
Fromheader. - A
Datefar from the first Received timestamp. - DKIM or SPF passing for a domain that has nothing to do with the From domain.
- Results in the header that your own server did not write.
- None of these is proof of fraud on its own; newsletters, forwarding and mailing lists produce several of them legitimately.
A reading routine
- Copy the full original header.
- Read the Received chain from the bottom upward and note any gaps, delays or odd timestamps.
- Find the Authentication-Results line whose authserv-id belongs to your own system.
- Compare the SPF and DKIM domains with the From domain for alignment.
- If something needs a closer look, check the sender's current SPF, DKIM and DMARC records with the individual checkers, remembering these show today's DNS.
- Report suspected phishing to your provider and security team rather than deciding from headers alone.
Frequently asked questions
Which Received line should I trust?
The one added by your own server, at the top. Lower lines are claims made by other systems.
Does dkim=pass in the header prove the message is genuine?
No. It is a statement by whichever system wrote the line, and it needs a domain that aligns with From to matter for DMARC.
Why does SPF fail after forwarding?
The forwarding server's IP is not in the original domain's SPF record. DKIM often survives if the content is unchanged.
Is the header I paste into the analyzer saved?
No. It is analysed in memory, not stored, and not reproduced in the report.
Written by DNS Tools editorial · Last updated 2026-10-09