Received header: how to read an email's routing path

The Received header is the trace record each mail server stamps onto a message as it passes through. Every MTA that handles the email prepends its own Received line at the top of the header block. Read those lines from bottom to top and you get the full routing path: timestamps, IP addresses, and protocol details at each hop.

Format of a Received header

RFC 5321 defines the general structure. A typical Received header looks like this:

The key clauses: from identifies the sending server (HELO/EHLO name and IP), by identifies the receiving server, with specifies the protocol (SMTP, ESMTP, ESMTPS for TLS), id is the internal queue ID, and the timestamp records when the handoff occurred.

Reading order: bottom to top

Each server prepends its line, so the lowest Received in the block is the first server that touched the message (usually the sender's MTA). The topmost is the last server before final delivery.

For a typical ESP-sent message, the chain looks like this:

1. The sender's MTA (the ESP) composes the message and passes it to its relay.
2. The ESP relay adds its Received line and forwards the message.
3. The recipient's MX server accepts the connection and adds its own Received line.
4. An internal delivery server (if present) places the message in the mailbox and adds the final Received line.

That gives you 3-4 Received headers for a normal delivery. Messages routed through a mailing list or forwarding can accumulate 6-8.

Diagnosing delays

Each Received contains a timestamp. The gap between adjacent timestamps shows how long the message sat at each stage. If 0.5 seconds elapsed between two servers but 45 minutes between the next pair, the delay was there.

Usual culprits: server queue backup, greylisting (first attempt rejected, retry succeeds after 5-15 minutes), DNS problems on the receiving side, or rate limiting by the mail provider.

Received headers and authentication

Received headers come with an Authentication-Results header that the receiving server adds next to the top Received. It records SPF, DKIM, and DMARC outcomes.

One caveat: Received headers added before your server can be forged. A sender can insert arbitrary lines to fake a routing history. Only the Received headers your own server and trusted servers added are reliable. Spam filters know this and evaluate only the "upper" records inside the recipient's infrastructure.

What the IP address tells you

The IP address in parentheses after the hostname is the actual TCP connection address. The hostname comes from the EHLO/HELO command and can be anything the sender sets. The IP is what the receiving socket sees and cannot be spoofed.

When analyzing Received headers, trust the IP over the hostname. From it you can check whether the server belongs to the claimed ESP, whether it appears in blocklists, and whether its PTR record matches the stated hostname.

TLS in Received: ESMTPS

The protocol in the with clause shows whether the connection was encrypted:

• SMTP — basic protocol, no extensions, no encryption.
• ESMTP — extended SMTP with EHLO support, but still no encryption.
• ESMTPS — ESMTP with TLS (STARTTLS or implicit TLS). This is what you want to see.
• ESMTPSA — ESMTP with TLS and authentication (SMTP AUTH), typical for submission on port 587.

A hop showing plain ESMTP transmitted in cleartext. For servers in the same datacenter that may be acceptable. Over the public internet, it is not.

Received headers and spam filters

Spam filters pull the IP of the first trusted hop and check it against DNSBL blocklists. An IP listed in Spamhaus or Barracuda means the message takes a scoring penalty before content analysis even starts.

Anomalies in the chain also trigger flags: an unusually long chain, timestamps that go backward, or forged internal Received lines all push the spam score up.

Reading example

Say you see three Received headers (top to bottom):

Reading bottom to top: the ESP application handed the message to its relay at 10:23:45, the relay delivered it to mx.gmail.com over TLS one second later, and Gmail's internal server placed it in the mailbox one second after that. Total delivery time: 2 seconds, no delays.