Email Headers: How to Read Them in Gmail and Outlook

Email headers are the lines at the top of every email that record who sent it, which servers passed it on and what your provider's checks found. Gmail shows them under Show original, Outlook under View message details.

Three parts answer most questions. Authentication-Results says whether the sending domain really sent the email, and the Received lines show where it waited. From, Reply-To and Return-Path show where replies and bounces go.

A fake refund email can put a supplier's address in From. It cannot change the verdict your provider writes after checking that domain.

How to open email headers in Gmail and Outlook

Open the email as it arrived, not your Sent copy, and use the menu in the table below. If you sent the email, ask the recipient for the full email header, because only their copy has the lines added on delivery.

Mail app	Where to click	What you get
Gmail in a browser	More, next to Reply, then Show original	A new window with a short summary and the full header; Copy to clipboard copies it
New Outlook, Outlook on the web and Outlook.com	More actions, then View, then View message details	The full header in a window
Classic Outlook for Windows	Double-click the email to open it, then File, then Properties	The header in the Internet headers box
Apple Mail on a Mac	View, then Message, then All Headers	Every header line above the message

Gmail has a quicker check too. Click the down arrow under the sender's name: Mailed by shows the envelope (Return-Path) domain, and Signed by the domain that signed the email. A question mark beside the name means Gmail could not authenticate the email.

What an email header looks like

An email header is a list of fields, one to a line: a name, a colon and a value. Request for Comments (RFC) 5322, the standard for email messages, defines the format (RFC 5322).

Newsletter designers also call an email's top banner its header. Here the word means the technical lines.

Below is a shortened email header from a dispatch email that an online tile shop sent through an email platform. We made it up: example.co.uk stands in for the shop's domain, and the other names and IP (Internet Protocol) addresses are reserved for documentation (RFC 2606, RFC 5737).

Delivered-To: [email protected]
Received: by mail.example.net with SMTP id t7ksd2;
        Mon, 19 Oct 2026 01:58:07 -0700
Return-Path: <[email protected]>
Received: from out4.platform.example (out4.platform.example [203.0.113.24])
        by mx.example.net with ESMTPS id 9a2e5c;
        Mon, 19 Oct 2026 01:58:06 -0700
Authentication-Results: mx.example.net;
       dkim=pass header.d=example.co.uk header.s=s1;
       spf=pass smtp.mailfrom=bounce.example.co.uk;
       dmarc=pass header.from=example.co.uk
DKIM-Signature: v=1; a=rsa-sha256; d=example.co.uk; s=s1; [signature cut]
From: Tile Shop <[email protected]>
Reply-To: [email protected]
To: [email protected]
Subject: Your order has been dispatched
Date: Mon, 19 Oct 2026 09:58:02 +0100
Message-ID: <[email protected]>

Read it in two halves. The lines from DKIM-Signature down left the sender's side with the email. Each server on the way stacked its own lines above, newest first.

Field	Written by	What it tells you
From	The sender	The name and address shown in your inbox; anyone can type them
Reply-To	The sender	Where your reply goes, if not to From
Date	The sender's mail app	When they pressed send, by their own clock
Message-ID	The sender's mail system	A unique ID; the part after the @ usually names the system that made it
DKIM-Signature	The sending server	The domain that signed the email, in d=
Return-Path	The server that delivered it	The envelope address that bounce reports go to
Received	Each server on the way	Which server handed the email to which, and when
Authentication-Results	The server that checked it	The result of each check it ran

Here the Return-Path uses a bounce subdomain of the retailer's own domain. Email platforms do that on purpose, so every mailer daemon report lands with software that processes it.

Which email header lines you can trust

Trust the lines your mailbox provider added, and treat everything below them as the sender's account. Their software writes From, Reply-To, Date and Message-ID, and it can slip fake Received lines in before the email leaves.

Servers only add Received lines on top (RFC 5321, section 4.4). So the lowest line whose by names your provider's server marks where your provider took the email.

The machine named after from in that line handed it over, and that handover is the hardest part of the route to fake. In the dispatch email, mx.example.net wrote that line. The handover came from out4.platform.example at 203.0.113.24, the address the receiving SMTP server saw on the connection.

Authentication-Results works the same way. Its first word names the service that ran the checks. Providers must delete any copy that claims their name but arrived from outside (RFC 8601, section 5), so read the copy headed by your own provider.

How to read Authentication-Results

Authentication-Results lists each check as method=result, followed by the domain that was checked. The usual three are SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting and Conformance).

For the tile shop, all three passed, each for a domain the shop owns.

Result	Domain it names	Where that domain comes from	Record that was looked up
spf=	smtp.mailfrom	The Return-Path, also called the envelope sender	The TXT (text) record starting v=spf1 on that domain
dkim=	header.d	The d= tag in DKIM-Signature	The public key under _domainkey on that domain
dmarc=	header.from	The domain in From	The TXT record at _dmarc on that domain

Microsoft's page on anti-spam message headers, last updated 27 July 2026, gives the same three definitions.

All three records live in DNS (Domain Name System), the internet's public directory for domains. When your own domain fails one, the fix is a DNS change: set up SPF, DKIM and DMARC in that order.

DMARC passes when the From domain matches a domain that passed SPF or DKIM. Under the default relaxed rule, a subdomain such as bounce.example.co.uk matches its parent. What a receiver does with a failure depends on the domain owner's DMARC policy.

Our own SPF record shows what an spf= result is measured against. This is the TXT lookup for mailgraf.com at 02:16 UTC (Coordinated Universal Time) on 25 October 2026, with an IP address and our office mailbox provider shortened:

$ dig +short TXT mailgraf.com
"v=spf1 ip4:… include:… ~all"
[3 site verification records cut]

Our SPF record ends in ~all. An unlisted server therefore gets spf=softfail, which RFC 7208 defines as a weak statement that the server is probably not authorised (RFC 7208, section 2.6). With -all, the same email would get spf=fail.

The remaining results mean this for SPF and DKIM (RFC 8601, section 2.7):

• none: nothing to check, such as no SPF record or no signature. In dmarc=none, the From domain has no DMARC record (RFC 9989, section 9.2).
• neutral: the SPF record makes no claim about the server, or a DKIM signature could not be processed.
• temperror and permerror: a lookup failed for now, or the published record is broken.

Forwarded mail often fails SPF, because the forwarding server is missing from the original domain's record. Google notes that genuine mail sent to mailing lists sometimes fails authentication too (Gmail Help). A DKIM signature travels with the email, so it can still pass where SPF fails.

How to spot a fake email in its header

A forged email usually shows dmarc=fail for the domain in From, or uses a From domain that only looks like the real one. Here is a forgery of the tile shop's email, again made up and shortened:

Authentication-Results: mx.example.net;
       dkim=none;
       spf=pass smtp.mailfrom=mailer.example;
       dmarc=fail header.from=example.co.uk
From: Tile Shop <[email protected]>
Reply-To: [email protected]
Subject: Your refund is ready

SPF passed, but for mailer.example, which has no link to the shop. Nothing that passed matches From, so DMARC failed, and replies would go to a third domain.

What you see	How much it tells you
dmarc=fail with header.from set to the brand's domain	A lot: the brand's domain did not send it, unless a forward broke the checks
A From domain one character off, such as examp1e.co.uk, with every check passing	A lot: the checks passed for the lookalike, not the brand
Reply-To on another domain, next to a request for money or bank details	A lot, taken together with the request
A pass for a domain unrelated to the brand, as above	Enough to doubt it, because only DMARC ties a pass to From
Return-Path on another domain	Little on its own: the standard allows a separate address for error reports (RFC 5321, section 4.4), and email platforms use one
A Message-ID from an unrelated system	Little on its own

Gmail flags some lookalikes, such as an address with a zero in place of the letter O (Gmail Help). Before paying anything, call the sender on a number you already have.

In the UK, forward suspicious emails to [email protected], run by the National Cyber Security Centre (NCSC). It says it acts on every report, though it cannot share the outcome (NCSC).

Why an email went to spam

The header shows which authentication checks failed, and Microsoft 365 writes its spam verdict there too. Gmail explains its reason in a warning shown on each email in Spam instead (Gmail Help).

A Microsoft 365 business mailbox records the filter's decision in a few fields, described on Microsoft Learn:

Field	What it means	What to do
SFV:SPM, in X-Forefront-Antispam-Report	The spam filter marked the email as spam	Read the CAT value to see which protection acted
CAT (category), such as PHSH (phishing) or SPOOF (spoofing)	The protection that acted on the email	Treat PHSH and SPOOF as a warning about the sender
SCL (spam confidence level), in the same line	A score that Microsoft says does not decide what happens in cloud mailboxes	Rely on CAT instead
BCL (bulk complaint level), in X-Microsoft-Antispam	How likely a bulk email is to draw complaints; higher is worse	If it is your newsletter, check how you collect and remove addresses
compauth=fail reason=001, in Authentication-Results	Microsoft's combined check of SPF, DKIM, DMARC and other signals failed, and the From domain publishes weak rules or none, such as ~all or p=none	On your own domain, make SPF or DKIM pass for the From address

If every check passes and the email still lands in spam, the cause sits outside the email header. Look at how mailbox providers rate the sender and at the content and list habits that trip spam filters.

How to find where an email was delayed

Convert every time to UTC, then find the biggest gap between the Date line, the Received lines and the moment you saw the email. Servers usually write local time with an offset from UTC, such as +0100 for British Summer Time, as the SMTP standard asks.

Back in the dispatch email, Date says 09:58:02 +0100 and the provider says 01:58:06 -0700. They look eight hours apart, yet in UTC they are 08:58:02 and 08:58:06: four seconds.

These lines come from a slow reply sent from the shop's office, shortened, with Date moved next to them:

Received: from mail.example.co.uk (mail.example.co.uk [198.51.100.9])
        by mx.example.net with ESMTPS id 51bd0e;
        Thu, 22 Oct 2026 09:47:31 -0700
Received: from [192.168.0.14] (host7.broadband.example [192.0.2.71])
        by mail.example.co.uk with ESMTPSA id 2c90aa;
        Thu, 22 Oct 2026 14:03:12 +0100
Date: Thu, 22 Oct 2026 14:02:58 +0100

In UTC, the reply was finished at 13:02:58 and reached mail.example.co.uk at 13:03:12. It arrived at the recipient's provider at 16:47:31, so it sat on that server for 3 hours 44 minutes. The shop's mail host is the one to ask.

Where the gap is	What it usually means	Who can look into it
Between Date and the lowest Received line	The email waited before it left: in an Outbox or on a laptop that was offline	The sender
Between two Received lines	The server named after by in the lower line held it, for example while retrying after a temporary refusal	Whoever runs that server
Between the top Received line and when you saw it	Your provider delivered it on time, and your mail app showed it late	You, in your app or phone settings

The first row follows RFC 5322: Date records when the author finished the email, not when it travelled (section 3.6.1). In Show original, Gmail puts the delivery time next to Created at (Gmail Help).

For a long header, Google's Messageheader tool points out delivery delays and their likely source. Microsoft's Message Header Analyzer lays the same lines out as a readable table. Either takes the email header you copied in the first step.

What a MailGraf email shows in its header

A campaign sent through MailGraf from your own domain or subdomain carries a DKIM signature for that domain. The records listed on the Senders page under Settings, once added at your DNS provider, let MailGraf sign for it (Add a sending domain).

So in Gmail, Signed by shows your domain, and one dkim=pass names it in header.d. The Return-Path holds a bounce address MailGraf uses to collect failed deliveries, so it can differ from From.

To see this on a real email, send a test to a Gmail address and open Show original. Once the campaign is out, bounces and complaints by provider appear under Provider performance in the Deliverability report.