How to read email headers: a line-by-line walkthrough

To read email headers, open the message's original source, then read the Received lines from the bottom up to follow its route. Check the Authentication-Results line for SPF, DKIM and DMARC, and compare From, Reply-To and Return-Path. Trust the lines your own provider added at the top over anything below them.

Headers look like noise the first time. They are a log. Every server that touches a message stamps a line on top of it, and your provider adds its verdict on whether the sender is who it claims. Once you know which five or six lines matter, you can tell where a message came from, why it was late, and whether it is genuine.

How do I view email headers?

These follow the current help pages from Google, Microsoft and Yahoo. Menus move from time to time, so if a label is missing, look for "original", "source" or "raw".

What does an email header look like?

Here is a complete, slightly shortened header for one message. The names and domains are examples.

Delivered-To: sam@example.org
Received: from mx2.relay.example.net (mx2.relay.example.net [198.51.100.24])
        by mx.example.org with ESMTPS id 5b1f17b1804b1
        for <sam@example.org>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Fri, 02 Oct 2026 07:42:18 -0700 (PDT)
Authentication-Results: mx.example.org;
       dkim=pass header.i=@harborbank.example header.s=s2026;
       spf=pass smtp.mailfrom=bounces@mail.harborbank.example;
       dmarc=pass (p=REJECT) header.from=harborbank.example
Return-Path: <bounces@mail.harborbank.example>
Received: from smtp.harborbank.example (smtp.harborbank.example [192.0.2.80])
        by mx2.relay.example.net (Postfix) with ESMTPS id 4cQ1Zs5Hk2z9sTB
        for <sam@example.org>; Fri,  2 Oct 2026 14:42:15 +0000 (UTC)
Received: from [10.0.4.12] (cpe-203-0-113-45.isp.example [203.0.113.45])
        by smtp.harborbank.example (Postfix) with ESMTPSA id 4cQ1Zr2Xb7z1yQ;
        Fri,  2 Oct 2026 14:42:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; d=harborbank.example; s=s2026;
        h=from:to:subject:date:message-id; bh=47DEQpj8HBSa; b=Qx7pLm2aR9kT3
From: Jordan Lee <jordan@harborbank.example>
Reply-To: Jordan Lee <jordan@harborbank.example>
To: Sam Rivera <sam@example.org>
Subject: Your account review is ready
Date: Fri, 2 Oct 2026 16:42:09 +0200
Message-ID: <7f3a91c2-5d84@harborbank.example>

Read it from the bottom up

New lines are added at the top, so the story starts at the bottom.

The sender's own lines (From, To, Subject, Date, Message-ID). These were written by the sender's mail program. They are what your inbox displays. Jordan's computer says the message was written at 16:42:09 in a time zone two hours ahead of UTC.

DKIM-Signature. The sending domain signed the message. d=harborbank.example is the domain taking responsibility, and h= lists the parts that were signed. You do not verify this by eye. Your provider does, and reports the result higher up.

The bottom Received line. This is the first hop. A device at 203.0.113.45 handed the message to smtp.harborbank.example. ESMTPSA means the device logged in with a password (the A) over an encrypted connection (the S). This is the line that sometimes shows the sender's home or office IP address.

The middle Received line. The bank's server passed the message to a relay, mx2.relay.example.net, four seconds later. Each Received line follows the same pattern: from the server that sent it, by the server that took it, with the protocol, then a timestamp.

Return-Path. The address that gets the bounce if delivery fails. Here it is on a subdomain of the same company. A different Return-Path is normal for newsletters, which often hand bounces to their mailing service.

Authentication-Results. Sam's provider, mx.example.org, ran its checks and recorded them: DKIM passed for harborbank.example, SPF passed for the Return-Path domain, and DMARC passed because the From domain matches a domain that passed. If you read only one line in a header, read this one.

The top Received line. The relay delivered to Sam's provider at 07:42:18 Pacific time, which is 14:42:18 UTC. From writing to delivery took nine seconds. The version=TLS1_3 note records that this hop was encrypted.

Delivered-To. The mailbox the message finally landed in.

Which header lines can you trust?

This is the question that decides everything else, and most guides skip it. Anyone can type header lines into a message before sending it. The lines added after the message reached your provider are different, because your provider wrote them.

The standard behind Authentication-Results, RFC 8601, is built on this idea. It defines a trust boundary around your provider's own servers, and says results are only meaningful when they were added inside it. It also has a section on forged header fields, which advises providers to remove any Authentication-Results line that claims to be theirs but arrived from outside. In practice: find the Authentication-Results line that names your own provider's server, and believe that one.

Yahoo's help page gives the same rule in plainer words. To find the true sender of a forged email, it says, compare the From address with the top-most Received line, because that is where the real sending information is.

What do the Received lines tell me?

Three things.

The route. Read upward and you see every server the message crossed. A message from a large company should start at that company or at a known mailing service. A trail that starts somewhere unrelated deserves a second look.

Delays. Compare timestamps from one Received line to the next. Convert them to the same time zone first, since each server writes its own. A gap of an hour between two lines tells you which server sat on the message. If the times run backwards by a few seconds, a server clock is off. That is common and harmless.

Encryption. Protocol names ending in S, such as ESMTPS, or a noted TLS version, mean that hop was encrypted in transit. Reading those markers has its own guide: how to check if your email is encrypted.

What does Authentication-Results mean?

It holds up to three results, each one pass, fail, or a softer value like none or neutral.

• spf=pass means the delivering server is on the list published by the domain in the Return-Path. See SPF.
• dkim=pass means the signature from the domain after header.i= or d= checked out and the signed parts were not changed.
• dmarc=pass means the domain in From matches a domain that passed one of the two. p=REJECT in brackets is the policy the domain owner published for failures.

Google's help page puts the user-level rule simply: find the Authentication-Results header, and if the message was authenticated you will see spf=pass or dkim=pass. A DMARC fail on a message that asks for money or a login is a strong reason to distrust it.

Can headers show the sender's location?

Sometimes. In the example, the first hop exposes 203.0.113.45, the address of the connection Jordan sent from. An IP address usually reveals the internet provider and the rough area, never a street address. Many webmail services leave the writer's IP out, so you will often find only mail server addresses. Some setups add it in a line called X-Originating-IP.

Addresses that start with 10., 192.168. or 172.16. to 172.31. are private network addresses. They identify a device inside someone's office or home network and say nothing about location.

The shortcut: let a tool read them

Once you know what the lines mean, you do not have to parse them by hand every time. Paste a header block, or the whole original message, into the free Secria email header analyzer and click Analyze headers. It flips the Received lines into a timeline with the oldest hop first, shows the time between hops, marks which hops were encrypted, lists the SPF, DKIM and DMARC results, compares Reply-To and Return-Path with the From domain, and flags any exposed sender IP. It runs in your browser, so nothing you paste is uploaded.

For the example above it reports that the message passed through 3 servers and took 9 seconds, that every hop between servers was encrypted with TLS, that all three checks passed for harborbank.example, and that the sender's IP address is visible. That is the same reading we just did by hand.

Frequently asked questions

Why are there so many Received lines?

One for each server that handled the message. A message inside one provider may have several internal hops, and a message through a mailing service or a spam filter picks up more. Five to ten lines is ordinary.

Can email headers be faked?

The lines written by the sender can, including From, Reply-To, Date and any Received lines they add at the bottom. The lines your own provider adds on arrival cannot be faked by the sender. That is why the top Received line and your provider's Authentication-Results line carry the most weight.

Is it safe to share my email headers with someone?

Headers contain your email address, the sender's, the subject, server names and sometimes IP addresses. They do not contain your password. Share them with your IT team or a support desk when asked, and remove anything you would not want public before posting them in a forum.

Why do the times in a header not match?

Each server writes the time in its own zone, shown as an offset like +0000 or -0700. Convert them all to UTC and they will line up. A small mismatch after that is a clock that needs setting.

In short

Open the original, start at the bottom, follow the Received lines up, and let your provider's Authentication-Results line settle whether the sender is real. If you would like an inbox that gives away less about you in the first place, Secria Mail removes tracking pixels automatically and senders never see your IP address.