Understanding Received Headers
Received headers form the email's journey log, showing which servers handled the message and when. Reading Received headers correctly allows you to trace email origin, identify spoofing, and understand the complete path from sender to recipient.
How Received Headers Work
Basic Received Header
Received: from mail.example.com ([192.0.2.1]) by mx.company.com with SMTP id abc123def for <[email protected]>; Wed, 15 Jan 2025 14:32:10 -0500
Breaking this down:
┌─ from mail.example.com ← Sending server hostname
├─ ([192.0.2.1]) ← Sending server's IP address
├─ by mx.company.com ← Receiving server (this one)
├─ with SMTP id abc123def ← Protocol (SMTP) and unique ID
├─ for <[email protected]> ← Recipient at this hop
└─ Wed, 15 Jan 2025 14:32:10 ← Timestamp of receipt
Real-World Example
Received: from smtp.gmail.com (smtp.gmail.com. [2607:f8b0:4864:20::c]) by mx.company.com with SMTP id 47h8ai23skd for <[email protected]>; Wed, 15 Jan 2025 14:32:10 -0500
Received: from google.com (unknown [2a00:1450:400d:811::20d]) by smtp.gmail.com with ESMTPS id d47tgx2vb1pf for <[email protected]> (version=TLSv1_2 cipher=AES128-GCM); Wed, 15 Jan 2025 14:32:05 -0500
Reading the Email Path
Critical Principle: Read Bottom to Top
The Received headers stack shows the path:
Bottom (Original sender): Received: from [sender's server]
↓
Received: from [first relay]
↓
Received: from [second relay]
↓
Top (Final recipient): Received: from [recipient's server]
Bottom = Start of journey
Top = End of journey
Complete Example with Path
Email sent from [email protected] to [email protected]
Header 1 (TOP - Final):
Received: from mx.company.com by mail.company.com with SMTP
↑ Company received it here
Header 2 (MIDDLE - Relay):
Received: from mail.relay.com by mx.company.com with SMTP
↑ Relay server passed it here
Header 3 (BOTTOM - Origin):
Received: from smtp.example.com ([192.0.2.1]) by mail.relay.com with SMTP
↑ Original sender's server ([email protected])
Path: [email protected] → relay → company.com
Interpreting Each Component
From (Sending Server)
Received: from smtp.gmail.com
What it shows:
- Hostname of server sending the message
- Can be FQDN or IP address
- May use reverse DNS
Verify:
- Is this a legitimate server for the claimed sender?
- Does hostname match sender's domain?
- Use whois/DNS to verify
IP Address in Brackets
Received: from smtp.gmail.com ([142.250.185.46])
What it shows:
- Actual IP address of sending server
- More reliable than hostname (can't be spoofed easily)
- May be IPv4 or IPv6
Verify:
- Lookup IP geolocation
- Check if IP matches sender's domain
- Use IP reputation tools
- Does IP belong to legitimate email service?
By (Receiving Server)
Received: by mx.company.com
What it shows:
- Hostname of server that received the message
- This server's name/identity
Verify:
- Is this the expected next hop?
- Does server belong to company in message?
With (Protocol and ID)
Received: with SMTP id 47h8ai23skd
What it shows:
- SMTP: Simple Mail Transfer Protocol (standard)
- ESMTP: Extended SMTP (more features)
- ESMTPS: ESMTP with TLS encryption
- ID: Unique identifier for this transaction
Key protocols:
- SMTP: Unencrypted (older, less secure)
- ESMTPS: Encrypted (more secure)
- LMTP: Local Mail Transfer Protocol
For (Recipient at This Hop)
Received: for <[email protected]>
What it shows:
- Who was the intended recipient at this hop
- May differ if mailing list involved
- Last "for" shows final recipient
Timestamp
Wed, 15 Jan 2025 14:32:10 -0500
What it shows:
- When this server received the message
- Timezone offset (-0500 = EST)
Verify:
- Is timestamp sequence logical?
- Each Received should have earlier timestamp than next
- Huge time gaps might indicate re-sending or issues
Reading Multiple Received Headers
Complete Example with Analysis
Email from: [email protected]
To: [email protected]
Subject: Important update
Headers (BOTTOM TO TOP):
3. (TOP)
Received: from mail.company.com by mx.company.com
with SMTP id abc123; Wed, 15 Jan 14:32:20 -0500
Analysis: Company's mail server received it
2. (MIDDLE)
Received: from mail.gmail.com by mail.company.com
with ESMTPS id def456; Wed, 15 Jan 14:32:15 -0500
Analysis: Gmail relayed it to company server
1. (BOTTOM - ORIGINAL)
Received: from smtp.example.com ([192.0.2.1])
by mail.gmail.com with ESMTP id ghi789
for <[email protected]>; Wed, 15 Jan 14:32:05 -0500
Analysis: John's company's server sent it
Path traced:
example.com (john sends) → gmail.com (relayed) → company.com (alice receives)
Spotting Suspicious Patterns
Red Flag 1: Missing Received Headers
Only one Received header (top only)
Concern: Either:
- Email created locally (forwarded internally)
- Headers removed (suspicious)
- Spoofed/forged headers
Verify: Is this expected for this type of email?
Red Flag 2: Hostname/IP Mismatch
Received: from gmail.com ([192.0.2.99])
Concern:
- Gmail's actual IPs are in 2607:f8b0:* range
- 192.0.2.99 is not Google's
- This is SPOOFED
Action: Treat as spoofed email
Red Flag 3: Reverse DNS Failure
Received: from unknown ([192.0.2.50])
Concern:
- Hostname "unknown" indicates reverse DNS failed
- IP address doesn't have reverse DNS
- Suspicious servers often lack proper reverse DNS
Action: Investigate IP, check reputation
Red Flag 4: Private IP Addresses
Received: from localhost ([127.0.0.1])
Concern:
- 127.0.0.1 = localhost (local machine)
- 192.168.*.* = private network
- Should never appear in received headers for external mail
Action: Email is forged/spoofed
Red Flag 5: Time Sequence Issues
Received 1: Wed, 15 Jan 14:32:20 (received at 14:32:20)
Received 2: Wed, 15 Jan 14:32:15 (received at 14:32:15)
Received 3: Wed, 15 Jan 14:32:10 (received at 14:32:10)
Issue: Times go backwards!
Should be: 14:32:10 → 14:32:15 → 14:32:20 (increasing)
Suspicious: Could indicate spoofed/manipulated headers
Red Flag 6: Server Chain Doesn't Match Sender
From: [email protected] (claims)
Received: from attacker.net ([192.0.2.99])
by relay.com with SMTP
Reality: Email came from attacker.net, NOT example.com
Action: SPOOFED EMAIL - Do not trust sender identity
Checking Server Legitimacy
Verifying Gmail Emails
Legitimate Gmail IP ranges:
Gmail sending IPs are in ranges:
- 2607:f8b0::/32 (IPv6)
- 142.250.0.0/15 (IPv4)
- Other Google IP ranges
Check:
- gmail.com server? ✓
- IP in Google's range? ✓
- Hostname matches Gmail? ✓
→ Likely legitimate
If:
- Hostname says "gmail.com" but IP is 192.0.2.1?
→ SPOOFED
Verifying Office 365 Emails
Legitimate Microsoft IP ranges:
Office 365 uses:
- outlook.office365.com
- mail.outlook.com
- protection.outlook.com
Check:
- Server in outlook.office365.com? ✓
- IP in Microsoft's range? ✓
→ Likely legitimate
Unknown Companies
For unknown senders:
1. Extract IP from Received header
2. Lookup IP ownership: whois command
3. Check if IP matches claimed company
4. Verify with company's actual mail servers
5. Check email reputation databases
Tools for Header Analysis
Online Tools
Inventive HQ Email Header Analyzer:
- Paste headers
- Visual parsing
- Path diagram
- Red flag detection
Google Admin Toolbox:
- Free header analysis
- Shows path clearly
- Identifies SPF/DKIM/DMARC results
MXToolbox:
- Header analyzer
- IP reputation check
- Reverse DNS lookup
Command Line
# Extract all Received headers
grep "^Received:" email.eml | tac # tac reverses order (bottom to top)
# Check specific IP
whois 192.0.2.1
# Reverse DNS lookup
nslookup -x 192.0.2.1
# IP geolocation
curl -s "http://ip-api.com/json/192.0.2.1"
Step-by-Step Header Reading Process
For Suspicious Emails
Step 1: Get the headers
- View full headers in email client
- Copy all text
Step 2: Read from bottom up
- Find the original Received header (bottom)
- Note the "from" server and IP
Step 3: Verify the IP
- Look up IP ownership
- Check if IP belongs to claimed sender's company
- If different company? Suspicious!
Step 4: Check authentication
- Look for Authentication-Results header
- SPF result (pass/fail)
- DKIM result (pass/fail)
- DMARC result (pass/fail)
Step 5: Verify the path
- Read each Received bottom to top
- Verify each step makes sense
- Check for anomalies or breaks
Step 6: Make decision
- All checks pass? Likely legitimate
- Red flags found? Likely spoofed
- Uncertain? Verify with sender by other means
Common Legitimate Variations
Forwarded Emails
Original:
Received: from sender.com (original sender)
Forward (new Received added):
Received: from forwarder.com (forwarder)
Received: from sender.com (original, moved down)
Legitimate:
- Has original Received
- Plus new Received from forwarder
- Multiple Received headers normal for forwards
Mailing Lists
Mailing list processing:
Received: from list.example.com (mailing list server)
for <[email protected]>
Received: from actual-sender.com (original sender)
Legitimate:
- List server receives original
- List server forwards to subscribers
- Both Received headers present
BCC Recipients
Received headers same as original
No indication email was BCC'd
All recipients see same path
Legitimate:
- BCC doesn't change Received headers
- Recipients see same information
Real-World Scenarios
Scenario 1: Legitimate Corporate Email
From: [email protected]
Claims: Urgent wire transfer needed
Check headers:
Received: from mail.company.com ([203.0.113.10])
Step 1: Is 203.0.113.10 company's IP?
✓ Yes, matches company website
Step 2: Check reverse DNS
203.0.113.10 → mail.company.com ✓
Step 3: Check authentication
spf=pass, dkim=pass, dmarc=pass ✓
Step 4: Pattern matches legitimate email
✓ From company's own server
Verdict: LIKELY LEGITIMATE
But: Always verify urgent requests separately!
Scenario 2: Phishing Attempt
From: [email protected]
Claims: Verify your account
Check headers:
Received: from attacker.com ([192.0.2.99])
Step 1: Is 192.0.2.99 Amazon's server?
✗ No, doesn't match Amazon's IPs
Step 2: Check reverse DNS
192.0.2.99 → unknown or attacker.com ✗
Step 3: Check authentication
spf=fail, dkim=fail, dmarc=fail ✗
Step 4: Pattern matches phishing
✗ From attacker's server, not Amazon
Verdict: PHISHING - DO NOT CLICK LINKS
Conclusion
Reading and interpreting Received headers is a critical skill for email security. By understanding:
- How to read headers from bottom to top
- What each component means
- How to verify server legitimacy
- What red flags indicate spoofing
You can effectively distinguish legitimate emails from phishing and spoofing attempts, even when the From address appears legitimate.
The Received headers show the truth about where an email actually came from, regardless of what the From address claims. Master this skill and you'll dramatically improve your ability to detect and prevent email fraud.
