An email header is the hidden technical data attached to every email, and it acts like a digital passport that shows where the email came from, the path it took, and whether it's authentic. It also includes the checks mail systems use to decide whether to trust a message, and over 90% spam reduction is tied to DMARC-based handling when authentication fails or passes correctly, according to the source cited below.
You're usually looking for this stuff when something feels off. Maybe you got an invoice from a supplier that uses the right logo but a strange tone. Maybe a password reset email arrived when you didn't ask for one. The header is where you stop guessing and start checking.
Email users typically only see the friendly parts of an email, like the sender name and subject line. That view is useful, but it's also easy to fake. The header shows the less glamorous details that matter more for security, such as the route the message took, the systems that handled it, and whether sender checks passed.
That matters for privacy too. If you care where your email metadata lives, header details can reveal server paths and jurisdictions in ways most generic guides ignore. In Canada, that becomes part security question, part data sovereignty question under PIPEDA.
Last updated: 6 July 2026
What Is an Email Header
An email header is a hidden block of code and metadata that travels with every email. It contains required fields like From, To, Date, and Subject, and it records the technical path a message took through the internet. Proton explains that each email includes a header block at the top that records timestamps from every Mail Transfer Agent, or MTA, that handled it, creating a complete audit trail of the message's journey in its guide to email headers.
That sounds technical, but the basic idea is simple. Think of the message body as the letter you wrote, and the header as the envelope plus every postmark stamped on it during delivery. The body tells you what the sender wants you to read. The header tells you whether the trip looks legitimate.
Why headers exist at all
Email wouldn't work without headers. Mail systems need routing information to know where to deliver a message, how to process it, and whether it matches basic trust rules. Without that information, you couldn't reliably tell who sent the message, when it was sent, or which systems touched it along the way.
Headers also help email providers separate real mail from junk. They include information that lets mailbox providers authenticate senders and decide whether a message belongs in your inbox or your spam folder. That's why people in deliverability, IT, and security spend so much time reading them.
Practical rule: If the visible sender name looks trustworthy but the message still feels wrong, the header is usually where the story changes.
What you can and can't see
In a normal inbox view, you only see a tiny slice of the header. You see the sender, recipient, date, and subject because those are the human-friendly fields. The rest is hidden because raw header text is dense and full of technical lines.
Once you open the full header, you'll see entries added by different mail servers over time. That trail can show the actual route of a message, which is useful for troubleshooting and for finding a fake sender. It can also expose where processing happened, which matters if your organization has residency requirements.
Here's a simple explanation:
| Part | What it means | Why it matters |
|---|---|---|
| Visible fields | From, To, Date, Subject | Basic context for the reader |
| Routing fields | Received, Return-Path, Message-ID | Shows where the email actually travelled |
| Authentication fields | SPF, DKIM, DMARC results | Helps confirm whether the sender is genuine |
When people ask what is an email header, they're often really asking a more useful question. Can this hidden data help me decide whether an email is real? The answer is yes. Not perfectly, and not always instantly, but often enough that it's one of the most practical anti-phishing habits you can build.
Key Fields in an Email Header Explained
Once you open a full header, it can look like a wall of machine text. Don't try to read every line at once. Start with a few fields that answer the most important questions: who claims to have sent the message, who handled it, and whether authentication checks passed.
The simple fields you already know
From is the address the sender wants you to see. It's the display identity, not always the true sending source. Attackers know recipients often trust this field too quickly.
To shows the intended recipient. If a message was sent to several people, the header can list multiple names and addresses. That can help you spot odd distribution patterns, especially when a message claims to be private but clearly wasn't.
Date records when the message was sent. Subject records the topic line. These sound ordinary, but they're still useful when you're checking whether a message matches the timing and context you'd expect.
The fields that tell the real delivery story
Return-Path is where delivery errors and bounce messages go. In a legitimate email, this often lines up with the sender's domain or an authorised sending service. If the From address says one thing and the Return-Path points somewhere unrelated, slow down.
Message-ID is a unique identifier for a specific email. You don't need to decode it in detail, but it can help show whether a message was generated by a real system or by a rough imitation. A strange-looking or generic ID doesn't prove fraud on its own, but it can add weight to other warning signs.
Received is one of the most useful fields in the whole header. Each mail server that handles the message adds a new Received line, usually with timing and server details. Read it as a chain of handoffs. It helps you trace where the message came from instead of trusting the polished display name in the inbox.
The visible sender can be staged. The Received chain is much harder to fake convincingly across every hop.
The authentication fields that matter most
The key line here is Authentication-Results. This field shows the output of SPF, DKIM, and DMARC checks. Mailtrap notes that a pass means the sender's IP is authorised by the domain, while a fail can trigger rejection or quarantine by email gateways, reducing spam delivery rates by over 90% under DMARC standards in its breakdown of email headers.
If those acronyms feel abstract, here's a plain-language version:
SPF checks whether the sending server is allowed to send on behalf of the domain.
DKIM adds a cryptographic signature to help prove the message wasn't changed in transit.
DMARC tells receiving systems what to do when SPF or DKIM doesn't align properly.
A useful analogy is physical ID. SPF is like checking whether the courier works for the company they claim to represent. DKIM is like a tamper seal on the package. DMARC is the company policy that tells the front desk whether to accept, quarantine, or reject the package if anything doesn't line up.
If you want a clearer mental model for signed messages and trust chains, our guide to digital signatures and PKI fills in the background without getting lost in jargon.
A quick field-by-field cheat sheet
| Header field | What to check | What it can tell you |
|---|---|---|
| From | Does the visible sender match what you expected? | Easy to fake, so treat it as a starting point |
| Return-Path | Does it broadly align with the sender's domain? | Mismatches can signal spoofing |
| Received | Does the route make sense? | Helps you find sender IP and trace origin |
| Message-ID | Does it look tied to a real sending system? | Odd patterns can support suspicion |
| Authentication-Results | Do SPF, DKIM, and DMARC pass? | One of the strongest trust signals in the header |
People often assume email header analysis is only for administrators. It isn't. If you can compare names, domains, and pass or fail results, you can catch a surprising number of scams before they catch you.
How to View Email Headers in Gmail and Outlook
Finding the raw header is easier than you might anticipate. You don't need a special admin panel or a developer tool. In most cases, it takes a few clicks.
Mailjet's instructions are clear on the basic steps. In Gmail, click the three-dot menu beside the reply button and choose Show Original. In Outlook on the web, click the three dots in the upper right and select view message source, as described in Mailjet's email header guide.
Gmail
Open the email first. Then click the three-dot menu near the reply button, not the browser menu, and choose Show Original. Gmail opens a new view that shows the full technical log, including routing and authentication details.
That screen can look intimidating at first. Don't read from top to bottom like a normal message. Scan for the fields covered above, especially From, Return-Path, Received, and Authentication-Results.
Outlook
In Outlook on the web, open the email, click the three dots in the upper right, and select view message source. If you use the Outlook desktop app, the process is a bit clunkier. You open the message in its own window, right-click file, choose properties, and then look for internet headers near the bottom.
One useful habit: when a message feels suspicious, save the full header before you delete anything. It's much easier to review or share later.
What you're looking at
The first time you view headers, it may feel like someone dumped a printer log into your inbox. That's normal. You don't need to understand every field to get value from it.
Start with three checks:
Visible identity. Does the From address match what you expected?
Delivery path. Do the Received lines look consistent with the claimed sender?
Trust checks. Does Authentication-Results show pass or fail for SPF, DKIM, and DMARC?
If you only do those three things, you're already reading headers more effectively than most users.
How to Spot a Spoofed Sender
A spoofed email is a message that pretends to come from someone trusted. The sender name looks familiar, the branding may look right, and the wording might be close enough to trigger a rushed click. Header analysis helps you look past the costume.
A common situation goes like this. You receive an invoice from a supplier you recognise. The display name matches the company, and the message asks you to open an attachment before end of day. If you only judge the message by the visible sender line, you might miss the trap.
Compare what the email says with what the header shows
Start with From and Return-Path. If the email claims to be from your supplier but the Return-Path points to a different domain or a sending pattern that makes no business sense, that's a strong warning sign.
Then check the Received chain. You're looking for whether the delivery path fits the story. If the sender claims to be a normal billing address but the route suggests an unexpected origin or a path that doesn't fit prior legitimate messages, don't trust the invoice.
After that, look at Authentication-Results. A fail doesn't always mean a message is malicious, but it does mean the message failed an important trust check. If it also has a mismatched Return-Path or an odd Received chain, the risk goes up quickly.
Why this matters now
This isn't just a niche problem. According to the 2025 Canadian Anti-Fraud Centre report, 57% of verified email fraud cases in Canada involved forged authentication headers, and 31% of victims were small businesses using ad-free email services, as cited in Campaign Monitor's email header explainer.
That number matters because many tutorials stop at “check the sender address.” That isn't enough anymore. Modern phishing attempts often mimic the visible parts well and hide the inconsistencies in technical fields that most users never open.
If you want to understand one of the core policies behind those pass or fail results, our article on DMARC and simpler email security is a good follow-up.
A short walkthrough helps:
The display name looks right. You receive “Accounts Payable” from a known company.
The urgency feels engineered. The message pushes you to act fast, often before you verify.
The header tells a different story. Return-Path doesn't line up, Received looks off, or Authentication-Results fails.
Here's a practical checklist you can use when you need to detect spoofed email fast:
| Check | What to compare | Red flag |
|---|---|---|
| From vs Return-Path | Visible sender and bounce path | Different or unrelated domains |
| Received chain | Claimed source and actual route | Delivery path doesn't fit sender story |
| Authentication-Results | SPF, DKIM, DMARC | One or more failures |
| Message-ID | Format and consistency | Looks generic or unusually odd |
Before you look at the example video below, keep one point in mind. A single strange field doesn't always prove fraud. Several small inconsistencies together usually matter more than one dramatic clue.
If the email pressures you to act now, header mismatches deserve extra weight. Attackers rely on speed and distraction.
Tools to Analyse Headers
Raw headers are useful, but they're not pleasant to read. Long chains of fields, odd spacing, and technical labels can make even a simple message look suspicious. That's why header analysis tools are worth using.
A good parser takes the raw header text and turns it into something readable. Instead of hunting through a text wall, you get a cleaner view of routing hops, authentication results, and possible issues. That makes it easier to find sender IP clues, spot alignment problems, and understand whether a message was authenticated.
When a tool helps most
Manual reading is still valuable when you know exactly which fields to check. A tool helps when you need speed, when you're sharing findings with someone less technical, or when the header is especially messy.
Popular options include tools from MXToolbox and Google Admin Toolbox Messageheader. We're mentioning them as examples because they make the same basic job easier. Paste in the header, review the parsed output, and then compare the cleaned-up report with what the message claimed on its face.
Here's the practical benefit:
Clearer routing view so the Received chain is easier to follow
Pass or fail summaries for authentication checks
Faster triage when you need to decide whether to trust a message
Better communication when you need to show a colleague why an email looks wrong
Best use case: use a parser for speed, then sanity-check the raw header if something important looks off.
Tools don't replace judgement. They make good judgement easier to apply.
How We Protect Your Privacy in Email Headers
Headers don't just reveal delivery details. They can also reveal metadata about where a message was processed and which systems handled it. For privacy-conscious users and organizations, that matters because metadata can cross borders even when the message content is encrypted.
That's one reason data residency comes up in header discussions more often now. Many Canadian organizations remain uncertain about whether email header metadata stored on US servers violates PIPEDA data sovereignty requirements. If you're responsible for business email, that uncertainty isn't abstract. It affects procurement, compliance reviews, and incident response.
The privacy side of header analysis
A lot of US-centric guides treat headers only as a deliverability or anti-phishing tool. That misses part of the story. Header paths can expose where processing happened, which may raise legal and operational questions when your organization wants mail and metadata kept under Canadian jurisdiction. That's also why people compare PIPEDA with foreign access regimes such as the US CLOUD Act. The message body gets most of the attention, but metadata matters too. When you review headers, you're not only checking authenticity. You're also seeing where control may leave your preferred jurisdiction.
Typewire was built around this exact concern. We operate our own infrastructure in Vancouver, Canada, so email and header metadata stay under Canadian jurisdiction rather than moving through third-party cloud platforms. That way, the full audit trail—including routing details, timestamps, and authentication records—remains under Canadian control.
We also block spy pixels, which helps reduce another common source of quiet metadata leakage. That doesn't make email magically private in every sense, and we won't pretend otherwise. Email always involves trade-offs between openness, compatibility, and control.
What we can do is keep those trade-offs honest, visible, and aligned with privacy-first email hosting.
If you want an email service that keeps header metadata and message content in Canada under Canadian privacy law, explore Typewire. We host everything in Canada, focus entirely on email, and give individuals and small businesses a simpler way to send and receive mail without data mining or ecosystem bloat.
