How to Read Received Headers and Trace an Email Delivery Path

An email can pass through an application server, an outbound relay, a filtering service and the recipient's mail exchanger before it reaches an inbox. Each receiving SMTP server normally adds a Received field. Reading those fields can help locate a delay, identify the server that handed mail to your provider and build a delivery timeline.

The fields are diagnostic evidence, not a complete chain of custody. A sender can add fake lines before transmission, clocks can disagree and private infrastructure may hide or rewrite details. Use the trace together with provider logs, authentication results and the context of the message.

What a Received field records

RFC 5321 section 4.4 requires an SMTP server that receives a message for delivery or further processing to prepend trace information. A typical field looks like this:

Received: from outbound.example.com (outbound.example.com [192.0.2.10])
        by mx.example.net with ESMTPS id ABC123
        for <[email protected]>;
        Mon, 03 Aug 2026 10:30:04 +0000

Common clauses answer different questions:

• from describes the host presented by the sending side and may include the address observed on the network connection;
• by identifies the server that accepted this hop and wrote the field;
• with describes the transport or protocol variant, such as ESMTP or encrypted SMTP;
• id is a queue or transaction identifier useful when an administrator can search that server's logs;
• for may identify one envelope recipient, although it is optional and can be removed for privacy;
• the date after the semicolon records when the receiving server accepted the message, including a numeric time-zone offset.

Not every field contains every clause. Gateways and non-SMTP systems can produce unfamiliar formats. RFC 5321 explicitly tells receiving systems to be robust with unexpected trace formatting rather than rejecting a message merely because a trace line looks unusual.

Read the route from the bottom upward

SMTP servers prepend new Received fields above the existing ones. The newest receiving hop is therefore at the top of the header block; the earliest recorded hop is usually at the bottom.

Consider this simplified trace:

Received: from filter.example.net by mx.recipient.example;
        Mon, 03 Aug 2026 10:30:07 +0000
Received: from outbound.sender.example by filter.example.net;
        Mon, 03 Aug 2026 10:30:04 +0000
Received: from app.internal.example by outbound.sender.example;
        Mon, 03 Aug 2026 10:29:59 +0000

Read it as:

1. app.internal.example handed the message to outbound.sender.example.
2. The outbound server handed it to filter.example.net.
3. The filter handed it to the recipient's mx.recipient.example server.

Do not sort the fields by their visible timestamps. The protocol-defined field order is more useful because server clocks may be wrong or unsynchronised. Convert each timestamp to one time zone only when estimating delay, and preserve the original value in any evidence record.

Calculate delay carefully

For each adjacent pair, subtract the earlier receiving time from the later one after applying the numeric offsets. A large positive gap can indicate queueing, rate limiting, a temporary network failure or processing at the next service. It does not identify the cause by itself.

A negative gap usually points to clock skew, a parsing mistake or an untrusted field—not time travel and not automatic proof of forgery. Check whether the offsets were handled correctly and whether the two lines were written by systems you control.

When investigating your own application, correlate the trace with:

• the UTC time at which the application requested the message;
• the sender's queue ID and delivery log;
• the first Received field written by infrastructure you trust;
• the time the recipient provider reports accepting or displaying it;
• any retry status or SMTP response recorded by the sending system.

The developer email testing checklist explains how to record the request-to-arrival timeline without treating one inbox observation as the whole delivery system.

Decide which hop you can trust

The topmost Received field was added by the server closest to the mailbox you are viewing. If that mailbox provider is trusted, this field is usually the strongest starting point: it can report the network address from which the provider actually accepted the message.

Work downward only as far as the fields remain consistent with infrastructure you recognise. Lines allegedly created before the message entered a trusted provider can be fabricated by the sender. A malicious sender cannot normally rewrite fields already added later by the recipient's systems, but it can place plausible-looking trace text in the message before those systems see it.

Hostnames also require context. A from name may come from an SMTP greeting, reverse DNS or local configuration. A private address such as 10.0.0.0/8 can describe an internal hop but cannot be traced directly across the public Internet. An IP geolocation result is approximate and does not establish the identity or physical location of the author.

Received fields do not replace authentication

Received fields describe transport hops. SPF, DKIM and DMARC evaluate different evidence about domain authorisation, signatures and alignment. A route that looks ordinary can carry a malicious message, and a legitimate forwarded message can have a complicated route.

Use the SPF, DKIM and DMARC guide to interpret authentication results separately. Do not infer that the visible From address controlled every host in the route, or that a familiar relay makes the content safe.

Use the local header analyser without oversharing

The Once Email email header analyser extracts Received hops, authentication results and repeated fields in the browser. Paste header fields only—never a password, verification code, message body or attachment. The tool does not contact the listed servers, verify their logs or prove that a field is genuine.

Before sharing results, replace personal addresses, public IP addresses, queue IDs and internal hostnames while retaining the order and time offsets needed to reproduce the issue. The test evidence redaction guide provides a safer reporting pattern.

A reliable interpretation checklist

Start at the top to identify the final receiving system, then reconstruct the path from the bottom upward. Trust the field order before the clocks. Normalise time zones, flag negative or unusually long intervals, and mark the boundary between trusted and sender-controlled infrastructure. Correlate queue IDs with authorised server logs when available.

Most importantly, state the limit of the conclusion. A trace may support “the recipient provider accepted this connection from this relay at this time.” It usually cannot prove who wrote the message, whether every earlier hop is genuine or whether its links and attachments are safe.