How to Read Email Headers: Who Really Sent This?

Every email carries a hidden set of lines called headers: a record of who sent it, which servers handled it and whether it passed authentication checks. You do not need to be a mail administrator to read the parts that matter. This guide shows where to find the headers and how to read them in about two minutes.

How to open the full headers

Every mail service hides headers by default and offers a way to see them:

Where you read mail	How to show headers
Gmail on the web	Open the message, click the three-dot menu next to Reply, choose Show original
Outlook on the web	Open the message, three-dot menu, View, then View message source or View message details
Outlook for Windows	Open the message in its own window, File, Properties, then the Internet headers box
Apple Mail	View menu, Message, All Headers (or Raw Source)
Thunderbird	View menu, Message Source
Mail generators	Many offer a "source", "raw" or "headers" button next to the message

Menu names change from time to time, but the option is always near "view source" or "original".

The anatomy of a header block

Here is a shortened, made-up example:

Return-Path: <bounce-7781@mail.shop.example>
Received: from mail.shop.example (mail.shop.example [192.0.2.25])
        by mx.yourmail.example with ESMTPS id a1b2c3
        for <you@yourmail.example>; Tue, 27 Oct 2026 09:14:05 +0000
Authentication-Results: mx.yourmail.example;
        spf=pass smtp.mailfrom=mail.shop.example;
        dkim=pass header.d=shop.example;
        dmarc=pass header.from=shop.example
From: "Example Shop" <orders@shop.example>
Reply-To: support@shop.example
To: you@yourmail.example
Subject: Your order has shipped
Date: Tue, 27 Oct 2026 09:14:02 +0000
Message-ID: <20261027091402.88@shop.example>

It looks dense, but only five or six lines usually matter.

The lines worth reading

From

What your mail app shows as the sender. It is written by the sender and can say anything, which is exactly why the other lines exist. Note the domain: here, shop.example.

Reply-To

Where your reply will go. A legitimate company may use a support address here. A Reply-To on a completely different domain from From, especially a free webmail address, is a classic sign of fraud.

Return-Path

The address that receives bounce messages. Bulk senders often use a separate bounce domain or subdomain, so a difference from From is normal. What matters is whether the domains are related to the company at all.

Received

Each server that handles the message adds a Received line at the top. So you read them from the bottom up to follow the message from its origin to you. The lowest lines can be faked by the sender; the top ones, added by your own provider, are reliable. The most useful line is usually the one where your provider says which server it received the message from.

Authentication-Results

This is the line most people should read first. Your mail provider records the outcome of three checks:

Check	Question it answers	What "pass" means
SPF	Was the sending server allowed to send for this domain?	The server's address is listed in the domain's published SPF record
DKIM	Was the message signed by the domain, and was it changed on the way?	A valid cryptographic signature from the domain shown in `header.d`
DMARC	Do SPF or DKIM pass for the same domain that appears in From?	The visible sender domain is backed by at least one aligned check

DMARC is the one that ties everything to the address you actually see. A message claiming to be from a big bank with dmarc=fail is almost certainly fake.

Date and Message-ID

The Date header is set by the sender and can be wrong; the timestamps in your provider's Received lines are more trustworthy. Message-ID is a unique identifier, useful when you report a problem to a support team.

Three real-life questions headers answer

"Is this email really from my bank?"

Check that dmarc=pass and that the domain in header.from is the bank's real domain, not a look-alike. Then apply the other checks in How to Spot a Phishing Email. Authentication proves the domain, not the honesty of its owner.

"Why did this land in spam?"

Look for fail, softfail or none in the authentication results, and for any spam-score headers your provider adds. If you run the sending domain, failing SPF or DKIM is the first thing to fix.

"Why was my verification code so late?"

Compare the times in the Received lines. A long gap between the sender's server and your provider points to a queue or a retry, often caused by greylisting, which we describe in Verification Email Not Arriving?

Privacy note: what headers reveal about you

When you send an email, your provider writes headers too. Large webmail services usually do not include your device's IP address; some smaller providers and desktop setups do. If that matters to you, send yourself a message and inspect its headers to see what your setup reveals.

Summary

Open the headers with "show original" or "view source".
Read Authentication-Results first: SPF, DKIM and especially DMARC.
Compare the domains in From, Reply-To and Return-Path.
Read Received lines from the bottom up and trust the top ones most.

Two minutes with the headers turns "this looks a bit odd" into an actual answer.