Email Header
An email header is the block of metadata at the top of every message, defined by RFC 5322, that carries the routing trail, identity fields, and authentication results recipients never normally see. It holds From, To, Subject, and Date, plus the technical Received, Return-Path, and Authentication-Results lines that tell the real story of where a message came from.
-
The visible
Fromcan be forged; the header trail is where you verify what is real -
Receivedlines read bottom to top, tracing every server the message passed through -
The
Authentication-Resultsline records the SPF, DKIM, and DMARC verdicts - Only the date and a sender address are strictly required; everything else is optional
Field-Name: value pairs
Date + an originator address
Return-Path · Received
Authentication-Results
Received lines: bottom to top
What an email header contains
Every email has two parts: the body you read, and the header that precedes it. The header is a list of Field-Name: value lines that ends at the first blank line, after which the body begins. Most of these fields are hidden by your mail client, but they carry everything a receiving server needs to route, authenticate, and judge the message.
Under RFC 5322, the only strictly required fields are the origination date (Date) and an originator address (From). Everything else, including To, Subject, and Message-ID, is technically optional, though a message without a Message-ID causes problems with threading, deduplication, and DKIM signing, so well-formed mail always includes one.
Return-Path: <bounce@mail.example.com>
Received: from mail.example.com (203.0.113.10)
by mx.recipient.net; Tue, 10 Jun 2026 09:14:02 +0000
Authentication-Results: mx.recipient.net;
spf=pass dkim=pass dmarc=pass
From: "Example" <hello@example.com>
To: you@recipient.net
Subject: Your June statement
Message-ID: <a1b2c3@example.com>
Date: Tue, 10 Jun 2026 09:14:00 +0000Reading the trace fields
The most useful part of a header for deliverability is the trace: the Received and Return-Path fields. Each mail server that handles a message adds its own Received line at the top, so the lines build up in reverse: the bottommost was added first (the original sender) and the topmost was added last (the final server). Reading from the bottom up traces the message’s journey, and a forged header often shows up as a gap or an impossible hop in that chain.
The Return-Path field, inserted by the final delivery server, records the envelope sender that bounces go to. Because it can differ from the visible From, comparing the two is a quick way to spot mail sent through a third party or, sometimes, a spoof.
The authentication line
The line that matters most for sender reputation is Authentication-Results, added by the receiving server to record how the message fared on each check. A healthy line reads something like spf=pass dkim=pass dmarc=pass. If you are debugging why mail lands in spam, this single field tells you at a glance whether SPF, DKIM, and DMARC passed, and whether DKIM and SPF aligned with your From domain. Our email header analyzer parses these fields for you so you do not have to read them by hand.
Common mistakes
From a recipient sees is easy to forge. The header trail, the Received chain, Return-Path, and Authentication-Results, is where you confirm whether a message is genuinely from who it claims.dkim=fail or dmarc=fail here points straight at the misconfiguration to fix.Frequently asked questions
From header is the visible sender your recipient reads. The Return-Path is the envelope sender where bounces are delivered, inserted by the receiving server from the SMTP MAIL FROM. They often differ when mail is sent through an ESP, and SPF checks the Return-Path, not the From.