Naimh is a seasoned marketer of 12 years, including in SaaS and tech. She’s an expert at simplifying complex technology concepts, bridging the gap between IT and marketing. Naimh specializes in turning tech speak into actionable insights, helping marketers get the most out of their tools and technology.
How to view email headers in Outlook: A complete guide
TL;DR
In New Outlook and Outlook on the web, open the message, select More actions (the ... menu), then View > View message details.
In classic Outlook for Windows, open the message in its own window, go to File > Properties, and read the Internet headers box.
In Outlook for Mac, open the message, then go to View > Message Source.
On Outlook mobile, open the message in a browser instead. The mobile apps don't expose a raw header view.
Once you have the headers, check Authentication-Results first (SPF, DKIM, DMARC) and the last Received line to see where the message actually came from.
Have you ever received a suspicious email in Outlook and questioned its legitimacy? Maybe the sender's name looked right, but something about the message felt off. The answer to "is this real" lives in the email header: the block of technical metadata Outlook hides by default.
This guide covers how to view email headers across New Outlook, classic Outlook for Windows, Outlook for Mac, and Outlook on the web, how to read what you're looking at, and where headers stop being useful, since checking a header isn't the same as stopping a phishing attempt.
If you're managing email across Microsoft 365, Exclaimer's cloud solution for Microsoft 365 brings that same consistency and control to the mail your organization sends out.
What are email headers, and why check them?
Email headers, also called internet headers or message headers, are metadata attached to every email as it moves from sender to recipient. They record the sender, recipient, subject, and every server the message passed through. This is information that the visible message body never shows you.
People go looking for headers for one of three reasons:
To verify authenticity. Headers reveal whether a message actually came from the domain it claims, or whether the sender address has been spoofed.
To trace the route. The Received lines show every server the message passed through on its way to your inbox, in reverse order.
To troubleshoot delivery problems. If mail isn't arriving the way you expect, the headers usually show where it stalled or diverted.
How to view email headers in Outlook
Microsoft now runs two distinct interfaces side by side: New Outlook and classic Outlook for Windows. The menu path for viewing headers depends on which one you're using, so check that first if the steps below don't match what you see on screen.
New Outlook and Outlook on the web
Open the email you want to inspect.
Select the ellipsis (...) or More actions button in the reading pane.
Choose View > View message details.
Copy the header text from the panel that appears, and paste it into a text file if you need to save or share it.
This matches Microsoft's own current guidance for New Outlook, which was last updated in June 2026.
Classic Outlook for Windows
Double-click the email to open it in its own window, rather than reading it in the preview pane.
Go to File > Properties.
Look for the Internet headers box at the bottom of the dialog.
Select the text, copy it, and paste it into Notepad or Word if you need a saved copy.
Outlook for Mac
Open Outlook for Mac and select the email.
Go to View > Message > View Source (or hold Ctrl and click the message, then choose View Source from the context menu).
The raw source, headers included, opens in a new window.
Copy the section you need before closing it.
Outlook mobile
Outlook's mobile apps don't currently expose a raw header view. If you need to check headers from your phone, open the message in a mobile browser instead and follow the New Outlook / Outlook on the web steps above. It's a genuine gap in the mobile app rather than being a setting you've missed.
How to interpret email headers
Headers can run to dozens of lines, most of which you'll never need. A handful of fields do almost all the useful work.
Standard elements
Here's what each field in the visible part of the header records:
Field | What it means |
|---|---|
From | The sender's name and address, as claimed. This is the field spoofing attacks target. |
To | The recipient's address. |
Date | When the message was sent. |
Subject | The subject line. |
Reply-To | The address a reply actually goes to, which can differ from From. |
Routing and authentication elements
Field | What it means |
|---|---|
Received | One line per server the message passed through, oldest at the bottom and most recent at the top. Read from the bottom up to trace the message's actual path. |
Return-Path | Where bounce notifications and delivery failures get sent. |
Message-ID | A unique identifier for this exact message, generated by the sending server. |
Authentication-Results | The field that matters most for spotting a fake. Reports the outcome of three email authentication checks: SPF, DKIM, and DMARC. |
Authentication-Results is worth its own breakdown, since it's the field carrying the most useful signal:
Check | What it confirms |
|---|---|
| SPF (Sender Policy Framework) | The sending server is authorized to send mail for that domain. |
| DKIM (DomainKeys Identified Mail) | A cryptographic signature confirms the message wasn't altered in transit. |
DMARC (Domain-based Message Authentication, Reporting, and Conformance) | The policy that tells receiving servers what to do when SPF or DKIM fails: quarantine, reject, or let it through. |
A message that fails all three isn't automatically fake, and a message that passes all three isn't automatically safe. Authentication proves the sending server was authorized to send as that domain. It doesn't check the content, the intent, or the request inside the message.
What headers can't tell you
Checking a header answers a narrower question than most people expect. It tells you whether a message's technical origin matches its claimed sender. It doesn't tell you whether the request inside the message is legitimate.
A compromised but properly authenticated account can send a message that passes SPF, DKIM, and DMARC cleanly, because it really was sent from the domain it claims. And a well-crafted lookalike domain can be registered, authenticated correctly, and still be run by an attacker.
Key takeaway
Header checking is a diagnostic step, not a prevention tool. A clean authentication result narrows down who sent a message. It doesn't confirm the message itself deserves your trust.
It's most useful alongside the broader basics of email security: checking whether the request itself is unusual (an urgent payment, a password reset you didn't request, a link that doesn't match the text), and verifying through a second channel before acting on anything that feels off.
How do you read an email header quickly?
Start with Authentication-Results, not the top of the header block. It gives you the fastest signal.
Read the last Received line, since that's the server closest to the true origin.
Compare the From address to the Reply-To address. A mismatch is a common spoofing tell.
Don't assume a pass on SPF and DKIM ends the question. Check whether the request itself makes sense before acting on it.
Is your organization's own email properly authenticated?
Checking a header this way answers a question about one message someone sent to you. Most IT teams have already automated the equivalent check on mail coming in: SPF, DKIM, and DMARC records, spam filtering, and mail flow rules that quarantine what fails.
The harder version of the question runs the other way: is everything your organization sends out authenticated properly in the first place? According to Exclaimer's State of Business Email 2025 research, surveying 4,009 IT professionals across the UK, US, Germany, and Australia, fewer than one in three organizations have actually implemented DMARC, DKIM, or SPF. Most IT teams are checking these fields on inbound mail without having fully locked them down on outbound mail.
"Email has something most channels don't: authentication standards. DMARC, DKIM, SPF. Imperfect, but they exist. That trust depends on organizations actually implementing these standards properly. The gap between companies with enforced DMARC and those without will widen. The latter become prime targets for impersonation."
That gap is a DNS and infrastructure problem. No email signature tool closes it, since getting DMARC to enforcement is down to whoever manages your domain.
What a centrally managed email signature covers is a different problem: making sure every message that goes out under your organization's name looks like it, consistently, for every employee, not just the ones who set one up themselves.
So, is that email actually trustworthy?
Viewing an email's headers in Outlook, whichever version you're running, answers a narrower question than this. It's actually all about whether the message's technical origin matches what it claims. That's still genuinely useful as it's the fastest way to catch a spoofed sender, trace a delivery problem, or back up a judgment call you were already leaning toward.
The bigger version of that question, whether everything your own organization sends meets the same bar, doesn't get answered by checking headers one email at a time. It's worth building into your organization's approach to email compliance directly, before someone outside your organization has reason to ask it for you.
Try Exclaimer for free
You didn't come here shopping for email signature software. But the same authenticity question you just spent this guide answering for one message is worth asking about everything your organization sends, and that's what Exclaimer actually handles: every employee's email signature and disclaimer, kept consistent, correctly formatted, and centrally managed across Microsoft 365, Google Workspace, and Exchange, without IT chasing it down one mailbox at a time.
