How to read email headers (the full delivery path, in plain English)

The header is the flight recorder for a message

An email header is the flight recorder for a message. It logs every server the mail touched, whether it proved who it claimed to be, and why the mailbox let it in or turned it away. Most people never open it, then wonder why a send bounced or landed in spam. Read it once and the guessing stops. Here is how to view a header, read it top to bottom, and pull the one answer you came for.

What an email header is, and how to read it

An email header is the hidden block of metadata above every message. Read it bottom to top for the delivery path: the oldest server is at the bottom, the mailbox that received it is at the top. The lines that matter most are the Received trail (where it traveled), and the Authentication-Results line, which shows SPF, DKIM and DMARC as pass or fail. Fail on those is a common reason mail bounces or gets filtered. The header tells you what happened to one message after you sent it.

First, get the raw header

You need the full source, not the pretty view. Here is where it hides.

Gmail (web)

• Open the message.
• Click the three dots (More) at the top right of the email.
• Choose Show original.
• Copy the whole block, or hit Download Original for a .eml file.

Outlook (desktop)

• Double-click the message so it opens in its own window.
• File, then Properties.
• The header sits in the Internet headers box at the bottom. Select all, copy.

Outlook (web)

• Open the message.
• Three dots (More actions), then View, then View message source.

Apple Mail

• Open the message.
• View menu, then Message, then All Headers (or Raw Source for the whole thing).
• Shortcut for raw source: Option, Command, U.

Once you have the block, you can read it by eye, or paste it into a free header tool that lays the lines out for you. Either way, the parts below are what you are looking for.

How to read it, top to bottom

A header looks like a wall of text. It is not. It is a stack of labeled lines. Here are the ones worth your time.

From, To, Subject, Date The friendly stuff. Note that From is just a claim. Anyone can type a name in it. The header is where you find out if that claim held up.

Received The travel log. Each server that handled the mail stamps its own Received line on top, so the list reads newest at the top, oldest at the bottom. Read it bottom to top to follow the message from sender to mailbox. A long or weird chain, or a jump through a server that has nothing to do with the sender, is worth a second look.

Return-Path The address bounces go back to. If it does not match the visible From, that is normal for a lot of legit bulk mail, but it is also the address the receiving server checks SPF against.

Authentication-Results The verdict line for identity. This is the one that decides a lot of fates. It reports:

• spf=pass / fail did the sending server have permission to send for that domain
• dkim=pass / fail was the message signed and did the signature hold
• dmarc=pass / fail did the whole thing line up under the domain's policy

Message-ID A unique fingerprint for the message. Handy when you are chasing one specific email through logs.

X-headers (X-Spam-Score, X-Spam-Status, and similar) Optional lines some servers add. An X-Spam-Score is a hint, not a law, but a high one tells you the receiving side was already suspicious.

An annotated header (the parts that matter)

Received: from mail.sender.com (mail.sender.com [203.0.113.10])   <- oldest hop, read this first
        by mx.recipient.com with ESMTPS
        for <you@recipient.com>; Tue, 26 Aug 2026 09:14:02 -0500
Authentication-Results: mx.recipient.com;
        spf=pass smtp.mailfrom=sender.com;                        <- allowed to send: good
        dkim=pass header.d=sender.com;                            <- signature held: good
        dmarc=pass (p=reject) header.from=sender.com              <- everything lined up: good
Return-Path: <bounce@sender.com>                                  <- where bounces go
From: "Sales Team" <hello@sender.com>                             <- a claim, checked above
Subject: Your August invoice
Date: Tue, 26 Aug 2026 09:14:01 -0500
Message-ID: <a1b2c3@sender.com>                                   <- this message's fingerprint

Three passes on the Authentication-Results line is what a healthy, trusted message looks like. Swap any of those to fail and you have found a reason the mailbox got nervous.

What pass and fail actually mean for you

Authentication is not paperwork. It is the receiving server deciding whether to trust you.

• All pass. You proved who you are. That is the floor for good delivery. It does not promise the inbox, but it clears the biggest, most common blocker.
• SPF fail. The server you sent from was not on the domain's approved list. Often a misconfigured sending tool, a new platform you forgot to authorize, or spoofing.
• DKIM fail. The signature did not match, so the message may have been altered in transit or was never signed right. Forwarding can break it too.
• DMARC fail. SPF and DKIM did not line up with the From domain under the domain's own policy. If that policy is strict, a fail can send the message straight to spam or get it rejected outright.

If you send for a living and you see fails on your own mail, that is a fix-it-now signal. Start with SPF, DKIM and DMARC, the basics.

How a header reveals a bounce cause

A bounce message is itself an email, and its header (plus the body it carries back) usually names the culprit. Read it the same way.

• The status code. Look for a line like Status: 5.1.1 or an SMTP reply in the body. A 5.x.x is a hard bounce, the address is dead or refused. A 4.x.x is temporary, a retry-later throttle. 5.1.1 in particular means the mailbox does not exist.
• The reporting server. The Received chain shows which hop rejected it, so you know whether the recipient's side refused it or your own relay did.
• The reason text. Phrases like "user unknown", "mailbox full", "policy rejection", or "blocked" tell you what to do next: drop a dead address, retry a full one, or fix a reputation problem.

The header does not fix the bounce. It tells you the cause so you stop repeating it. For the full breakdown of each type, see why is my email bouncing.

Send fewer bad emails so you read fewer bad headers

A header is an autopsy. It tells you what happened to one message after it left your hands. Useful, but it is after the fact, one email at a time.

The better move is to send fewer bad ones in the first place. Every dead address you mail is a bounce you will later have to read a header to explain. Run the list through Listgevity before you send and every address comes back with a plain verdict: Inbox the good ones, Caution the risky, Remove the dead. Fewer bad sends means fewer ugly headers to debug, and a reputation that keeps your good mail moving.

A basic header check tells you what one message did. Listgevity tells you which addresses to trust before you hit send.

FAQ

Do I read a header top to bottom or bottom to top? Read the whole thing top to bottom to find the labeled lines you care about. But read the Received chain bottom to top, because the oldest server is stamped at the bottom and the receiving mailbox is at the top. That order is how you follow the real path.

Can I trust the From line? Only after you check the Authentication-Results line. From is a claim the sender types in. SPF, DKIM and DMARC are what test whether that claim is real. Pass on all three is your signal it is legit.

Will reading headers fix my bounces or my spam problem? No. Headers diagnose, they do not repair. They tell you the cause, dead address, failed authentication, throttling, so you can act. The fix is cleaning the list and getting authentication right. And no tool, header reader or otherwise, can promise you the inbox. Be careful with anyone who says they can.

A message passed authentication but still hit spam. Why? Authentication is the floor, not the finish line. A message can prove its identity and still get filtered for weak reputation, spammy content, or too many complaints from past sends. Passing SPF, DKIM and DMARC clears the biggest blocker, then reputation and content carry the rest.

Is a free header tool safe to paste into? A header holds routing and authentication data, not your password or the message body's secrets, so a reputable free header tool is fine for a quick read. Do not paste anything you would not want logged, and prefer a tool that does not store what you submit.