Why the From Address Cannot Be Trusted
When you receive an email claiming to be from your bank, your CEO, or a government agency, the displayed "From" address tells you almost nothing about where the email actually came from. The SMTP protocol, which governs email transmission, allows the sender to set the "From" field to any value they choose. This is by design, not a bug, and it is routinely exploited in phishing and business email compromise attacks.
To determine whether an email is genuinely from who it claims to be from, you need to look beyond the visible message and into the email headers, the metadata that records the message's journey from sender to your inbox.
How to Access Email Headers
Every email client provides a way to view the full headers:
- Gmail: Open the email, click the three-dot menu, select "Show original"
- Outlook (web): Open the email, click the three-dot menu, select "View message source"
- Outlook (desktop): Open the email, go to File > Properties, and read the "Internet headers" box
- Apple Mail: Open the email, go to View > Message > All Headers
- Thunderbird: Open the email, go to View > Message Source
The headers will appear as a block of structured text that initially looks overwhelming but follows a consistent, readable format once you know what to look for.
Key Headers to Examine
Received Headers (The Route Map)
The most important headers for tracing an email are the "Received" headers. Each mail server that handles the message adds a "Received" header to the top, creating a chronological trail from bottom to top. The bottom-most "Received" header shows the originating server, and each subsequent header shows the next hop in the delivery chain.
What to look for:
- The originating IP address in the bottom "Received" header. You can look up this IP using WHOIS or geolocation tools to determine the sending network.
- Consistency of server names. If an email claims to be from a major bank but the originating server is a residential IP address or an unrelated hosting provider, that is a strong indicator of fraud.
- Time stamps. The timestamps in "Received" headers should progress logically from bottom to top. Significant gaps or backwards timestamps suggest manipulation.
Authentication Results
Modern email authentication relies on three complementary systems:
SPF (Sender Policy Framework): Verifies that the sending server's IP address is authorized to send email for the claimed domain. Look for spf=pass or spf=fail in the authentication results.
DKIM (DomainKeys Identified Mail): Verifies that the email has not been modified in transit by checking a cryptographic signature against the sending domain's public key. Look for dkim=pass or dkim=fail.
DMARC (Domain-based Message Authentication, Reporting, and Conformance): Coordinates SPF and DKIM results and tells receiving servers what to do when authentication fails. Look for dmarc=pass or dmarc=fail.
A legitimate email from a major organization should pass all three. If any of these checks fail, the email should be treated with heightened suspicion.
Return-Path
The Return-Path header (also called "envelope from") indicates where bounce messages should be delivered. In legitimate email, this typically matches or is closely related to the "From" address. A Return-Path pointing to a completely different domain is a red flag.
Message-ID
Every email should have a unique Message-ID. The domain in the Message-ID typically reflects the actual sending system. If an email claims to be from microsoft.com but the Message-ID contains a random domain, that discrepancy warrants investigation.
X-Originating-IP
Some mail systems add this header, which records the IP address of the client that submitted the email. This can identify the actual sender even when other headers have been manipulated.
Practical Analysis Walkthrough
When analyzing a suspicious email, follow this process:
- Read the Received headers from bottom to top to trace the delivery path
- Identify the originating IP address and look it up using a WHOIS service
- Check SPF, DKIM, and DMARC results in the authentication headers
- Compare the Return-Path domain to the displayed From address
- Examine the Message-ID domain for consistency
- Look for anomalies such as unusual server names, residential IP addresses for corporate senders, or geographic inconsistencies
Tools for Header Analysis
Several free tools can parse raw email headers into a readable format:
- Google Admin Toolbox Message Header Analyzer parses headers and highlights delivery delays
- MXToolbox Header Analyzer provides a visual timeline of the email's journey
- Mail Header Analyzer (various online tools) formats headers into readable tables
These tools do not require technical expertise and can quickly surface the most relevant information from a block of raw headers.
Common Red Flags
- SPF, DKIM, or DMARC failures for an email claiming to be from a large organization
- Originating IP address in a different country than the claimed sender
- Return-Path domain that does not match the From domain
- Missing or incomplete authentication headers from providers that normally include them
- Recently registered domains visible in the sending infrastructure
- Multiple unexpected relay servers in the delivery chain
Limitations of Header Analysis
Email headers can be partially forged. Specifically, everything below the first "Received" header added by your mail provider's server could have been fabricated by the sender. The headers added by your own provider's infrastructure are trustworthy because they record what that server actually observed.
For this reason, authentication results computed by your provider (SPF, DKIM, DMARC) are more reliable than the raw "Received" headers from earlier hops.
Understanding how to read email headers gives you a powerful tool for evaluating suspicious messages. Combine this skill with ongoing monitoring of your email exposure. Check LeakedSource to see whether your email address has been exposed in breaches that could make you a target for phishing campaigns.