Reading Microsoft 365 and Google Workspace Email Headers Like a Pro
Read M365 and Google Workspace email headers without flinching. Six lines triage 90% of mail-flow questions, with worked phishing and false-positive cases.
TL;DR
Email headers look intimidating because one message carries two hundred lines of routing metadata. Six of them triage 90% of mail-flow questions: was it really from who it claims, did SPF and DKIM pass, did DMARC align, where did it come from, is it being filtered. What each one means on M365 and Google Workspace is below, with worked cases.
How to grab the full headers
Outlook desktop. Open the message in its own window. File → Properties. The “Internet headers” box is at the bottom. Copy everything.
Outlook on the web (OWA). Open the message. Three-dot menu → View → View message details. Headers paste into a modal.
Gmail and Google Workspace. Open the message. Three-dot menu in the top-right → Show original. Gmail opens a new tab with the full source plus a tidy summary at the top showing SPF, DKIM, and DMARC verdicts already parsed.
Apple Mail. View → Message → All Headers (Cmd+Shift+H), then View → Message → Raw Source for the full thing.
Mobile. Don’t. Forward the suspect message as an attachment to yourself and open it on desktop.
The six headers worth reading first
1. Authentication-Results: (the verdict line)
The receiving server’s parsed verdict on the message. Almost always near the top of the block. On M365 and Google Workspace it looks like:
Authentication-Results: mx.google.com;
dkim=pass header.i=@example.co.za header.s=google header.b=AbC123;
spf=pass smtp.mailfrom=bounces@example.co.za;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.co.za
The three verdicts: spf=, dkim=, and dmarc=. You want three passes. The alignment check is the part most people miss: SPF and DKIM can both pass on a different domain to the one in From: and DMARC still fails. That’s the whole point. When DMARC fails, the receiver applies your policy: dmarc=fail action=quarantine or dmarc=fail action=reject.
2. Received: chain (the route, read bottom-up)
Received: headers stack. Each hop prepends a new line. The bottom entry is where the message originated; the top is the final hop into your inbox.
A clean M365-to-M365 message has three or four Received: lines. More than six and you’re looking at a forwarded or relayed message.
Read bottom-up. A header opening with:
Received: from random-vps-7421.cheaphost.ru ([185.220.101.45])
by mx.google.com with ESMTPS id ...
…with a From: claiming paul@osh.co.za is a problem. The originating IP is in Russia, the helo is a generic VPS, and OSH doesn’t send from cheaphost.ru. SPF will already have failed; the chain just confirms the geography.
3. From: and Return-Path: (alignment by eye)
The From: header is what your mail client renders. The Return-Path: is the envelope sender, the address bounces go to. Legitimate bulk senders routinely use a vendor envelope domain while the visible From: is the customer’s. Normal. DMARC handles the alignment question for you, but eyeballing both is a fast sanity check.
Pattern to flag: From: paul@osh.co.za with Return-Path: <random-string@gmail.com> and no SPF or DKIM relationship between the two.
4. Received-SPF: (the SPF result with reason)
Essentially a duplicate of the spf= line in Authentication-Results:, but with a plain-English explanation:
Received-SPF: Pass (protection.outlook.com: domain of example.co.za designates 40.107.220.45 as permitted sender)
When this says Fail, the parenthesised reason tells you why. The most useful: permerror means the SPF record itself is broken (10-lookup limit hit, syntax error). That’s a sender-side DNS problem, not a phish.
5. DKIM-Signature: (selector, domain, algorithm)
Five tags worth knowing:
a=rsa-sha256: algorithm.rsa-sha1is deprecated; if you see it, the sender should rotate.d=example.co.za: the signing domain, the alignment domain. Compare to theFrom:header.s=selector1: the selector. The DNS lookup isselector1._domainkey.example.co.za. M365 usesselector1andselector2. Google Workspace defaults togoogle.bh=...andb=...: body hash and signature. The receiver checks these; you don’t.
Read d= and s= at speed. If d= doesn’t match the From: domain, DKIM won’t align.
6. Vendor extras: M365 and Google Workspace stamps
M365:
X-Forefront-Antispam-Report:is the spam-filter verdict. TheCAT:tag names the category (NONE,SPM,HSPM,PHSH,MALW).SCL:is the Spam Confidence Level (-1 to 9).SCL:5or above was treated as spam.X-Microsoft-Antispam-Mailbox-Delivery:shows where the message ended up (dest:Iinbox,dest:Jjunk,dest:Qquarantine).
Google Workspace:
ARC-Authentication-Results:andARC-Seal:are the Authenticated Received Chain headers. Gmail signs the authentication results so downstream mailing lists and forwarders can preserve the original verdict even when SPF and DKIM would otherwise break in transit.
What a phishing email’s header trail looks like
A user forwards you a message claiming to be from the CFO asking for a wire transfer.
From: says "Cathleen Ogier" <cathleen@osh.co.za>. Return-Path: says <accounts4847@protonmail.com>. The envelope sender has nothing to do with osh.co.za. First red flag.
Authentication-Results: reads spf=fail smtp.mailfrom=accounts4847@protonmail.com; dkim=none; dmarc=fail action=quarantine header.from=osh.co.za. SPF fails. DKIM is none. DMARC fails.
Received: chain, read bottom-up, opens at a residential ISP block in eastern Europe. Two hops, neither of them protection.outlook.com or Google’s outbound ranges.
X-Forefront-Antispam-Report: stamps CAT:PHSH and SCL:9. M365 has already made the judgement.
SPF fail, DKIM none, misaligned envelope sender, short Received chain that doesn’t include the claimed-sender’s platform, spam category already saying PHSH. That’s the whole picture.
What a legitimate-but-broken email looks like
The Mailchimp send that fails alignment. Marketing sends a campaign via Mailchimp. The message arrives with dkim=pass header.d=mcsv.net and spf=pass smtp.mailfrom=bounce-mc.us10.mcsv.net. Both pass. DMARC fails: dmarc=fail action=quarantine header.from=example.co.za. Neither aligns with example.co.za. SPF authenticated mcsv.net. DKIM signed for mcsv.net. DMARC needs at least one aligned with the visible-from domain, and neither is. The fix: enable Mailchimp’s custom DKIM signing on the customer domain.
The Sage send that fails after a forwarder is added. Finance sends Sage invoices. Authentication is fine direct. Then the customer adds an inbound forwarder in front of M365. The forwarder’s IP isn’t in the original SPF record, so SPF fails on the second hop. If the forwarder leaves the body untouched, DKIM survives and DMARC passes on the DKIM leg. If the forwarder rewrites headers (an “[external]” subject prefix, a tracking pixel), DKIM fails too, and DMARC fails. Fix: SRS on the forwarder, ARC participation, or removing the forwarder from the path.
Legitimate message, authentication failed for a structural reason. The headers tell you which leg broke. The fix is on the sender or the forwarder, not you.
When to reach for a header analysis tool
Every time you’d otherwise paste a 200-line block into a text file and squint. The TamingDNS Email Header Analyser parses the raw block and returns the Authentication-Results: verdict, a geo-located timeline of the Received: chain, flagged anomalies, and the M365/Google spam-filter verdicts decoded into plain English. Free, no login. Paste in, read out.
Where this fits
Microsoft 365 covers Defender for Office 365 anti-phishing posture. The DMARC service page covers SPF, DKIM, and DMARC at the DNS layer. Google Workspace covers the GW equivalents. For the foundational DMARC read, see The Bouncer’s Guide to DMARC.
Forensic email triage from OSH
If you have a message you can’t decide on, paste the headers to us. We’ll read them and tell you what the chain actually says: block the sender, fix the alignment gap and allow it, raise an incident, or escalate to the platform vendor.
Email support@osh.co.za with the headers in the body. Same business-day reply. No tooling to install.
