Tracing a delivery through Received headers

Checking TLS hop by hop#

The with clause shows whether each hop used TLS. ESMTPS and ESMTPSA indicate TLS; plain ESMTP or SMTP between organizations means that hop was unencrypted. Many servers also add a comment with the TLS version and cipher, such as (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384).

If you care about transport encryption, for example because you have deployed MTA-STS, Received headers on messages arriving at your domain are a quick way to spot senders still delivering without TLS.

What you can trust#

Received headers are only as trustworthy as the server that wrote them. The headers your own servers add are reliable. Headers added before the message reached your infrastructure were written by others and can be forged: a spammer can prepend fake Received lines to make a message look like it passed through respectable servers.

The trust boundary is the first Received header written by your own receiving server, the one whose by clause names your MX. The from clause in that header records the IP that actually connected to you, which cannot be faked at the TCP level. Everything below it is the sender's claim.

Other trace headers worth knowing#

Received headers are not the only trace information in a message:

• Return-Path is added by the final delivering server and records the envelope sender, which is the domain SPF was checked against.
• Authentication-Results records the SPF, DKIM and DMARC verdicts a receiver reached. Like Received, it is trustworthy only when added by your own server; receivers are expected to remove copies that claim to come from them.
• ARC headers, when present, record authentication results observed by intermediaries such as mailing lists and forwarders.
• X- headers added by filters and gateways often contain spam scores and policy decisions. They are not standardized, but they frequently explain why a message was quarantined.

Reading these together with the Received chain gives you the full story: the route, the timing and the authentication verdicts along the way.

Practical uses#

• Investigating delays: find the hop with the largest gap.
• Identifying the true origin: the connecting IP in your own MX's Received header is the source to check against SPF, blocklists and abuse reports.
• Confirming the path: verify that mail passed through the gateways and filters you expect, in the expected order.
• Supporting other admins: the id value lets another operator find the message in their logs quickly.
• Spotting forwarding: hops through an unexpected domain usually mean the recipient forwards mail, which explains SPF failures.

A quick extraction script#

import email, sys
from email.utils import parsedate_to_datetime

msg = email.message_from_binary_file(open(sys.argv[1], "rb"))
hops = msg.get_all("Received", [])[::-1]          # oldest first
prev = None
for h in hops:
    flat = " ".join(h.split())
    when = parsedate_to_datetime(flat.rsplit(";", 1)[-1].strip())
    gap = f"+{(when - prev).total_seconds():.0f}s" if prev else "origin"
    print(f"{when.isoformat()}  {gap:>8}  {flat[:110]}")
    prev = when

Checklist#

• Read Received headers from the bottom (oldest) to the top (newest).
• Normalize time zones before comparing timestamps.
• Look for the largest gap to locate delays.
• Check the with clause on each hop for TLS.
• Trust headers only from your own MX upward; treat earlier ones as claims.
• Note queue IDs when asking another administrator for help.

Key takeaways#

• Received headers are a hop-by-hop log of a message's path, newest first.
• Timestamps between hops reveal where delays occur, with time zones normalized and skew in mind.
• The with clause shows whether each hop used TLS.
• Only headers added by your own servers are trustworthy; earlier ones can be forged.