What Are Email Headers?
Every email carries a set of hidden metadata called headers that record the complete journey of the message from sender to recipient. While you normally only see From, To, Subject and Date, there are often dozens of additional headers containing crucial security and routing information.
How to View Raw Email Headers
- Gmail: Open the email → click the three-dot menu (⋮) → Show original
- Outlook: Open the email → File → Properties → Internet headers
- Apple Mail: View menu → Message → All Headers
- Thunderbird: View menu → Message Source
Understanding the Received Headers
The most important headers for tracing an email are the Received headers. Each mail server that handles the email adds a Received header. Reading them from bottom to top gives you the delivery path — from the originating server to your inbox. The IP address in the bottom-most Received header is often the sender's real IP (though major providers like Gmail hide this).
SPF, DKIM and DMARC
SPF (Sender Policy Framework) verifies that the sending server is authorised to send email for the domain. DKIM uses cryptographic signatures to prove the email has not been modified in transit. DMARC ties SPF and DKIM together and tells receiving servers what to do if checks fail.
If an email fails SPF or DKIM checks, it may be spoofed — appearing to come from a domain it did not actually originate from.
Why Only the Last Received Header Can Be Trusted
Anyone can forge Received headers, since they're just text an attacker can add to a crafted message before sending it — but there's one exception: the Received header added by your own mail provider's server, at the moment it actually accepted the message, can't be faked by the sender because it reflects your own infrastructure's direct observation of the connecting IP. Everything above that trusted header in the chain could theoretically be fabricated, which is why security analysis focuses on that boundary header specifically, not the entire chain.
A Real DMARC Policy Gotcha
Setting a DMARC record with p=none does absolutely nothing to block spoofed email — it's a monitoring-only mode that just generates reports about failures without instructing receiving servers to reject or quarantine anything. Many domains publish DMARC records and assume they're protected, without realizing p=none needs to be manually upgraded to p=quarantine or p=reject after reviewing those reports, which is a step a lot of DNS setups never actually complete.
Analyze Email Headers Free
Paste your raw headers into our Email Header Analyzer to see the delivery path, authentication results and sender details in a clear visual format.
