A support engineer spent two days trying to figure out why emails from a specific client were arriving 6 hours late. The client swore they sent them immediately. The recipient swore they arrived hours later. Everyone blamed everyone else's email system.
The answer was in the headers. Reading through the Received headers revealed the message sat in a queue at an intermediate relay server for 5 hours and 47 minutes. The relay was a legacy system the client had forgotten existed, misconfigured and struggling under load. Ten minutes of header analysis solved a two-day mystery.
Email headers are the flight recorder of every message. They document the complete journey from sender to recipient, every server touched, every check performed. Learning to read them is one of the most valuable debugging skills in email.
The structure of email headers
Email headers appear at the beginning of every message, before the body content. They're a series of field-value pairs, each on its own line, following a simple format: "Field-Name: field value".
Headers serve multiple purposes. Some identify the message: From, To, Subject, Date, Message-ID. Some record the delivery path: Received headers from each server. Some document security checks: Authentication-Results, DKIM-Signature. Some control behavior: Reply-To, List-Unsubscribe.
The order of headers matters for some purposes. Received headers are added in reverse chronological order—the most recent at the top, the original at the bottom. Reading them from bottom to top traces the message's journey forward through time.
Most email clients hide headers by default, showing only From, To, Subject, and Date. To see full headers, you need to access "view source," "show original," or similar options depending on your email client.
Received headers: the delivery trail
Every mail server that handles a message adds a Received header documenting its involvement. These headers create an audit trail of the message's complete path.
A typical Received header contains several pieces of information: the server that received the message (the one adding the header), the server it received it from, the protocol used (SMTP, ESMTP, etc.), and a timestamp.
Reading from bottom to top, you can trace the message's journey. The bottom Received header shows the first server that handled the message after it left the sender's mail client. Each subsequent header shows the next hop. The top Received header shows the final delivery to the recipient's mailbox.
Timestamps in Received headers help identify delays. If there's a 3-hour gap between two consecutive headers, the message sat at that server for 3 hours. This pinpoints where delays occur.
The "from" and "by" fields identify servers. "From" shows where the message came from; "by" shows the server adding the header. Mismatches or suspicious entries can indicate forwarding, relaying, or potentially spoofing.
Authentication headers
Modern email includes headers documenting authentication checks. These tell you whether SPF, DKIM, and DMARC passed or failed.
The Authentication-Results header is added by receiving servers after performing authentication checks. It summarizes the results in a structured format: which checks were performed, whether they passed or failed, and relevant details like which domain was checked or which key was used.
A passing authentication result might show SPF pass with the IP address verified, DKIM pass with the signing domain, and DMARC pass with the policy applied. Failures include reason codes explaining what went wrong.
The DKIM-Signature header contains the actual cryptographic signature added by the sending server. It specifies the signing algorithm, the domain responsible, the selector for key lookup, which headers are signed, and the signature itself.
When debugging authentication failures, these headers tell you exactly what happened. "DKIM signature verification failed" in Authentication-Results, combined with examining the DKIM-Signature header, often reveals whether the signature was malformed, the key was missing, or the message was modified in transit.
Identifying the real sender
Several headers relate to sender identity, and understanding their differences matters for both debugging and security.
The From header is what recipients see—the display address in their email client. This is easily spoofed; anyone can put any address in the From header.
The Return-Path (or Envelope-From) is the address where bounces are sent. This is set during the SMTP transaction, not in the message headers, though it's often recorded in headers by receiving servers. SPF checks this address, not the From address.
The Sender header, when present, indicates who actually sent the message on behalf of the From address. It's used when someone sends email for another person, like an assistant sending on behalf of an executive.
Reply-To specifies where replies should go, which can differ from From. Legitimate uses include sending from a no-reply address while directing responses to a monitored inbox. Illegitimate uses include phishing emails that display a trusted From address but capture replies elsewhere.
For security analysis, compare these headers. Mismatches aren't always malicious—there are legitimate reasons for differences—but they warrant attention.
Timestamps and delays
Every Received header includes a timestamp. Comparing these timestamps reveals where messages spent time.
The Date header shows when the message was composed (according to the sender's clock). The first Received header timestamp shows when it entered the mail system. Subsequent timestamps show each hop. The final timestamp shows delivery.
Large gaps between consecutive Received headers indicate queuing. The message arrived at a server but wasn't immediately forwarded. This could be intentional (greylisting delays new senders) or problematic (overloaded server, network issues).
Timezone differences can confuse timestamp analysis. Headers might show times in different zones. Convert everything to a single timezone (UTC is conventional) before calculating intervals.
Clock skew between servers can create apparent anomalies—a message appearing to arrive before it was sent. Small discrepancies (seconds to minutes) are normal. Large discrepancies suggest misconfigured server clocks.
Spam and filtering headers
Many mail servers add headers indicating their spam assessment. These aren't standardized but follow common patterns.
X-Spam-Status typically shows whether the message was classified as spam and the score it received. X-Spam-Score shows just the numerical score. X-Spam-Flag is a simple yes/no indicator.
SpamAssassin, a common spam filter, adds detailed headers showing which rules triggered and their point values. This breakdown is invaluable for understanding why a message was filtered. "MISSING_SUBJECT: 2.5 points" tells you exactly what to fix.
Some servers add headers indicating which blacklists were checked and whether the sender appeared on any. This helps diagnose blacklist-related delivery problems.
Provider-specific headers vary. Gmail adds headers related to their categorization system. Microsoft adds headers about their filtering decisions. Learning to recognize these helps when debugging delivery to specific providers.
Practical header analysis
When debugging email problems, a systematic approach to header analysis helps.
Start with the Authentication-Results header. Did SPF, DKIM, and DMARC pass? If not, you've likely found your problem. The details explain what failed and why.
Next, trace the Received headers from bottom to top. Does the path make sense? Are there unexpected servers? Are there long delays between hops? Anomalies here often explain delivery problems.
Check for spam-related headers. Was the message scored as spam? Which rules triggered? This tells you what the receiving server didn't like about the message.
Verify sender headers are consistent. Does From match Return-Path domain (for DMARC alignment)? Is Reply-To pointing somewhere unexpected? Inconsistencies might explain filtering or might indicate spoofing.
Look at timestamps. When was the message sent? When was it delivered? Where did it spend time? Delays become visible in the timestamp trail.
Tools for header analysis
While you can read headers manually, tools make analysis faster and catch things you might miss.
Google's Message Header Analyzer (in Google Admin Toolbox) parses headers and presents them in a readable format, highlighting delays and authentication results.
MXToolbox's header analyzer similarly parses and formats headers, with additional context about what each field means.
Email clients' built-in tools vary in quality. Some just show raw headers; others provide basic parsing. For serious debugging, dedicated analysis tools are worth using.
For programmatic analysis, libraries exist in most languages to parse email headers. This enables automated monitoring and alerting based on header contents.
Frequently asked questions
Can email headers be forged?
Headers added by the sender (From, Subject, etc.) can be forged. Headers added by receiving servers (Received, Authentication-Results) are trustworthy because they're added after the message arrives. This is why authentication results from the receiving server matter.
Why do I see multiple Received headers?
Each server that handles the message adds its own Received header. A message passing through 5 servers will have 5 Received headers. This is normal and creates the audit trail that makes debugging possible.
How do I view headers in Gmail?
Open the message, click the three-dot menu in the upper right, and select 'Show original'. This displays the complete message source including all headers.
What does 'with ESMTPS' mean in Received headers?
It indicates the message was transferred using SMTP with TLS encryption (the S stands for Secure). 'ESMTP' without the S means unencrypted transfer. Modern email should show encrypted transfers between servers.