Skip to content
EML-038 Email Evidence

Which Received line can I trust?

title: Which Received line can I trust? subtitle: Start with the recipient’s trusted mail system and work backwards only while each hop can be explained. slug: which-received-line-can-i-trust series: email-evidence section: technical-interpretation card_type: question_card pathway_order: 15 section_order: 2 status: draft public_safe: true video_ready: true word_count: 725 estimated_read_time_seconds: 300 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - email evidence - Received header - trust boundary - routing - mail server sources: - title: 'RFC 5321: Simple Mail Transfer Protocol' url: https://www.rfc-editor.org/info/rfc5321/ - title: 'RFC 5322: Internet Message Format' url: https://www.rfc-editor.org/info/rfc5322/ - title: 'RFC 5598: Internet Mail Architecture' url: https://www.rfc-editor.org/info/rfc5598/ - title: 'Gmail Help: Trace an email with its full header' url: https://support.google.com/mail/answer/29436?hl=en-GB - title: 'Microsoft Learn: Message Header Analyzer' url: https://learn.microsoft.com/en-us/connectivity-analyzer/message-header-analyzer

Which Received line can I trust?

Start with the recipient’s trusted mail system and work backwards only while each hop can be explained.

Script

You’ve opened the complete header and found several Received lines.

One of them may show where the message entered the recipient’s trusted email system. Others may describe earlier hops through relays, gateways or sending platforms.

But you can’t safely trust a Received line just because it is at the top, bottom or closest to the visible From address.

The useful question is:

Which system added this line, and do I trust that system to describe the connection it received?

When an SMTP server accepts a message, it normally adds its own Received trace field at the top of the existing message. As the email moves through several servers, the newest line is added above the earlier ones.

That means the header usually reads in reverse journey order.

The top line is the most recent recorded hop.

The lower lines claim to describe earlier parts of the route.

But there is an important limitation.

Before the message enters infrastructure you trust, the sender or an earlier system may be able to insert false-looking header fields. A malicious sender can write a convincing Received line into the message before handing it to a genuine mail server.

So don’t begin at the bottom and assume you’ve found the sender.

Begin at the top.

Identify the mail system that delivered the message into the recipient’s mailbox. That may be Microsoft 365, Google Workspace, an organisational gateway, a filtering service or another provider.

Confirm which Received lines were added by that trusted environment.

Then work downwards through the chain.

For each line, ask:

Which server says it received the message?

Which system does it say sent the message?

Does the receiving server belong to the recipient’s provider or another known part of the delivery path?

Does the hostname or IP address fit the organisation’s actual infrastructure?

Do adjacent timestamps make sense?

Can the hop be matched to message-trace, gateway or provider records?

Continue only while the systems and their behaviour can be explained.

The most useful boundary is often the first trusted server that accepted the message from outside the recipient’s environment.

Its Received line may tell you which external mail server connected to it, the time of the connection and sometimes the protocol or security used.

That is usually stronger than a line further down that simply claims the message came from a particular laptop, address or internal system.

For example, the recipient’s provider may record that it received the message from a server operated by a marketing platform.

That supports a conclusion about the platform that handed the message over.

A lower line claiming that the message began on a named workstation may have been added inside the platform, by the customer’s system or by somebody creating the message. Its value depends on whether that earlier system can be identified and verified.

Be careful with private IP addresses and internal hostnames.

They may accurately describe movement inside the sender’s organisation or provider. They may also be meaningless outside that environment. A private address doesn’t identify an internet subscriber.

Also expect legitimate complexity.

Security gateways may receive, scan and resend messages. Mailing lists may redistribute them. Customer-management systems may generate them. Cloud providers may move them through several internal services. The header may show a real but indirect route.

The common mistake is:

“The bottom Received line contains an IP address, so that must be the sender’s device.”

It may be.

It may also be a fabricated line, a local server, a webmail gateway, a shared platform or a system several steps away from the person who wrote the email.

Another mistake is to trust every line above a genuine provider name. A message can contain both trusted and untrusted trace information. You need to identify the point where the message entered the trusted chain.

Preserve the full header exactly as received. Don’t reorder the lines or paste selected parts into a new document before keeping the original.

Then report the result precisely.

“The recipient’s mail provider recorded the message as arriving from this external mail server at this time” may be a sound conclusion.

“The lowest IP address proves the suspect sent the email from this device” usually goes much further than the header allows.

Trust the server that added the line.

Work backwards from known infrastructure.

And stop when the chain moves beyond what you can verify.

Key takeaway

A Received line is useful because of the system that added it, not because of where it appears in the header.

Source notes

Keep moving

Where this question leads

These links explain why the next page may matter, rather than presenting an undifferentiated list.