Email Header Analyzer guide
How to copy full email headers, what the XGM Email Header Analyzer shows about delivery hops, delays and authentication, and how to spot spoofing signs.
What email headers contain
Every mail server that handles a message adds a Received header at the top, recording where it got the message from, its own name and a timestamp. The receiving mail server also adds Authentication-Results, which records the outcome of SPF, DKIM and DMARC checks. Together they are the closest thing to a delivery receipt email has.
Headers added before your provider's servers are written by other systems and can be forged, while headers added by your own provider are trustworthy. That is why analysis usually starts at the top, with the hops your provider added, and works down.
Copying the full headers
Mail clients hide headers by default, so you need the "original" or "source" view. Copy everything from the first line down to the start of the message body; the analyzer ignores the body if you include it.
| Client | Menu |
|---|---|
| Gmail (web) | Open the message, three-dot menu → Show original |
| Outlook (web and new Outlook) | Open the message, three-dot menu → View → View message source (or message details) |
| Apple Mail | View → Message → All Headers, or Raw Source |
| Thunderbird | View → Message Source |
Menu names change between versions, but every major client has an option labelled original, source or headers. Forwarding a message does not preserve its original headers; forward it as an attachment if someone else needs to analyse it.
How to use the analyzer
- Open the Email Header Analyzer and paste the full headers.
- Read the summary: From, Return-Path, Reply-To, Subject, Date and Message-ID.
- Check the SPF, DKIM and DMARC results taken from
Authentication-Results. - Follow the hop timeline to see where time was spent, and read the warnings.
- Export the result as JSON to get every parsed header, including the full
Authentication-Resultsline with the DKIM selector (header.s) and signing domain (header.d).
Stays in your browser
Reading authentication results
Authentication-Results: mx.example.net;
dkim=pass header.i=@example.com header.s=s2026a header.b=AbCdEf12;
spf=pass (example.net: domain of bounce@example.com designates 192.0.2.25 as permitted sender) smtp.mailfrom=bounce@example.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com| Result | Meaning |
|---|---|
pass | The check succeeded |
fail | The check failed: not authorised (SPF), bad signature (DKIM), or not aligned (DMARC) |
softfail | SPF ~all matched: not authorised, treat with suspicion |
neutral / none | No usable statement, or no record published |
temperror | A temporary DNS problem prevented the check |
permerror | The record is broken, such as an SPF record over the lookup limit |
DMARC is the result that ties the others to the visible From address. A message can show spf=pass for a sending service's bounce domain and still fail DMARC, because that domain is not aligned. The DMARC guide explains alignment, and the DKIM guide covers signature failures.
What the warnings mean
| Warning | Why it matters |
|---|---|
| DMARC failed | The From domain was not authenticated by an aligned SPF or DKIM result; the message may be spoofed. |
| SPF fail or softfail | The sending server is not authorised by the envelope domain. |
| DKIM failed | The signature does not match; the message may have been modified in transit. |
| Envelope sender differs from the From domain | Common for mailing services, but also for spoofing; check DMARC. |
| Replies go to a different domain | A Reply-To on another domain is a common phishing pattern. |
| Hops with earlier timestamps | A server clock is wrong, or headers were forged. |
| No headers found | Paste the full original message source, headers first. |
When all three authentication results pass and the From domain is one you expect, the message almost certainly came from that domain's mail system. When DMARC fails for a domain that publishes p=reject, most large providers would have rejected it, so finding it in an inbox is itself worth reporting.
Warnings are signals, not verdicts. Newsletter platforms routinely use their own envelope sender, and support desks set Reply-To addresses on purpose. Combine the warnings with the authentication results and the context of the message.
Finding delivery delays
The analyzer calculates the time between consecutive hops and the total from the first to the last. A delay of seconds is normal, a few minutes can come from spam filtering or queueing, and hours usually mean a server retried after a temporary failure. The hop where the delay appears points to the system responsible.
| Where the delay is | Likely cause |
|---|---|
| Before the first hop of the sending provider | Message queued in the sender's client or application |
| Between the sending server and the recipient's MX | Receiver deferred the message (greylisting, rate limits, temporary errors) |
| Inside the recipient's system | Content scanning, sandboxing of attachments, or internal queues |
| Negative delay | Clock differences between servers or forged headers |
FAQ
Are my headers uploaded?
No. The analyzer runs in your browser, and the pasted text is not sent to XGM.
Which Received header is the first hop?
The bottom one. Each server adds its header on top, so the analyzer reverses the list to show delivery order.
Can Received headers be faked?
Headers added before the message reached your provider can be forged by the sender. Headers added by your own provider's servers are reliable.
Why does SPF pass but DMARC fail?
SPF passed for the envelope sender's domain, which is not aligned with the From domain. DMARC needs an aligned SPF or DKIM pass.
How can I find the DKIM selector?
Look for header.s= in Authentication-Results, or s= in the DKIM-Signature header. Both are in the pasted source and in the analyzer's JSON export.
Why are there more hops than servers I know about?
Large providers pass messages through several internal systems for filtering, scanning and storage, and each adds a Received header. Only the hops between organisations usually matter for troubleshooting.
What does the with field in a hop mean?
It names the protocol used for that hop, such as ESMTPS (SMTP with TLS) or ESMTPSA (with TLS and authentication). Plain SMTP or ESMTP means that hop was not encrypted.
Why is authentication shown as not found?
The headers do not contain an Authentication-Results line with that method. Some clients strip it, or the paste started after it; copy the full original source.
Can I tell where the sender is located?
Only roughly. The first external hop often shows the sending server's IP, which you can look up with IP Intelligence, but that is usually a mail provider, not the person.
What should I do with a phishing message?
Report it through your mail client's phishing button or to your IT team. Header analysis helps confirm spoofing, but do not click links or reply.