Email Headers Explained And Which Ones to Trust

Email headers are the block of lines above every message that almost nobody reads. Every message carries a block of lines above it that almost nobody reads. Part of it comes from the sender and is worth nothing. The rest is added by servers along the way and cannot be faked. Telling those two apart is the whole skill. It takes about five minutes to learn.

You need this when something looks wrong. A note claiming to be from a bank. A delivery that took eleven hours. A sender insisting they never wrote what you received. The answer usually sits in the headers, written in a format that has barely changed since 1982. The same block appears at the top of every EML file, because a saved message is a message.

What an Email Header Block Is

A header is a name, a colon, then a value. Nothing more complicated than that. They run from the top of the message down to the first blank line. That blank line is the only thing separating them from the body.

From: Site Notices <notices@example.net>
To: sam@example.org
Subject: Scaffold permit renewal
Date: Tue, 4 Mar 2026 09:41:00 +0000
Message-ID: <20260304094100.A7F2@example.net>
                          <- this blank line ends the headers
The body of the message starts here.

The blank line is structural, not decorative. Everything above it is instructions to software. Everything below it is what a person wrote. Lose that line in a conversion and a reader has no way to tell where one stops and the other starts, which is why a badly converted message sometimes shows its own headers as text.

The Email Headers the Sender Wrote

These are the familiar names. They are also the ones worth the least, because the sending program chose every one of them.

Bcc is missing because it has to be. A blind copy works by leaving the address out of the headers entirely and handing it to the server separately. Nothing in a received message reveals who else got a blind copy, which is the point.

The Email Headers the Servers Wrote

Now the useful half. Every server that handles a message adds a Received line. It adds it at the top.

Received: by your-server
Received: by relay-two
Received: by relay-one
Received: from sender

From: ...
Subject: ...

4  by your-server
3  by relay-two
2  by relay-one
1  from sender  <- start here

Each line carries a timestamp. Subtract one from the next and you have how long that hop took, which turns a vague complaint about slow mail into a specific one about a specific server.

A sender can add Received lines too. Fake ones, at the bottom, inventing a history that never happened. What they cannot do is forge the lines added after the message left them. So the lines you trust are the ones written by servers you or your provider control, counting down from the top until you reach the first one you have no reason to believe.

The Email Headers That Settle Arguments

Three checks run on most mail now. The receiving server writes down how each one went.

Authentication-Results: mx.example.org;
  spf=pass smtp.mailfrom=example.net;
  dkim=pass header.d=example.net;
  dmarc=pass header.from=example.net

Pass does not mean safe. It means the message really came from the domain it claims. A domain set up an hour ago to look like a bank will pass all three checks perfectly, because it genuinely owns the name it is using. The checks prove identity rather than honesty.

Reading Email Headers in Under a Minute

1. Find Authentication-Results and read the verdict. Three passes and the message is from where it says. Any fail and everything below is in question.
2. Compare From with Return-Path. Different domains is ordinary for mailing lists and newsletters. Different domains on a message claiming to be personal is worth a second look.
3. Read the Received lines from the bottom up. Ask where it started and whether that matches the sender it claims to be. A message from a bank starting at a home broadband connection is answering your question already.
4. Subtract the timestamps. One hop taking hours while the rest took seconds tells you where a delay happened. It is almost never where people assume.
5. Check Message-ID for a matching domain. Most servers build it from their own name. One that does not match anything else in the block is a small signal worth adding to the others.

What Email Headers Explain That Nothing Else Does

That last row is a MIME matter rather than a header one. Headers were specified for plain characters, so anything else has to be wrapped in a marker naming its character set. A client that cannot unwrap it shows the marker instead.

Why the Email Header Block Has Barely Changed

The format was written down in 1982 and revised twice without altering its shape. A name, a colon, a value, one per line. New fields arrive constantly and none of them required the format to change, because adding a name to a list was always all it took.

IANA keeps the register of field names, the same way it keeps the register of content types. That is why a header your software has never seen causes no trouble. Software that meets an unfamiliar field is expected to carry it along untouched, which is exactly what every server did with the authentication fields before anyone supported them.

This is also why headers survive conversion and formatting does not. They are plain text in a fixed shape, so any format built on the message keeps them whole. What loses them is converting to something that stores a picture of the message rather than the message.

Reading them without a mail client is a parsing job. Our EML viewer lays the block out in a browser tab rather than hiding it behind a menu. Where a folder of messages has to move somewhere the headers will survive, the converters handle the route.