How to Read Email Headers: Routing and Authentication Results
Email headers contain metadata supplied by the sender's software and added by mail systems that handle the message, including identities, routing hops, dates, and reported authentication results.
How it works
A message begins with sender-controlled fields and gains trace and security fields as mail systems process it. Those fields do not all have equal evidentiary value: visible identities can be forged, and earlier-looking trace lines can come from an untrusted system. Headers added by receiving infrastructure you trust are generally more useful for interpreting the message path and authentication results.
Start with the visible message fields
From is the author identity normally shown by a mail application, while To identifies an intended recipient and Subject describes the message. Date is supplied by the sending side and can be inaccurate. These fields help establish what the message claims, but a visible From address alone does not prove who sent it.
Reply-To tells a mail client where replies should go when it differs from From. That difference can be intentional for support systems, mailing platforms, and delegated services, so it is an inconsistency to understand rather than automatic proof of phishing. Return-Path reflects the SMTP envelope return address recorded during delivery and can legitimately use a provider domain.
Message-ID is an identifier usually generated by the sending system. Its domain and format can add context, but neither uniqueness nor a familiar domain proves origin. Compare these fields with trusted routing and authentication evidence instead of judging any one label in isolation.
Trace the Received headers
Each mail server can prepend a Received field when it accepts or relays a message. The newest trusted hop therefore normally appears above earlier trusted hops in the displayed header. Investigators often work from the earliest hop added inside the recipient's trusted mail environment toward the final delivery, checking which server added each line.
Do not assume that every bottommost or earlier-looking Received line is true. A sender or untrusted relay can insert text before the message reaches trusted receiving infrastructure. Establish the recipient provider's trust boundary first, then use the sequence of trusted additions rather than applying a mechanical bottom-to-top rule.
For example, a trusted line might report that mx.example.net received a message from outbound.example.com at the documentation address 192.0.2.25. Later trusted lines can show internal gateways and delivery systems. Timestamps may use different time zones, clocks can differ, and relays or security services can make the route longer without indicating abuse.
Read SPF, DKIM, and DMARC results
A trusted receiving system may summarize checks in Authentication-Results with values such as spf=pass, dkim=pass, and dmarc=pass. Read the system that wrote the header and the associated domains, not only the three result words. Untrusted or duplicated Authentication-Results fields can otherwise create a misleading impression.
SPF pass reports that sending infrastructure was authorized in the evaluated SMTP and domain context. DKIM pass reports that a signature verified for its signing domain and covered content. DMARC pass reports that at least one qualifying SPF or DKIM path passed with the required alignment to the visible From domain.
These passes are useful authentication evidence, not a safety guarantee. Legitimate accounts can be compromised, authenticated domains can carry harmful content, and attackers can authenticate domains they control. Failures also need context because forwarding, mailing lists, relays, configuration errors, and message modification can affect results.
Put header evidence together
Begin with the visible From address, then note Return-Path and any different Reply-To. Identify the trusted receiving system, trace the Received path from its earliest trusted hop, and inspect the Authentication-Results it added. Record sending hosts, public IPs, timestamps, and domain relationships where they are available.
Look for evidence that supports or conflicts with the message's claims, but keep conclusions proportional. A sending IP may identify a shared provider or relay rather than the human sender, and IP geolocation does not identify a person. A gateway can rewrite or add fields, while forwarding and mailing-list software can change authentication outcomes.
The Email Header Analyzer unfolds continued lines, preserves Received hops, extracts visible IPs and selected identity fields, and reports SPF, DKIM, and DMARC values already present in the pasted headers. It does not independently authenticate the message, verify a DKIM signature, contact mail or DNS servers, or analyze the body and attachments.
Practical guidance
- Start with headers added by receiving infrastructure you trust before relying on sender-supplied identities or trace lines.
- Compare visible identities, the trusted Received path, and reported SPF, DKIM, and DMARC domains together.
- Treat mismatches, passes, failures, and extracted IPs as evidence to investigate rather than automatic proof of safety, abuse, or human identity.
Common question
Can email headers prove who sent a message? Not by themselves. Trusted trace and authentication evidence can describe handling and domain-level authentication, but it generally cannot establish the real-world identity of the person who pressed Send.