Understanding Received Headers and SMTP Routing Hops

1. The Structure of a Received Header – Decoding Each Component

The Received header is the most critical header for understanding an email's journey. Each time an SMTP mail transfer agent (MTA) forwards an email, it prepends a Received header at the very top of the header stack, documenting the transaction.

The Complete Anatomy

Received: from mail.example.com (mail.example.com [192.0.2.45])
        by mx.google.com with ESMTPS id f1g2h3i4j5k6l7m8n9
        for ;
        Tue, 2 Jun 2026 10:30:05 -0400 (EDT)

Breaking Down Each Component

• "from mail.example.com": The hostname of the server that sent the email (as claimed by that server)
• "(mail.example.com [192.0.2.45])": The sending server's hostname and IP address as determined by the receiving server (this is the authoritative part)
• "by mx.google.com": The receiving server's hostname that's adding this header
• "with ESMTPS": The protocol used (ESMTP with TLS, ESMTP, SMTP, LMTP, etc.)
• "id f1g2h3i4j5k6l7m8n9": An identifier for the SMTP connection or queue ID
• "for ": The recipient address (not always present)
• "Tue, 2 Jun 2026 10:30:05 -0400 (EDT)": The timestamp when this hop occurred

The Protocol Field – What "with" Tells You

The protocol field reveals security information about the hop:

• SMTP: Standard, unencrypted SMTP (rare today)
• ESMTP: Extended SMTP (supports additional features)
• ESMTPS or ESMTPSA: ESMTP with TLS encryption (ESMTPSA includes authentication)
• LMTP: Local Mail Transfer Protocol (for final delivery to mailbox)
• HTTP: Rare, sometimes used by webmail interfaces

The presence of "ESMTPS" indicates the connection was encrypted with TLS—a good security sign.

2. Tracing Hops from Bottom to Top – The Email's Journey in Reverse

Because each new Received header is added at the top, you must read Received headers from bottom to top to trace the email's actual path from sender to receiver.

The Golden Rule of Received Header Order

Oldest at the bottom, newest at the top. This is counterintuitive but consistent across all emails.

Step-by-Step Trace Example

Consider this header block (simplified):

Received: from mx.google.com (209.85.220.41) by outlook.com; 15:30:00
Received: from mail.example.com (192.0.2.45) by mx.google.com; 10:30:00
Received: from client-192-0-2-100.example.com (192.0.2.100) by mail.example.com; 10:28:00
Received: from [192.168.1.50] by client-192-0-2-100.example.com; 10:27:30

Tracing from bottom (oldest) to top (newest):

1. Bottom: [192.168.1.50] → client-192-0-2-100.example.com (sender's email client to their ISP's outbound server)
2. Second from bottom: 192.0.2.100 → mail.example.com (ISP's outbound to sender's mail server)
3. Third from bottom: 192.0.2.45 → mx.google.com (sender's mail server to Google's inbound)
4. Top: 209.85.220.41 → outlook.com (Google forwarding to the final recipient at Outlook.com)

Visualizing the Journey

For complex paths, draw a diagram:

Sender Client (192.168.1.50)
    ↓
ISP Outgoing (192.0.2.100)
    ↓
Sender's Mail Server (192.0.2.45)
    ↓
Google Inbound (mx.google.com / 209.85.220.41)
    ↓
Final Recipient (Outlook.com)

3. Understanding Different Hop Types – What Each Jump Represents

Different types of hops reveal different things about email infrastructure and potential issues.

Client to Submission Server (MUA to MSA)

This first hop is from the sender's email client (Outlook, Apple Mail, Gmail web) to their outgoing mail server. Look for:

• Client IP: Often a residential or business IP address, sometimes from a VPN
• Authentication: Usually includes "with ESMTPSA" (authenticated)
• Port indicators: Port 587 (submission) or 465 (SMTPS) are standard

Received: from [192.168.1.50] (user-192-0-2-100.example.com [192.0.2.100]) by mail.example.com with ESMTPSA id abc123; ...

Relay to Relay (MTA to MTA)

Hops between mail servers as the email traverses the internet toward its destination:

• Typically use standard SMTP/ESMTP ports (25)
• Often pass through multiple relays, especially for large providers
• Each hop adds some latency (usually milliseconds to seconds)

Inbound Gateway to Final Delivery (MDA)

The last hop before delivery to the recipient's mailbox:

• Often uses LMTP instead of SMTP
• May involve spam/virus scanning that adds latency
• The receiving server's name often indicates the email provider

Internal Relays Within Organizations

Large organizations often have multiple internal mail relays:

• Edge gateway – First point of contact from the internet
• Spam/virus filter appliances (e.g., Barracuda, Proofpoint)
• Internal exchange servers – Route to the correct mailbox database
• Mailbox store – Delivers to individual user folders

4. Detecting Latency and Delivery Delays – Finding the Bottlenecks

When recipients complain about delayed email, Received headers tell you exactly where the bottleneck occurred.

Calculating Hop-by-Hop Delays

Subtract the timestamp of a lower Received header from the timestamp of the header above it to calculate how long the email spent at that hop.

Example Delay Analysis

Received: from mx.google.com (209.85.220.41) by outlook.com; 15:30:00
Received: from mail.example.com (192.0.2.45) by mx.google.com; 10:30:00
Received: from localhost (127.0.0.1) by mail.example.com; 10:28:00

• Hop 1 (client to mail.example.com): 10:28:00 to 10:30:00 = 2 minutes
• Hop 2 (mail.example.com to Google): 10:30:00 to 15:30:00 = 5 HOURS (problem!)
• Hop 3 (Google to Outlook): 15:30:00 to 15:30:00 = 0 minutes

The 5-hour delay occurred between mail.example.com and Google. The sender should investigate why Google held their message.

Common Delay Causes by Time Length

• Seconds to a few minutes: Normal processing, routing, or greylisting (new sender relationship)
• 5-30 minutes: Queue congestion, rate limiting, or content scanning
• 1-4 hours: Throttling due to reputation issues or large attachments
• 4-24 hours: Significant queue backlog or intentional deferral
• 24+ hours: Mail server problems, blacklisting, or permanent failure pending

Time Zone Awareness

Email timestamps include timezone offsets (e.g., -0400 for EDT, +0000 for UTC). Always convert to a common timezone (UTC is best) before calculating differences.

5. Identifying the True Originating IP – Cutting Through the Noise

For security investigations and deliverability troubleshooting, identifying the true original sender IP is often essential.

The Bottom-Most Received Header

In most legitimate emails, the bottom-most Received header contains the true originating IP address of the sender's email client or first-hop server.

Types of Origin Indicators

• RFC 1918 private addresses (10.x.x.x, 172.16-31.x.x, 192.168.x.x): The sender is behind NAT on a local network. The next Received header likely shows their public IP.
• Residential IP ranges: The sender is using a home internet connection (common for personal email).
• Business IP ranges: The sender is using a corporate internet connection.
• Cloud provider IPs (AWS, Azure, GCP): The email originates from cloud infrastructure (common for legitimate business email).

When Spammers Forge the Bottom Header

Sophisticated spammers sometimes forge the bottom Received header to hide their true origin. Look for:

• Implausible hostnames (e.g., "localhost" or "mail.google.com" from non-Google IPs)
• Mismatches between claimed hostname and IP in parentheses
• Missing reverse DNS or generic PTR records

Using Multiple Headers for Verification

Cross-reference multiple headers to verify origin. If the bottom two Received headers both show the same IP in their parentheses, that's almost certainly the true origin.

6. Identifying Forged or Suspicious Headers – Spotting Manipulation

Spammers and phishers often forge Received headers to hide their tracks. Knowing how to spot forged headers is a critical security skill.

Common Forgery Techniques

Adding Fake Received Headers

Spammers sometimes add fake Received headers to make an email look like it passed through legitimate servers:

Received: from mail.google.com (209.85.220.41) by mail.example.com; (FAKE – Google didn't send this)
Received: from real-spam-server (203.0.113.88) by mail.example.com; (REAL first hop)

Detection: Check that timestamps are sequential and that the receiving server in the fake header actually exists and sent the email to the next hop.

Mismatched Hostnames and IPs

The hostname before the parentheses and the IP inside the parentheses should match (or be closely related). Discrepancies indicate forgery:

Received: from mail.google.com (phishing-server.ru [203.0.113.88]) ...

The hostname claims to be google.com, but the IP resolves to a different domain—obvious forgery.

Missing or Impossible Timestamps

Timestamps that are in the future, far in the past, or out of order suggest manipulation.

Trust Chain Verification

For security-critical investigations, verify each hop's trust chain:

1. Can the receiving server in header X plausibly have sent to the server in header Y?
2. Do the timestamps flow logically (increasing from bottom to top)?
3. Do the IPs in parentheses match known infrastructure of the claimed hostnames?
4. If the email passed authentication (SPF/DKIM/DMARC), the sending domain has vouched for the IP path.

7. MTA-STS, TLS, and Secure Routing Indicators – Modern Email Security

Modern email routing includes security features that appear in Received headers and indicate encrypted, authenticated transmission.

TLS Indicators in Received Headers

Look for "ESMTPS" in the with clause—this indicates the hop used TLS encryption:

Received: from mail.example.com (192.0.2.45) by mx.google.com with ESMTPS id ...

Additional TLS details may appear in separate headers:

Received-SPF: pass (google.com: domain of example.com designates 192.0.2.45 as permitted sender)
TLS-Required: Yes
TLS-Version: TLSv1.3
TLS-Cipher: TLS_AES_256_GCM_SHA384

MTA-STS (SMTP MTA Strict Transport Security)

MTA-STS forces TLS encryption for email to specific domains. Headers may indicate MTA-STS enforcement:

X-MTA-STS-Status: enforced
X-MTA-STS-Policy: version="STSv1.1"; mode="enforce"; mx:*.example.com;

DANE (DNS-Based Authentication of Named Entities)

DANE uses DNSSEC to publish which TLS certificates are valid for a mail server. Headers may show DANE validation status.

Why This Matters

End-to-end TLS encryption (all hops using ESMTPS) means your email wasn't readable in transit by any intermediate network. This is increasingly expected for sensitive communications.

8. What Hop Counts Tell You – Normal vs. Abnormal Routing

The number of Received headers (hops) in an email reveals a lot about its journey and legitimacy.

Normal Hop Counts by Sender Type

• Direct send (small business/personal): 3-5 hops
• Email service provider (SendGrid, Mailchimp): 4-7 hops
• Large provider (Google, Microsoft): 5-10 hops (internal relays)
• Forwarded email (through multiple forwards): 8-15+ hops

Abnormal Hop Patterns

• 1-2 hops only: Likely spoofed or sent via local script (rare legitimate)
• 15+ hops: Email may have been forwarded many times or routed inefficiently
• Hops from unrelated organizations: Email passing through servers in different countries, industries, or affiliations warrants scrutiny

Hop Counting as a Spam Signal

Spam filters analyze hop counts. Unusually low hop counts can indicate direct-to-MX spamming. Unusually high hop counts can indicate compromised chains or excessive forwarding.

9. Real-World Routing Analysis Examples – Putting Knowledge into Practice

Example 1: Normal Business Email via Google Workspace

Received: from mail-il1-f170.google.com (209.85.166.170) by outlook.com; 10:32:15
Received: from mail-sor-f65.google.com (209.85.220.65) by mail-il1-f170.google.com; 10:32:12
Received: from mail-ed1-f43.google.com (209.85.208.43) by mail-sor-f65.google.com; 10:32:10
Received: from user-laptop (user-192-0-2-100.example.com [192.0.2.100]) by smtp.gmail.com with ESMTPSA; 10:30:00

Analysis: 4 hops. All Google infrastructure. ESMTPSA shows authentication and TLS. Sender client at 192.0.2.100. Normal, legitimate email.

Example 2: Marketing Email via SendGrid

Received: from mx.google.com (209.85.220.41) by outlook.com; 14:20:00
Received: from o1.sendgrid.net (167.89.18.45) by mx.google.com with ESMTPS; 14:19:55
Received: from mail.example.com (192.0.2.200) by o1.sendgrid.net with ESMTPSA; 14:18:00

Analysis: 3 hops. SendGrid as intermediate relay. TLS at all hops. Standard for ESP-sent marketing email.

Example 3: Delayed Forwarded Email

Received: from forwarder.example.net (203.0.113.50) by gmail.com; Wed, 3 Jun 2026 09:00:00
Received: from mailing-list.example.org (198.51.100.75) by forwarder.example.net; Tue, 2 Jun 2026 10:30:00
Received: from original-sender.com (192.0.2.45) by mailing-list.example.org; Tue, 2 Jun 2026 10:28:00

Analysis: 3 hops, but note the date change—original email sent on June 2 at 10:28 but not delivered until June 3 at 09:00. The 22.5-hour delay occurred at forwarder.example.net (between 10:30 and next day 09:00). Forwarder likely had queue issues.

Example 4: Suspicious Path

Received: from mx.google.com (209.85.220.41) by recipient.com; 10:30:00
Received: from mail.ru (spam-server.ru [203.0.113.88]) by mx.google.com; 10:28:00
Received: from claimed-bank.com (spam-server.ru [203.0.113.88]) by mail.ru; 10:25:00

Analysis: The From header likely claims to be from a bank, but the routing shows servers in Russia, no authentication (no ESMTPSA), and the same IP appears twice. This is almost certainly spam or phishing.

10. Troubleshooting with Received Headers – A Systematic Approach

Problem: "My emails aren't being delivered"

1. Check the bottom-most Received header to confirm your server is sending
2. Look for any "Received" headers from your domain—if none exist, your server never sent the email
3. Check for bounce messages (NDRs) and examine their headers for failure reason

Problem: "Emails are delayed hours or days"

1. Calculate hop-by-hop delays as shown in Section 4
2. Identify which hop has the largest timestamp gap
3. Investigate that specific server—was it down? Overloaded? Rate limiting?
4. Check if the delaying server is greylisting (new sending relationship)

Problem: "Gmail/Outlook flagged my email as spam"

1. Check Authentication-Results for SPF/DKIM/DMARC failures
2. Look for spam-specific headers like X-Spam-Status, X-Google-Spam-Score
3. Examine Received headers for suspicious routing (foreign countries, open relays)
4. Ensure all hops used TLS (ESMTPS)—lack of encryption can trigger spam filters

Problem: "I think someone is spoofing my domain"

1. Examine Received headers on suspicious emails claiming to be from your domain
2. Check the bottom-most Received header to find the true originating IP
3. Look up that IP in WHOIS to identify the hosting provider
4. File an abuse report with that provider
5. Implement DMARC with p=reject to prevent spoofing