Source: https://once-email.com/blog/read-received-headers Delivery and authentication · Aug 3, 2026Updated Aug 3, 2026 # How to Read Received Headers and Trace an Email Delivery Path Follow Received header fields in the correct order, compare timestamps safely and recognise the limits of hostnames, IP addresses and untrusted trace data. [Once Email Engineering, Once Email author Once Email Engineering]() Reviewed by Once Email technical review What this guide helps you do Readers can build a timestamped delivery path, spot plausible delay points and describe the limits of hostnames, addresses and unsynchronised clocks. Article guide Why this article is worth your time **Original analysis** The trace method reads hops from the trusted receiving boundary backward and separates observed relay evidence from lines an untrusted sender could fabricate. **Trend context** Cloud relays, filtering gateways and privacy proxies add more hops and rewriting, but each trusted receiver prepending its own trace remains the useful anchor. **Practical value** Readers can build a timestamped delivery path, spot plausible delay points and describe the limits of hostnames, addresses and unsynchronised clocks. 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 ; 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. ## Related guides Verification Email Not Arriving? A Safe Troubleshooting Checklist Work through address mistakes, sender delays, retries, filtering and mailbox limits without repeatedly requesting codes or weakening account security. [Verification Email Not Arriving? A Safe Troubleshooting Checklist]() How to Read SPF, DKIM and DMARC Results in an Email Header Understand what SPF, DKIM and DMARC authenticate, why alignment matters, and why a pass result is useful evidence rather than proof that a message is safe. [How to Read SPF, DKIM and DMARC Results in an Email Header]() Postfix vs Dovecot: Different Roles in a Receiving Email Server See where Postfix and Dovecot sit in the inbound mail path, what each service owns, how LMTP connects them, and which evidence to check when delivery fails. [Postfix vs Dovecot: Different Roles in a Receiving Email Server]() ## Use a related tool Email header analyzer Explain delivery hops and summarize SPF, DKIM and DMARC evidence without claiming absolute authenticity. [Email header analyzer]() [Why Some Websites Reject Disposable Email Addresses Understand the account-recovery, abuse, support and risk reasons behind disposable-email restrictions—and what legitimate users should do instead of evading them.]() [A Safe Checklist Before Downloading an Email Attachment Check the request, sender, file name, type and handling environment before downloading an attachment—and know what email previews and scanners cannot prove.]()