How to get the full headers
Mail programs hide the headers behind a menu — Show original in Gmail, View message details in Outlook, Message Source in Thunderbird; “Where to find the headers” under the field above has the full path for each. Copy everything from the first line down to the empty line before the text of the message — pasting the whole message is fine too, the analyzer stops at that empty line.
The phone apps of Gmail and Outlook do not show the full headers; open the message in a browser or on a computer instead.
Reading the Received chain
Every server that handles a message adds one Received line above the others, so the chain reads from the bottom up: the lowest line is the first server, the top one is your own provider’s. One line, taken apart:
Received: from out25.mailer.example.org (out25.mailer.example.org. [198.51.100.25])
by mx.example.net with ESMTPS id k9l8m7n6o5
for <jane.doe@example.net>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 12 Oct 2026 07:42:18 -0700 (PDT)
from the name the sending host gave, then the receiver's own view of it:
its reverse DNS and the address it connected from
by the server that took the message and wrote this line
with the protocol — ESMTPS means the connection used TLS
id the receiver's queue ID, for its own logs
for the recipient
; the time the receiver took the message, with its time zone| with | Meaning |
|---|---|
| SMTP, ESMTP | Plain SMTP — no sign of encryption on this hop |
| ESMTPS | SMTP over TLS (STARTTLS) |
| ESMTPA | The sender logged in (SMTP AUTH) — a mail program submitting a message |
| ESMTPSA | Logged in, over TLS — the usual first hop from a mail program |
| LMTP, LMTPS | Hand-over to the mailbox store inside one system |
| UTF8SMTP… | The same with international (UTF-8) addresses |
The delay of each hop is the difference between its time and the one before; the analyzer converts every time to UTC first, because each server writes its own time zone. A few seconds between servers is normal. Several minutes usually mean greylisting — a receiver that turns away the first attempt from an unknown sender — or a queue. A negative delay means two servers’ clocks disagree.
Which lines you can trust
Anything written before the message reached your provider can be made up: a spammer can add fake Received lines below the real ones, and choose any From, Reply-To, Date and Message-ID. What your provider wrote after the message arrived is reliable — the top Received lines and its Authentication-Results. The analyzer marks the hop where the message was handed over: the address in that line is the one the receiving server actually saw connect, and the one to look up in a blocklist check or a WHOIS lookup.
- The display name shows an address that differs from the real one — “PayPal <service@paypal.com>” <x@example.net> — so that a phone shows only the fake.
- Reply-To at another domain. Help desks and mailing lists do this legitimately; in a message that asks for money or a password it is how the answer reaches someone else.
- DMARC fail for a sender that should pass — a bank, a large shop, your own company.
The reverse DNS in the handover line matters for mail servers you run yourself: receivers check that the sending address has a PTR record that points back to it.
Authentication results in plain words
Authentication-Results is where the receiving server writes down its checks (RFC 8601). Each method gets one result, and the property after it names what was checked: smtp.mailfrom for SPF, header.d or header.i for DKIM, header.from for DMARC. Microsoft 365 adds compauth, its own verdict that also weighs other signals.
| Result | Meaning |
|---|---|
| pass | The check succeeded for the domain named |
| fail | SPF: the server is not on the domain's list (-all). DKIM: the signature does not verify. DMARC: neither SPF nor DKIM passed for the From domain |
| softfail | SPF only: not on the list, and the domain asks for suspicion rather than refusal (~all) |
| neutral | SPF only: the domain makes no statement (?all) |
| none | Nothing to check: no SPF record, no signature, no DMARC policy |
| temperror | A DNS lookup failed at the time; the same check may pass later |
| permerror | The published record is broken — a syntax error, or more than ten SPF lookups |
Whether the published records themselves are right is a question for the SPF checker, the DKIM checker and the DMARC checker, or the mail server check for all of them at once. To build them, use the SPF record generator and the DMARC record generator.
Spam filter headers
SpamAssassin writes X-Spam-Status: Yes or No with the message’s score and the score needed for spam (5.0 by default), followed by the rules that matched. Rspamd writes X-Spamd-Result with its score and threshold. Microsoft 365 writes X-Forefront-Antispam-Report: there, SFV (the filter verdict) and CAT (the category) say how the message was handled — Microsoft states that the SCL number no longer decides it in the cloud — and BCL in X-Microsoft-Antispam rates bulk mail from 0 to 9.
A mail server of your own that ends up in spam usually lacks one of three things: SPF and DKIM that pass for the From domain, a PTR record for its address, or a clean address on the blocklists.
Frequently asked
How do I find the full headers of an email?
In Gmail, open the message and choose More (⋮) → Show original, then Copy to clipboard. In the new Outlook, Outlook on the web and Outlook.com: More actions (…) → View → View message details. In classic Outlook for Windows, open the message in its own window and choose File → Properties; the headers are in the Internet headers box. In Apple Mail: View → Message → All Headers, or Raw Source. In Thunderbird: View → Message Source (Ctrl+U). Paste everything from the first line down to the empty line before the text of the message.
How do I read the Received lines?
From the bottom up. Every server that handles a message adds its Received line at the top, so the lowest one is the first server and the highest one is your own provider's. Each line says where the message came from — the name the sending host gave, its reverse DNS and its IP address — which server took it (by), the protocol (with ESMTPS means the connection used TLS) and the time. The differences between consecutive times are the delays; the analyzer works them out and shows every time in UTC.
Can email headers be faked?
Everything the sender writes can be: From, Reply-To, Date, Message-ID and any Received lines added before the message reached your provider. What your own provider adds after it arrived — the top Received lines and the Authentication-Results — is what to trust. That is why the analyzer marks the hop where the message was handed to the receiving server, shows the address that server saw, and reads its SPF, DKIM and DMARC verdicts instead of guessing from the From line.
What does DMARC alignment mean in email headers?
DMARC passes only when SPF or DKIM passes for a domain that matches the domain in the From address. SPF vouches for the envelope sender — the Return-Path, shown as smtp.mailfrom — and DKIM for the signing domain, d=. A newsletter service often passes SPF for its own bounce domain, which does not match, and passes DMARC through a DKIM signature for your domain. The table in the results shows each domain, its result and whether it matches.
Are the headers I paste sent anywhere?
No. The analyzer runs entirely in your browser: nothing you paste is uploaded, stored or written into the page address. Headers contain e-mail addresses and server names, so the page keeps nothing — clear the field or close the tab when you are done.