How to read email headers

A walk through the headers on a real message: who sent it, which servers handled it, and whether it passed authentication.

Every email carries a block of headers above the body. Your mail app shows three or four of them, tidied up: who it is from, the subject, the date. The rest are hidden, and they are the part that tells you where a message really came from. You read them when a message looks forged, when mail arrives hours late, or when your own mail keeps landing in spam and you want to know why.

To see them, open the message and look in its menu for an option named something like “Show original”, “View source” or “View headers”. You get the raw text of the message. Everything above the first blank line is headers.

A sample message

Here are the headers of an invented but typical message. Maya, at example.org, has sent an invoice to Sam, at example.com. Long signature values are trimmed.

From: Maya Ortiz <[email protected]>
To: [email protected]
Subject: Invoice for October
Date: Tue, 03 Nov 2026 09:22:04 -0500
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8

A header is a name, a colon and a value. Lines that start with whitespace continue the header above them. The order matters: each server that handles a message adds its headers at the top, so the newest information is first and the oldest is at the bottom.

The Received chain, read from the bottom

Each server that accepts the message stamps it with a Received header saying who handed the message over, who took it, and when. Because new stamps go on top, you read the journey from the last Received line upward.

Bottom stamp. A computer at 198.51.100.44 handed the message to out1.mail.example.org. ESMTPSA means the connection was encrypted and the sender logged in. This is Maya's mail app submitting the message to her provider.
Middle stamp. out1.mail.example.org, at 192.0.2.25, delivered it to mx.example.com two seconds later. ESMTPS means the hop was encrypted with TLS. This is the moment the message crossed from the sender's organization to the recipient's.
Top stamp. mx.example.com passed it internally to store.example.com, the server that holds Sam's mailbox.

In each line, the name after from is what the sending machine called itself, and the part in parentheses is what the receiving server observed: the address the connection actually came from, and the name that address resolves to. When the two disagree, believe the parentheses.

The timestamps are how you diagnose delays. Convert them to one time zone and compare each hop with the next. Here the whole trip took five seconds. If one gap were forty minutes, you would know which server sat on the message.

One caution. A Received header is just text, and a sender can paste in fake ones before the message leaves. The stamps you can trust are the ones added by your own provider's servers, which are the ones at the top. In this sample, the middle stamp is the last trustworthy fact about the origin: mx.example.com saw a connection from 192.0.2.25. Anything below that line is the sender's account of events.

From, Return-Path and Reply-To

A message has two sender addresses, and they do different jobs.

From is written inside the message and is what your mail app displays. The sending software can put anything there.
Return-Path records the envelope sender: the address the sending server gave during delivery, and where bounce notices go. The final receiving server writes it at the top.

In the sample they differ: mail is from [email protected], but bounces go to [email protected]. That is normal. Newsletters, mailing lists and most company mail systems use a dedicated bounce address. A mismatch is only suspicious when the two domains have nothing to do with each other, such as a From naming your bank and a Return-Path at an unrelated domain.

Also check for a Reply-To header. If present, your reply goes there, not to the From address. A message that claims to be from a colleague but replies to an outside address is a classic sign of fraud.

Message-ID and Date

Message-ID is a unique label the sending system gives each message. The part after the @ is normally the sender's domain or mail server. Replies quote it in their In-Reply-To and References headers, which is how mail apps group a conversation into a thread. It is also the thing to give a mail administrator when you ask them to find a message in their logs.

Date is set by the sender's device, so it is only as accurate as that device's clock. Here it reads 09:22:04 with an offset of -0500, which is 14:22:04 UTC, one second before the first server stamp. A Date that is far from the Received times means a wrong clock or a message that was written to look older or newer than it is.

Authentication-Results

This header is the receiving server's verdict on whether the message is entitled to use the domain it claims. It starts with the name of the server that did the checking, then lists each test.

spf=pass: the connecting address, 192.0.2.25, is on the list of servers allowed to send for the envelope domain, mail.example.org.
dkim=pass: the signature in the DKIM-Signature header verified against the public key published by example.org under the selector s2026. The signed headers and body were not altered on the way.
dmarc=pass: at least one of those passes was for a domain that matches the one in From. This is the result that connects the checks to the address you actually see.

Results other than pass include fail, softfail, neutral, none (the domain publishes nothing to check against) and temperror or permerror (the check could not be completed). The guide to SPF, DKIM and DMARC explains what each test proves.

Only trust an Authentication-Results header whose first field names your own mail provider. A forger can add one of their own that says everything passed. And remember what a pass means: the message really came from that domain. It says nothing about whether the domain belongs to who you think. Mail from a lookalike domain passes every check.

Letting a tool do the parsing

Reading raw headers gets tedious on real messages, which can have a dozen hops and several signatures. The email header analyzer on this site does the mechanical part. Paste a header block and it lists the Received hops in the order they happened, oldest first, with the address and timestamp of each. It shows the SPF, DKIM and DMARC result from every Authentication-Results header, and pulls out From, To, Subject, Date, Message-ID, Reply-To and X-Mailer. The parsing runs in your browser and the headers are not uploaded.

It reports what the headers say. It does not look anything up or re-verify signatures, so the cautions above still apply: trust the top of the chain, and treat everything below your own provider's first stamp as a claim. If a pasted message contains images you would rather not load while investigating, the guide on tracking pixels explains why viewing the source is the safe way to look.