Every email carries a block of text you normally never see: its headers. Your mail app shows four of them (From, To, Subject, Date) and hides the rest. The hidden part is where the useful information is. It records every server the message passed through, how long each one held it, and what the receiving server thought of the sender.

You need the headers when a message landed in spam, arrived hours late, or bounced for a reason you do not understand. They are also how you check whether an email that claims to come from your bank really does.

How to open the full headers

Gmail (web): open the message, click the three dots next to the reply arrow, then Show original. A new tab opens with a short summary (SPF, DKIM and DMARC results) at the top and the raw headers underneath.

Outlook on the web: open the message, click the three dots, then View and View message source.

Outlook for Windows: open the message in its own window, then File, Properties. The headers are in the box called "Internet headers". The box is small; click inside it, select everything and copy.

Apple Mail: select the message, then View, Message, All Headers.

Copy everything from the first line down to the first empty line. After that empty line comes the body of the message, which you do not need. If you paste the result into our email header analyzer, it lays the route out as a table and explains each result. It works in your browser, so the headers are not sent anywhere.

Read them from the bottom up

This is the part that confuses most people. Each server that handles a message adds its own lines at the top. So the oldest information sits at the bottom, and the newest at the top. To follow the message from sender to inbox, start at the bottom of the header block and read upwards.

The Received lines: the route

Here is one Received line, as Gmail writes it:

Received: from mail.example.com (mail.example.com. [198.51.100.25])
        by mx.google.com with ESMTPS id a1si1234567wrb.123.2026.10.29.03.10.11
        for <ana@example.org>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Thu, 29 Oct 2026 03:10:11 -0700 (PDT)

It reads as one sentence: the server mx.google.com received the message from a machine calling itself mail.example.com, whose real IP address was 198.51.100.25, with encrypted SMTP (ESMTPS), at 03:10:11 Pacific time.

A few details matter:

  • The name and the IP can disagree. The first name after from is what the sending machine said about itself. The part in parentheses is what the receiver saw: the name its reverse DNS gave, and the IP that actually connected. When you investigate a suspicious message, trust the IP in brackets.
  • The time is the receiver's clock. Compare two consecutive Received lines and you get the time the message spent between them. A gap of a few seconds is normal. A gap of 20 minutes means it waited somewhere, often because the receiving server deferred it ("try again later") and the sender retried.
  • Lines written by the sender's own network can be faked. Only the Received lines added by servers you trust (your own provider, at the top) are reliable. Anything below the first server you do not control is information the sender gave, not proof.

A typical message has three to six Received lines: the sender's app or mail client, the sending provider's servers, then the receiver's servers.

Authentication-Results: the receiver's verdict

This is the most useful line in the whole block. The receiving server writes it after checking the message:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1 header.b=AbCd1234;
       spf=pass (google.com: domain of bounce@example.com designates 198.51.100.25 as permitted sender) smtp.mailfrom=bounce@example.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

It starts with the name of the server that ran the checks (mx.google.com), then gives one result per method:

Part What it tells you
spf=pass The sending IP is listed in the SPF record of the domain in smtp.mailfrom (the bounce address).
dkim=pass The message carries a valid DKIM signature from the domain in header.i or header.d, with the key named by the selector header.s.
dmarc=pass SPF or DKIM passed for the same domain as the From address. p=REJECT is the policy that domain publishes.

Other values you will meet: fail (the check ran and failed), softfail (SPF only: the domain says "probably not allowed" with ~all), none (no record to check), neutral, temperror (a DNS lookup failed for a moment) and permerror (the record itself is broken, for example an SPF record with more than 10 DNS lookups).

Two things trip people up here.

First, only the top Authentication-Results line counts. If a message passes through several systems, you may find more than one, and some may come from the sender's side. The receiver's verdict is the one at the top, written by a server whose name you recognise.

Second, "pass" for the wrong domain. Look at the domains, not only the word pass. A newsletter tool may produce dkim=pass header.d=sendgrid.net while your From address is news@example.com. DKIM passed, but for the tool's domain, not yours, so it does nothing for your DMARC. That case is explained in our guide to DMARC failures.

DKIM-Signature: how the sender signed

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1;
        h=from:to:subject:date; bh=...; b=...

You do not need to read the long b= value. Three tags are enough:

  • d= is the domain that signed.
  • s= is the selector. The public key lives in DNS at s1._domainkey.example.com.
  • a= is the algorithm, normally rsa-sha256.

With d= and s= you can look up the key yourself in the DKIM checker and see whether it is still published and long enough. Our DKIM record guide explains what a healthy key looks like.

The other lines worth knowing

  • Return-Path: the address bounces go to. It is often a technical address of the sending platform, such as bounces+123@em.example.com. SPF checks this domain, not the From domain.
  • Message-ID: a unique identifier created by the sender. Handy when you ask a provider's support about one specific message.
  • List-Unsubscribe and List-Unsubscribe-Post: the unsubscribe link mail apps show next to the sender name. Since 2024, Gmail and Yahoo expect bulk senders to support one-click unsubscribe, which means both headers, with List-Unsubscribe-Post: List-Unsubscribe=One-Click. See the 2026 sender requirements.
  • ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results: added by forwarding services and mailing lists to record what the authentication looked like before they changed the message.
  • X- headers (X-Mailer, X-Spam-Status, X-MS-Exchange-…): custom lines added by a particular program or provider. Some are useful (spam scores), most are internal noise.

Three things headers tell you that nothing else does

Why a message went to spam. Start with Authentication-Results. If SPF or DKIM failed, or DMARC failed, that is your answer, and the fix is in DNS. If all three pass, the reason is reputation or content, which the headers do not show directly. Some providers add their spam score in an X- header (X-Spam-Status, X-MS-Exchange-Organization-SCL).

Why a message arrived late. Compare the timestamps of consecutive Received lines and find the big gap. If the gap sits between the sender's server and the receiver's first server, the receiver probably deferred it, for example with 421 4.7.28 rate limiting at Gmail or greylisting. If the gap is inside the sender's own servers, the problem is on their side.

Whether a message is really from who it claims. Phishing often uses a From address that looks right. Check that dmarc=pass and that the passing domains are the real company's domain. A message "from your bank" that passes DKIM only for mailer.example and fails DMARC was not sent by your bank.

A note on privacy

Headers contain email addresses, names, and the IP addresses of the servers involved. Sometimes they include the IP of the sender's own computer, when they wrote from a desktop mail app. Think twice before posting full headers in a public forum. If you need help from a forum, replace the addresses with placeholders first.

Frequently asked questions

Can email headers be faked?

Partly. The sender controls everything they write before the message leaves: From, Subject, Date and any Received lines added on their side. They cannot control the lines added by the receiving servers, including the top Received lines and Authentication-Results. That is why you read from the top down when you check authenticity.

Why do I see no Authentication-Results line?

You are probably looking at a copy in your Sent folder. The results are written by the receiving server when the message arrives. Send a test message to an address at Gmail or Outlook.com and open the headers of the copy that was received.

Do headers show the sender's location?

They show IP addresses, and an IP can be roughly placed on a map. But most email today leaves from a provider's servers (Google, Microsoft, a newsletter platform), so the IP points to that provider's data centre, not to the person.

How big can headers get?

A few kilobytes is normal. Messages that went through many security gateways and forwarders can reach 20 KB or more, mostly because of ARC and vendor X- headers.

Sources