Every email message arrives with a complete record of where it came from, who handled it, and how it was assessed along the way. That record is the email header — and most senders never look at it. The body of the message is what users see; the headers are what mail servers see, and they contain the truth about deliverability that no dashboard summarises adequately.
A practical example: a customer reports that order confirmations are not arriving. The sending platform shows the message was delivered. The recipient says it never arrived. Both are technically correct. The header tells you which server handled the message last, whether DKIM passed, whether DMARC aligned, whether a content filter intervened, and whether the recipient’s mail server made a routing decision that diverted the message before it ever reached the inbox.
What Email Headers Are and Why They Matter
Email headers are the metadata that accompany every email message. They include the sender, recipient, subject, date, and a detailed log of every mail server that handled the message between sender and recipient. They also include the results of authentication checks (SPF, DKIM, DMARC) and any annotations added by spam filters, security gateways, or forwarding services.
Headers are written from the bottom up. The earliest entries are at the bottom of the header block, and each subsequent server prepends its own entries above. The very top of the header block is therefore the last server to touch the message — usually the recipient’s mail server.
For diagnostic purposes, headers contain three categories of information. Routing data shows the path the message travelled. Authentication data shows whether the message passed identity checks. Filtering data shows how the message was scored or annotated by security tools along the way.
How to View Full Headers in Major Mail Clients
The default view in every mail client hides headers. Accessing them requires specific menu commands.
Gmail (Web)
Open the message, click the three-dot menu next to the reply button, select “Show original.” This opens a new tab with the full message including all headers.
Gmail (Mobile)
Full headers are not directly accessible. The mobile app does not expose the “Show original” function, which is one reason header diagnosis is usually done on desktop.
Outlook Desktop
Open the message in its own window, click File → Properties. The Internet Headers field at the bottom contains the headers.
Outlook Web
Open the message, click the three-dot menu, select “View message source.”
Apple Mail
Open the message, View menu → Message → All Headers (or press Cmd+Shift+H).
Yahoo Mail
Open the message, click the three-dot menu, select “View raw message.”
Once you have the raw header text, the analysis can begin. Several free online tools — Google Admin Toolbox Message Header analyzer, MXToolbox, MessageHeader.io — will parse pasted headers into a readable timeline. They are useful for quick visualisation, but they do not replace knowing how to read the headers directly.
A Real Email Header, Decoded Line by Line
Below is a sanitised example of the header block from a real email, with explanation of each meaningful field.
The Received Chain — Tracing the Path
Received headers document the journey of the message from sending mail server to receiving mailbox. Each server that handles the message adds its own Received line at the top of the existing headers.
A typical Received chain reads bottom-up like this:
- The earliest Received line (at the bottom) shows the message leaving the sender’s mail server. It records the sending IP, the recipient address, and a timestamp.
- Subsequent Received lines (moving upward) show intermediate mail servers — typically the sending platform’s outbound infrastructure, then the receiving organisation’s edge mail server, then internal mail routing, then the final delivery to the user’s mailbox.
Each Received line includes the timestamp of when that server received the message. Comparing timestamps across the chain reveals where delays occurred. A normal end-to-end delivery is one to ten seconds. A multi-minute gap between two Received lines indicates that a server held the message for some reason — greylisting, virus scanning, content inspection, or rate limiting.
The format of a Received line is roughly:
Received: from [sending-host] by [receiving-host] with [protocol] id [server-message-id] for [recipient]; [timestamp]
The “from” field is the most diagnostically important. It contains the IP address and reported hostname of the sending server. Comparing the reported hostname to the actual reverse-DNS of the IP reveals attempted spoofing. Legitimate mail will have a sending hostname that matches the reverse-DNS of the IP.
Return-Path and Message-ID
Return-Path is the envelope sender — the address bounces will be sent to. It is distinct from the From: header, which is the human-readable sender. Mismatch between Return-Path and From: is normal for ESPs (where the sending platform sets its own Return-Path for bounce processing) but can also be a spoofing signal.
Message-ID is a unique identifier assigned by the sending mail server. It is useful for searching server logs to locate a specific message and for confirming whether duplicate deliveries are actually duplicates (same Message-ID) or distinct messages (different Message-IDs).
Authentication-Results — SPF, DKIM, DMARC Verdicts
The Authentication-Results header is added by the receiving mail server and records the outcome of every authentication check performed on the message. This is the single most diagnostically valuable line in any header.
A typical Authentication-Results header looks like:
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=sender@brand.com; dkim=pass header.i=@brand.com; dmarc=pass action=none header.from=brand.com
Each component shows pass, fail, neutral, softfail, or none. SPF pass means the sending IP is authorised in the domain’s SPF record. DKIM pass means the cryptographic signature was valid. DMARC pass means the message aligned with the domain’s DMARC policy.
A message landing in spam despite delivery to the inbox is often diagnosed in this single line. A DKIM fail or DMARC fail on a domain that has been carefully authenticated indicates a configuration problem — typically a sending service that has not been properly registered, or a relay that is rewriting the message in a way that breaks the signature.
ARC Headers and Forwarded Messages
ARC (Authenticated Received Chain) is a protocol that preserves authentication results across forwarding. When a message is forwarded — for example, through a mailing list, or from a corporate forwarder to a personal address — the forwarding server typically alters the message in ways that break SPF and sometimes DKIM. ARC allows the forwarder to vouch for the original authentication results so that the final receiver can still verify the chain.
ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal headers appear when the message has been forwarded through an ARC-aware server. Their presence is normal for forwarded mail and does not indicate a problem.
DKIM-Signature — What Each Tag Means
The DKIM-Signature header contains the cryptographic signature applied by the sending server. It is not human-readable in the conventional sense but its individual tags carry diagnostic value.
Key Tags
v=: DKIM version (almost always 1)a=: signing algorithm (typically rsa-sha256)d=: the signing domain (this should match the From: domain for DMARC alignment)s=: selector (used to look up the public key in DNS)h=: which headers are covered by the signaturebh=: body hashb=: the signature itself
The most diagnostically useful field is d=. If the d= value does not match the From: domain, DMARC alignment is broken even if DKIM technically passes. This is the most common cause of mysterious DMARC failures.
X-Headers (The Vendor-Specific Ones)
Any header beginning with X- is non-standard and added by a specific server or service. These vary widely.
Common X-Headers
X-Mailer:The software that composed the messageX-Originating-IP:The user’s IP at the time the message was sent (often added by webmail providers)X-Spam-Score:A spam score from a content filterX-MS-Exchange-CrossTenant-*:Microsoft 365 routing dataX-Forefront-Antispam-Report:Microsoft’s detailed spam scoring
X-headers are vendor-specific but often contain the most direct diagnostic information when something has gone wrong. A Microsoft X-Forefront-Antispam-Report with SCL (Spam Confidence Level) of 5 or above means Exchange Online has decided the message is likely spam, regardless of what other checks said.
Diagnosing Common Problems From Headers
The most useful skill in header reading is mapping symptoms to header sections.
Reading a Spam-Foldered Message
When a message lands in spam, the headers usually contain explicit explanation. Look first at Authentication-Results for failed checks. If authentication passed, look for X-Spam-* or X-Forefront-Antispam-Report headers indicating the receiver’s filter score. If neither shows the cause, look at the Received chain for unusual delays or intermediate servers that may have annotated the message in ways the visible headers do not show.
Reading a Bounced Message
Bounce messages contain the original message as an attachment, including the original headers. Open the original headers and look at the last Received line — the one closest to the recipient. The diagnostic explanation will often be in a Diagnostic-Code field or Final-Recipient field within the bounce report.
Spotting Spoofed or Phishing Emails
Authentication-Results is the first stop. Phishing messages almost always show SPF fail, DKIM fail, or DMARC fail — or all three. The From: domain may not match the d= value of any DKIM-Signature header. The Received chain may show unusual sending hosts that do not match the claimed sender’s known infrastructure.
Tools That Automate Header Analysis
Several tools save time on header parsing.
Google Admin Toolbox Message Header analyzer is free and accepts pasted headers, producing a visual timeline and explanation of authentication results. It is the most accessible option for non-experts.
MXToolbox Email Header Analyzer offers similar functionality with additional integration with MXToolbox’s other deliverability tools.
MessageHeader.io is a lightweight, ad-free alternative for quick parsing.
For ongoing operational use, monitoring tools like Mailgun’s deliverability dashboard, SendGrid’s Event Webhook, and inbox placement testing tools surface header data automatically without requiring manual extraction.
Key Takeaways
- Email headers are the metadata trail of every message and contain definitive answers to most deliverability questions.
- Headers are written bottom-up: the earliest server is at the bottom, the most recent at the top.
- The Received chain shows routing and timing. Authentication-Results shows SPF, DKIM, and DMARC verdicts. X-headers contain vendor-specific data.
- DKIM alignment with the From: domain is the most common silent cause of DMARC failures. Check the d= value of the DKIM-Signature.
- Free header analyzer tools speed up reading but do not replace knowing how to interpret the raw headers.
- The most useful skill is mapping a deliverability symptom to the specific header section that diagnoses it.
Frequently Asked Questions
The headers appear above the message body in the raw format, but within the header block, the time ordering is bottom-up — the earliest Received line is at the bottom of the header block. This often confuses first-time readers.
Some header fields can be set freely by the sending mail server, including From:, Reply-To:, and most X-headers. Received headers and Authentication-Results headers added by mailbox providers cannot be faked by the sender — they are written by trusted infrastructure. The diagnostic value is in the headers added by the receiving side.
Neutral means the DKIM check did not produce a clear pass or fail — typically because there was no DKIM signature on the message at all, or the signature could not be verified because the public key could not be retrieved. Treat neutral the same as fail for diagnostic purposes.
Most sending platforms log the headers of sent mail in their delivery logs. For mail sent from a personal mailbox, the “Sent” folder retains the original message, and the same Show original / View source command will display headers.
X-headers added by trusted infrastructure (the recipient’s mail server, the corporate gateway) are reliable. X-headers added by the sender are not — they can contain anything. When diagnosing a delivery problem, focus on X-headers added by the receiving side.
Conclusion
Email headers are the closest thing email infrastructure has to a flight recorder. Every authentication check, routing decision, delay, and filtering action leaves a trace inside the header block. Once you understand how to read those traces, most deliverability problems stop being mysterious and start becoming diagnosable.
For senders managing deliverability seriously, learning header analysis is one of the highest-leverage technical skills available. Dashboards summarise trends, but headers explain individual events — why one message failed, why another landed in spam, or why a phishing attempt was blocked. The ability to interpret that information directly reduces dependency on guesswork and dramatically shortens troubleshooting time. Decode Email Problems With Headers
