Email header analyzer
Paste raw email headers to trace the delivery path, check authentication, identify delays, and understand what each header means.
Where to find the raw headers
Headers are hidden by default in every mail client, because almost nobody needs them until something goes wrong. The option is usually worded as showing the original or the source.
- Gmail: open the message, use the menu at the top right of it, and choose to show the original.
- Outlook on the web: open the message menu and look for viewing the message source.
- Apple Mail: under the View menu, choose the message and then all headers.
Copy everything from the top down to the first blank line and paste it above. The body is not needed and is better left out.
How to read the results
- Read Received headers from the bottom up. Each server prepends its own line, so the oldest hop is at the bottom and the most recent at the top. That bottom entry is the closest thing you have to where the message really started.
- Authentication results show what the receiving server concluded about SPF, DKIM and DMARC. This is the receiver's verdict, recorded at delivery time, which makes it the most trustworthy part of the header.
- Return path and From can differ. The From address is what the recipient sees, the return path is where bounces go. Mailing lists and bulk senders legitimately differ here, but so does a forged message.
- Message ID uniquely identifies the message and usually contains the sending system's hostname. It is the value to quote when asking a provider to trace a delivery.
- Time gaps between hops localise a delay. A message that sat for twenty minutes at one server was queued there, and that is the operator to ask.
Spotting a forged sender
Headers are the only reliable way to judge a suspicious message, because the display name and the visible address are trivially faked and everything else in the body can be copied perfectly.
- DMARC failed on a domain that publishes a policy. The single strongest signal. It means the message did not come from a server the domain authorises.
- SPF or DKIM passed on a different domain than the one in the From address. This is a pass without alignment, and it is exactly what a convincing forgery looks like.
- The earliest Received hop does not match the claimed sender. A message claiming to be from a bank that originated on a consumer mail host is not from that bank.
- Reply-To pointing somewhere unrelated. A common trick, since the reply quietly goes to the attacker while the From address looks legitimate.
Common questions
Can email headers be faked?
The sender can write anything into the headers they generate, including forged Received lines. What they cannot forge are the lines added by the receiving servers, since those are written after the message leaves their control. Trust the hops nearest the top and the authentication results, not the ones the sender supplied.
Does the header show the sender's real IP address?
Often, but not reliably. The earliest Received line shows the first server that handled the message, which for a normal send is the sender's mail provider rather than their computer. Many providers deliberately strip the originating client address for privacy, so its absence is not suspicious by itself.
SPF passed but DMARC failed. How?
DMARC requires alignment as well as a pass. If SPF passed on the sending service's own domain rather than the domain in the visible From address, there is a pass without alignment and DMARC still fails. Signing with DKIM on your own domain is the usual fix for legitimate mail that hits this.
Why did my message take hours to arrive?
Compare the timestamps on consecutive Received lines and find the gap. Delay at one hop usually means greylisting, where a receiving server deliberately defers a first delivery attempt, or a queue caused by rate limiting. The server holding the message is the one to investigate.