Every email you receive carries a hidden data block called the header, and it contains a complete forensic record of the message: who sent it, which servers handled it, what authentication checks it passed or failed, and precisely when each hop occurred. Most mail clients fold these details away so your inbox stays readable, but they are always there, one or two clicks from the surface. Understanding how to find and read them is one of the most practical skills in email security, whether you are trying to decide if a "bank" message is genuine, tracing why a legitimate email ended up in spam, or just curious about how the internet actually routes mail. This guide walks through every major header field, shows you how to view headers in the most common clients, and explains what to look for when something seems off.
Where to Find the Full Headers
Every mail client hides headers behind a slightly different menu, but they are always accessible. In Gmail, open the message and click the three-dot menu in the top-right corner of the email, then choose "Show original." This opens a new tab with the raw message, including the complete header block at the top and the source below. In Outlook (desktop), open the message in its own window, go to File → Properties, and the full header text appears in the "Internet headers" box at the bottom of that dialog. Apple Mail on macOS has the option under View → Message → All Headers, or you can use View → Message → Raw Source for the complete RFC 5322 message. On mobile the headers are harder to access, which is why phishing analysis is better done on a desktop where the raw text is readable. Google's Message Header Analyzer and MXToolbox both accept pasted headers and render them as a readable table, which is the easiest way to interpret a long, compressed header block.
The Anatomy of an Email Header
Headers are read bottom to top when tracing a message's journey, because each server prepends its own record to the front of the growing block. The oldest entries are at the bottom and reflect what the original sender's system wrote; the newest entries are at the top and reflect what your mail server added just before delivery. This order is counterintuitive but important: a forged header inserted by an attacker will appear above the legitimate entries added by your provider's servers, which is one of the ways you can detect manipulation.
The From field is what you see in your inbox — the human-readable sender name and address. This is the easiest field to forge, and it is the one phishing emails routinely falsify. Seeing "support@yourbank.com" in the From field proves nothing without checking the authentication results below it. The Return-Path or Envelope-From is where bounced messages go, and it is harder to fake without breaking delivery. If the domain in Return-Path does not match the domain in From, that is a significant warning sign. The Reply-To field is another common manipulation point: marketers and attackers alike set it to a different address than From, so that your reply goes somewhere other than where the message appeared to originate.
The Received fields are the travel log, one entry per server hop. Each one records the IP address of the server that handed off the message, the server that received it, and a timestamp. Reading them from bottom to top reconstructs the route: server A accepted the message from the sender, handed it to server B, which delivered it to your provider's inbound gateway. Comparing the IP addresses in the lowest Received field against the sending domain's published records is how you check whether the email actually originated where it claims to. Tools like MXToolbox's Blacklist Checker let you look up whether any of those IPs are on known spam or abuse lists.
Authentication Headers: SPF, DKIM, and DMARC
The three most important lines in a modern email header are the authentication results, and they appear in a field called Authentication-Results added by your receiving mail server. They summarise the outcome of three separate checks your provider ran before accepting the message.
SPF (Sender Policy Framework) checks whether the IP address that delivered the message is authorised to send mail for the From domain. The sending domain publishes a DNS record listing its approved outgoing servers, and your provider checks the delivering IP against that list. A result of spf=pass means the email came from an authorised server; spf=fail or spf=softfail means it did not, which is strong evidence of spoofing or misconfiguration. We explain the full mechanics in why the From address can lie.
DKIM (DomainKeys Identified Mail) checks a cryptographic signature that the sending mail server attached to the message. The signature covers the message body and selected headers, and it is verified against a public key the domain publishes in DNS. A dkim=pass result means the message body has not been altered since the authorised server signed it and that the signing domain matches the From domain. A dkim=fail means the signature did not verify, which could indicate tampering or a misconfigured sender.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer on top of SPF and DKIM. It asks "does at least one of SPF or DKIM pass, and does the result align with the From domain?" A dmarc=pass is the strongest positive signal that a message really originated where it claims. When DMARC fails, the sending domain's published policy tells receiving servers whether to quarantine or reject the message, which is why legitimate organisations that properly configure DMARC make spoofing their domain much harder for attackers.
Message-ID, Date, and Thread Headers
The Message-ID is a unique identifier assigned by the originating mail server, formatted as a string like <unique-string@sending-domain.com>. The domain in the Message-ID should match the domain in the From field; if it references a completely unrelated domain, that is a suspicious mismatch. The Date field records when the message was composed, as reported by the sender's system, and comparing it against the timestamps in the Received fields shows whether the claimed composition time is consistent with the delivery timeline. A message claiming to have been sent yesterday but whose earliest Received timestamp is from today has an inconsistency worth noting.
Threading headers like In-Reply-To and References link replies to their parent messages using Message-IDs, which is how your mail client groups a conversation into a thread. These matter less for security analysis but are useful when you are tracing a long email chain and need to establish which message came first.
X-Headers and Custom Fields
Any field whose name starts with X- is a non-standard extension added by a particular mail system. Common examples include X-Mailer (the software the sender used to compose the message), X-Spam-Score (a numeric result from a spam filter), X-Google-DKIM-Signature (an additional signature added by Gmail), and X-Originating-IP (the IP of the client that submitted the message to the sending server). These fields are informational and their presence or content can help identify the sending software or provide additional context, but they can also be freely inserted by anyone, so they carry less authority than the formally structured authentication fields.
Bulk senders and marketing platforms often add X-headers that identify their platform (X-Mailer: Mailchimp, X-Campaign-ID, etc.), which is useful when you are trying to determine what service actually sent a message on behalf of a company. Some of these headers are what mail clients use to populate the one-click List-Unsubscribe button you see in Gmail and Apple Mail for newsletter messages.
What to Look for When Something Feels Wrong
Applying this knowledge to a suspicious email comes down to a short checklist. First, check the Authentication-Results block: if SPF, DKIM, and DMARC all fail, the message did not pass any standard verification and should be treated with deep scepticism regardless of what the From field says. Second, compare the From domain with the Return-Path domain: a mismatch means replies and bounces go somewhere different from where the message claims to originate. Third, look at the bottom-most Received field, which records the very first server to handle the message; its IP should belong to the organisation the email claims to be from, and you can check this with a WHOIS or reverse-DNS lookup. Fourth, check the Message-ID domain against the From domain. None of these checks is individually decisive, but failures across multiple fields together paint a clear picture of spoofing. We tie this into the broader skill of identifying malicious messages in how phishing emails work.
For messages that seem legitimate but are landing in spam, headers show you which filter made the decision. The X-Spam-Score and associated reason fields will often name the rule that triggered — a suspicious URL pattern, a bad IP reputation, or an SPF failure — and that tells a sender exactly what to fix. Email deliverability troubleshooting almost always starts with reading the headers of a message that did not arrive where expected.
Headers and Temp Mail
If you receive a message in a temporary inbox, its headers look like any other email. The Received chain will show the message passing through your temp mail provider's servers, and the authentication results will reflect the sender's own configuration. One difference is that the message will have been routed through the temp mail service's mail infrastructure, so the final delivery hop in the Received chain will reference that service's servers rather than a personal mail provider. This is entirely normal and visible if someone inspects the headers on a reply, though for a one-way verification flow, there is nothing to inspect from the other side.
What headers cannot show is anything about the person reading the inbox, because header information only travels with the message, not with the recipient. Using a disposable address at a temp mail service means that the message carries your real provider's details only in the delivery chain visible to you, never in what the sender sees. That is one of the structural privacy properties of disposable email that email headers help illustrate.
The Short Version
Email headers are the complete travel log and authentication record of any message, hidden by default but always accessible in one or two clicks. They record every server hop (Received fields), who the message claims to be from and where replies should go (From, Return-Path, Reply-To), and the results of SPF, DKIM, and DMARC checks that tell you whether those claims were verified. Reading from bottom to top traces the real delivery path; checking the authentication block tells you whether the domain was validated; comparing From domain against Return-Path and Message-ID domains surfaces the mismatches that reveal spoofing. Legitimate messages from well-configured senders will show pass results for all three authentication checks and consistent domains across every field. Phishing and spoofed messages typically fail one or more checks and show domain mismatches, which is exactly what the headers are designed to expose.
Frequently Asked Questions
How do I view email headers in Gmail?
Open the message, click the three-dot menu in the top-right corner of the email body (not the page), and choose "Show original." A new tab opens with the raw message, including the full header block at the top. You can copy the entire header section and paste it into Google's Message Header Analyzer or MXToolbox for a formatted, annotated view that is much easier to read than the raw text.
What does SPF pass mean in an email header?
SPF pass means that the IP address which delivered the message is listed in the sending domain's published SPF record as an authorised outgoing server. It confirms that the message arrived from a server the domain owner has approved for sending mail. SPF pass alone is not a guarantee of legitimacy — an attacker can pass SPF from their own domain and still spoof the visible From address — but combined with DKIM pass and DMARC pass, it is strong evidence that the message is genuine.
Can email headers be faked?
The From, Reply-To, and any X-headers in the original message can be freely set by the sender to whatever they choose, which is how email spoofing works. However, the Received fields and Authentication-Results added by each server along the delivery chain are written by those servers and cannot be falsified without compromising the servers themselves. The authentication checks (SPF, DKIM, DMARC) are also verified against DNS records the domain owner publishes, so an attacker cannot fake a pass result for a domain they do not control. This is why the Authentication-Results field is more trustworthy than the From line alone.
What is the difference between From and Return-Path?
From is the address shown to you in your inbox, the display sender. Return-Path (also called Envelope-From or MAIL FROM in the SMTP transaction) is where the mail system sends delivery failures and bounces. Legitimate senders usually have these match or at least use the same domain. Mismatches — especially where Return-Path uses a completely unrelated domain — are a common indicator of spoofing or of a bulk sender routing bounces through a different system than the marketing address they display.
Why does the bottom Received field matter most?
The Received fields are prepended by each server as it handles the message, so the last one added (at the top) is what your mail provider wrote, and the first one added (at the bottom) is what the original or earliest server wrote. Reading from the bottom tells you where the message actually started its journey, which is the most meaningful check: the IP in that bottom Received entry is the server that first injected the message into the email system, and it should belong to the organisation the email claims to be from. If it belongs to an unrelated hosting provider or a known spam network, that is the key red flag.
Achyuth Kumar
Founder & editor, TempMailKit
Achyuth builds privacy tools and writes TempMailKit’s guides on email security, spam, and online privacy. Every article is checked against primary sources and our editorial policy before it is published. Questions or a correction? Get in touch.