A message header can look like a wall of technical text, but its Received lines offer a practical clue: they record mail servers handling the message along its route. The order is easy to misread because the newest entry is usually placed above older ones. Reading the lines from top to bottom can help you trace the sequence backward, while careful interpretation keeps you from treating a header as proof of inbox delivery or sender identity. Here is a method for following the hops and deciding what to share if the route remains unclear.
The useful bits
- Read Received lines from the top downward: newest hop first, earlier hops below.
- Treat each line as a record made by the server that added it; older lines may not be independently trustworthy.
- For help, share the complete relevant header, not just one Received line.
Find the right part of the message
A message has ordinary content, such as its subject and body, and a header containing routing and delivery details. The header is often hidden in a mail app’s message details or original-message view. The exact label and steps vary by app, so look for an option that shows full headers or the original message source rather than relying on a shortened summary.
Once visible, locate every line beginning with “Received:”. A long header may wrap a line across the screen; wrapping does not necessarily mean there are multiple Received entries. Preserve the full text, including continuation lines, when copying it.
Read from the newest hop backward
Each mail server that accepts a message for onward handling can add a Received line. It normally adds its record at the top of the existing header. As a result, the first Received line is generally the most recent recorded hop, and lines below it describe earlier handling. Read top to bottom to move backward through the route.
A line may include a server that received the message, a server or system said to have sent it, a time, and sometimes an identifier or recipient detail. Not every line includes the same fields. Compare the neighboring lines for a plausible sequence: a receiving server in a newer entry may correspond to the sending system mentioned in an older one. Names and formatting can differ, so a mismatch is a clue to investigate, not a conclusion by itself.
- Start at the top and note the receiving server in each line.
- Move downward, comparing the earlier sender and later receiver where possible.
- Keep the original order; do not sort entries by the displayed dates.
Received: from inbound.example.com by mx.example.com; [newer recorded time] Received: from sender.example.com by inbound.example.com; [earlier recorded time]
Separate recorded hops from assumptions
A Received line is a server’s record of handling, not a universal certificate that every detail in the message is genuine. Earlier lines may have been supplied before a trusted server received the message and could be altered or fabricated. The records added within a mail provider’s trusted handling path are usually more useful than claims far earlier in the chain, but readers may not know where that trusted boundary begins.
Use the route as technical evidence to discuss a delivery question, not as a guarantee of who wrote the message, whether every hop is complete, or whether the message reached an inbox. A message can be accepted by a server and later filtered, routed elsewhere, delayed, or rejected at a different stage. The header alone may not tell you which outcome occurred.
Check the evidence before drawing a conclusion
A useful review is narrow and repeatable. Count the Received entries, follow them from top to bottom, and note any gaps, repeated systems, or times that appear inconsistent. Do not remove entries simply because they seem unrelated: a relay or filtering system may be part of the route. If dates matter, retain the time-zone information shown rather than comparing clock times as if they were all local.
Then connect the header to the actual symptom. If a recipient says a message never arrived, the header from the sender’s copy may show how far the message travelled, but it may not contain the recipient’s final delivery decision. The receiving provider or administrator may need logs or other information that is not present in the message.
- Keep a copy of the complete header before editing or forwarding the message.
- Record the symptom and approximate send time separately from your interpretation.
- Avoid treating a single unfamiliar host, timestamp, or line as proof of delivery or fraud.
Share enough context when asking for help
If the route does not explain the problem, send support the complete relevant header, along with the message’s approximate send time, sender and recipient addresses, and a concise description of what happened. Use a secure support channel and follow its instructions about handling message contents. A partial excerpt can remove the neighboring entries needed to understand the sequence.
Before sending, check that you have copied the header from the affected message rather than a reply or forwarded copy with additional routing details. Ask support whether they need the original message or other information. They can use the header as one piece of evidence, while confirming that any particular line proves inbox delivery would go beyond what the header alone can show.
About this guide
Prepared with AI assistance for the BITTU Mail editorial library. Check important details against your original messages and current account settings. Product access depends on your role, plan and provisioning state. Provider interfaces and requirements can change.
View current plans · Security information · Suggest a correction