# What is an Email Header?

> What an email header is, how to read the Received and Authentication-Results lines, why the From address can lie, and how headers expose spoofing.

An email header is the block of metadata carried at the top of every message that records where it came from, the path it took, and how it was authenticated. Your mail client hides most of it and shows you only `From`, `To`, `Subject`, and the date — but the full header is the message's travel log, and it is where you confirm whether a message is genuine or forged. Paste one into the free [email header analyzer](/tools/email-header-analyzer) to decode the route and authentication results in seconds.

Headers hold two kinds of information: descriptive fields the sender fills in (`From`, `To`, `Subject`) and technical fields that servers add as the message moves (`Received`, `Authentication-Results`, `Message-ID`). The descriptive fields are easy to fake; the technical ones, added by receiving servers, are what you actually trust.

## How an email header is built

A header is assembled incrementally — each server that touches the message adds its own lines on top, so the newest information sits at the very top and the oldest at the bottom.

1. Your mail client ([MUA](/learning/what-is-an-mta)) writes the initial fields: `From`, `To`, `Subject`, `Date`, and a unique `Message-ID`.
2. Your outbound server ([MTA](/learning/what-is-an-mta)) hands the message off over [SMTP](/learning/what-is-smtp), stamping the envelope sender in `Return-Path`.
3. Every relay along the route — guided by the recipient's [MX records](/learning/what-is-an-mx-record) — prepends a `Received:` line naming the server it came from and the time it arrived.
4. The receiving server runs [SPF](/learning/what-is-spf), [DKIM](/learning/what-is-dkim), and [DMARC](/learning/what-is-dmarc) checks and records the outcome in an `Authentication-Results:` header (defined in RFC 8601).

To read the journey, start at the **bottom** `Received:` line (the origin) and work up to the top (the final delivery). A gap in the chain, or an unexpected relay, is often the first sign something is wrong.

## What a header looks like

A trimmed real-world header reads like this:

```
Received: from mail.example.com (mail.example.com [203.0.113.24])
        by mx.recipient.com with ESMTPS id 4a1f2c
        for <you@recipient.com>; Fri, 10 Jul 2026 14:41:00 -0400
Authentication-Results: mx.recipient.com;
        spf=pass smtp.mailfrom=example.com;
        dkim=pass header.d=example.com;
        dmarc=pass (p=reject) header.from=example.com
From: "Billing" <billing@example.com>
To: you@recipient.com
Subject: Invoice #2048
Message-ID: <a1b2c3@example.com>
```

The `Authentication-Results` line is the one that matters most. Here SPF, DKIM, and DMARC all pass, and critically `header.from=example.com` **aligns** with the DKIM and SPF domains — so the visible sender is genuine. A `dmarc=fail` on that line, or a `header.from` that does not match the authenticated domain, is a spoofing red flag.

## The records behind the authentication results

Those `spf=`, `dkim=`, and `dmarc=` verdicts are not generated from nothing — they are the receiver's checks against the DNS records the sending domain publishes:

![The records behind a header's authentication results](/images/figures/email-header-auth-records.webp)

If a domain has not published these records, the header simply reports `none`, and the receiver has far less to go on. That is why reading a header and configuring authentication go hand in hand — the header only tells you as much as the sender's DNS lets it.

## Why email headers matter

- **Spotting [spoofing](/learning/what-is-spoofing).** The visible `From:` can say anything; the `Authentication-Results` line reveals whether the domain actually authenticated. Trust the verdict, not the display name.
- **Diagnosing delivery failures.** When a message bounces or lands in [spam](/learning/understanding-spam-emails), the `Received` chain and any error text show exactly where it broke — an unlisted sending server, a failed DKIM signature, a misrouted relay.
- **Tracing the origin.** The bottom `Received` line and the sending [IP address](/learning/what-is-an-ip-address) let investigators locate where a phishing message really started.
- **Confirming a trusted sender.** A clean, aligned authentication result is what lets brand features and reputation systems treat your mail as legitimate.

## Things to keep in mind

- **The `From:` field is not proof of anything.** It is sender-supplied text. Always prefer the DMARC result over the address you see.
- **Read `Received` lines bottom-up.** Newest is on top; the origin is at the bottom.
- **Some fields can be forged; the authentication verdict cannot be faked by the sender.** Only the receiving server writes `Authentication-Results`, so it reflects what actually happened.
- **Headers contain metadata like IP addresses.** Treat a full header as sensitive when sharing it for support.

## Frequently asked questions

### How do I view the full header in Gmail or Outlook?

In Gmail, open the message, click the three-dot menu, and choose **Show original**. In Outlook, open the message and use **File → Properties** (desktop) or the message's **View message details** option. Both show the raw header you can paste into an analyzer.

### What's the difference between the From address and the Return-Path?

`From:` is the address the reader sees; `Return-Path` is the envelope sender that receives bounces and that SPF actually checks. They can legitimately differ — a marketing platform often uses its own `Return-Path` — which is one reason DMARC alignment, not the raw addresses, decides trust.

### Why does a message show spf=pass but dmarc=fail?

Because SPF passed for a *different* domain than the one in your `From:`. DMARC requires alignment between the authenticated domain and the visible `From:` domain. A pass on an unaligned domain still fails DMARC — a common signature of spoofed mail sent through a real relay.

### Can I trust an email if the header shows dkim=pass?

Not on its own. DKIM can pass for the attacker's own domain while they display your brand in `From:`. Look for `dmarc=pass` with `header.from` aligned to the authenticated domain — that combination is what confirms the sender is who they claim to be.

### Do headers reveal the sender's real IP address?

Usually the sending server's IP appears in the earliest `Received` line, though relays and privacy features can mask the originating client. It is enough to identify the sending infrastructure, which is what matters for reputation and abuse reports.

## Related reading

- [What are DMARC, DKIM, and SPF?](/resources-post/what-are-dmarc-dkim-and-spf)
- [What is an impersonation attack and how can you stop it?](/learning/what-is-an-impersonation-attack-and-how-can-you-stop-it)
- [What is an IP reputation?](/learning/what-is-an-ip-reputation)