Reconstruct Routing and Sender Identities
Read Received fields from the first trusted mail boundary and compare visible, envelope, return, and signing identities.
In this lesson, you will learn to:
- Identify the portion of a header chain added by trusted infrastructure.
- Compare the visible From identity with SMTP, return-path, and signing identities.
Reconstruct Routing and Sender Identities
Teaches route reconstruction without trusting attacker-supplied header fields and shows why one message contains several legitimate sender identities.
Build the route from a trusted boundary
Mail transfer systems normally prepend Received fields as a message moves. Analysts often read those fields from the bottom upward to reconstruct the path, but the method is reliable only after identifying the first server the organization trusts. Text below that boundary may have been supplied before the message entered controlled infrastructure. Compare hostnames, IP addresses, protocol details, and timestamps across adjacent hops. Large time jumps, impossible ordering, or a private address presented as an Internet source are questions to resolve, not automatic proof of deception.
Use message trace data to corroborate the header. The platform can show the connector, delivery action, recipient, and internal processing that a copied header cannot independently prove. Forwarding, mailing lists, gateways, and security relays legitimately add hops and may rewrite envelope fields. Record the observed route, the trusted boundary, and any unresolved hop. Avoid geolocating an IP as a shortcut to attribution: hosting, relays, VPNs, and shared cloud infrastructure make location a weak identity signal.
Map each identity to the claim it makes
The user-visible From field is an author claim. The SMTP MAIL FROM identity, often reflected in Return-Path after delivery, is used for delivery-status handling and SPF evaluation. A DKIM signature names a signing domain. Reply-To can direct responses somewhere different. These identities may differ in legitimate delegated sending, but the differences are exactly what an analyst must explain.
Create a small identity table with the displayed name, RFC 5322 From address, Reply-To, MAIL FROM or Return-Path, DKIM d= domain, Message-ID domain, and the connecting IP observed at the trusted boundary. Compare domains by exact registrable domain and subdomain; do not rely on visual similarity. A familiar display name does not authenticate an address, and a matching Message-ID domain is not an authentication result. The useful question is whether the combination matches the organization’s expected sending pattern and the authenticated evidence in the next lesson.
Resources
- NIST SP 800-177 Rev. 1: Trustworthy Email — Consult the NIST guidance for the roles of SMTP, DNS, sender authentication, transport protection, and content security in trustworthy mail.