100 Digital Life Security #4: Reading an Email Header — Following the Evidence

Digital Life Security Series ...Practical ways to protect your devices, accounts, privacy, information and home

An email arrives that does not look quite right.

The sender's name is familiar, but something about the message seems unusual.

Where did it really come from?

Was the sending server authorized?

Was the message digitally signed?

Did SPF, DKIM, and DMARC pass?

Did the message travel through the servers we would expect?

The answers may be hiding in something most people never see:

The email header.

There Is Much More to an Email Than We Normally See

Most email programs intentionally show us a simplified version of a message.

We see something like:

From: Jane Smith <jane@example.com>
To: Brad <brad@example.net>
Subject: Invoice
Date: September 24, 2026

Behind that simple presentation can be dozens of additional header fields recording information about the message.

Mail servers may add information as the message travels through the email system. Authentication systems add results. The sending software adds identifiers. Spam and security systems may add their own observations.

Looking at the full header can feel a little like opening the hood of a car.

At first, there seems to be an overwhelming amount of machinery.

But once we know the important parts, patterns begin to emerge.

How Do You See the Header?

The exact command varies among email programs and services.

Look for wording such as:

• View Source
• View Message Source
• Show Original
• View Raw Message
• Show Headers
• View Full Headers

You may suddenly be presented with a large block of technical-looking information.

Do not worry about understanding everything.

We are going to learn where to look first.

Start With From

You might find a line resembling:

From: "Jane Smith" <jane@example.com>

This is the address presented to the recipient as the author of the message.

It is important, but we should immediately learn a fundamental lesson:

The From field alone is not proof of who actually sent the message.

Email was designed in a more trusting era, and some information supplied by the sender can be manipulated.

That is one reason modern email authentication systems were developed.

The Display Name Can Be Especially Misleading

Consider:

From: "Your Bank" <randomaddress@example.org>

An email application might prominently display:

Your Bank

If you do not look farther, you might assume that is who sent it.

But the display name is simply text supplied as part of the message.

A familiar display name should never be treated as authentication.

Now Look at Reply-To

Another useful field is:

Reply-To:

For example:

From: billing@example.com
Reply-To: paymentdepartment@different-example.com

A different Reply-To address is not automatically suspicious.

Businesses legitimately use different systems to send and receive email.

But an unexpected difference deserves attention.

If you press Reply, the response may go somewhere other than the address shown in From.

That can be useful to an attacker attempting to redirect a conversation.

Return-Path Is Something Different

You may also see:

Return-Path: <bounce@example.com>

The Return-Path is associated with the envelope sender used during mail delivery.

It is commonly where delivery failure information would be directed.

This address can legitimately differ from the visible From address.

Newsletter services, mailing lists, cloud mail systems, and other automated services often use specialized envelope addresses.

This distinction becomes important when examining SPF because SPF normally evaluates the domain involved in the mail transaction rather than simply trusting the visible From line.

One Email Can Have Several Identities

This surprises many people.

An email may contain several different addresses or domains serving different purposes:

• The visible From address
• The Reply-To address
• The envelope sender or Return-Path
• The domain used by a DKIM signature
• The servers that actually transported the message

They do not necessarily have to be identical.

Understanding how they relate is much more useful than simply looking for one matching address.

Received: The Message's Travel Record

Now we reach one of the most interesting parts of an email header:

Received:

As mail travels between servers, receiving mail systems normally add a Received header describing the handoff.

A simplified example might look something like:

Received: from mail.example.com (192.0.2.10)
    by mx.example.net with ESMTP;
    Thu, 24 Sep 2026 14:32:10 -0400

This tells part of the story of how the message reached its destination.

Messages that pass through several systems can accumulate several Received lines.

Read Received Headers From Bottom to Top

This is one of the first practical skills to remember.

Received headers are generally read from the bottom upward when reconstructing the route of an email.

Each receiving server adds its information above what was already there.

Therefore, the newest handoff normally appears toward the top while earlier handoffs appear farther down.

Reading upward can allow us to reconstruct the apparent journey:

Original system → outgoing mail server → intermediate system → receiving mail server.

Now we are beginning to perform an investigation rather than merely looking at an email.

But Can We Trust Every Received Line?

Here we need to develop a more advanced security habit.

Not necessarily.

A sender controls the message before it reaches infrastructure we trust and may be able to insert misleading information into portions of it.

However, when your own mail provider receives a message from another server, your provider can record information about the connection it actually observed.

That distinction matters.

Evidence becomes stronger when it was generated by a system we trust rather than supplied by the party we are investigating.

This principle extends far beyond email.

Authentication-Results: One of My Favorite Places to Look

Many modern mail systems add a header resembling:

Authentication-Results:

Inside it you may find results such as:

spf=pass
dkim=pass
dmarc=pass

This is extremely useful because the receiving mail system is recording the results of authentication tests it performed.

Instead of merely accepting what the sender claims, we can examine what the receiving infrastructure determined.

What Does spf=pass Tell Us?

Suppose we see:

spf=pass

In simplified terms, this means the receiving system determined that the server involved in delivering the message was authorized under the SPF policy for the domain being checked.

That is useful evidence.

But remember an important lesson:

SPF passing does not automatically prove that the visible From address is trustworthy.

SPF authenticates a particular domain used during mail transport.

This is one reason DMARC alignment matters.

What Does dkim=pass Tell Us?

You may see:

dkim=pass

Elsewhere in the header you may find something beginning with:

DKIM-Signature:

A DKIM signature contains several pieces of information. Two particularly useful ones are often identified by:

d=example.com

and:

s=selector1

The d= value identifies the signing domain.

The s= value identifies a selector used to locate the appropriate public-key information in DNS.

The receiving mail server can retrieve that public information and verify the cryptographic signature.

If DKIM passes, we have evidence that the signature validated and that the signed portions of the message have not been altered in a way that breaks that signature.

DMARC Connects Authentication to What the User Sees

Now suppose we find:

dmarc=pass

DMARC asks an especially useful question.

Does a domain authenticated through SPF or DKIM appropriately align with the domain shown to the recipient in the visible From address?

This helps address an important weakness in simply checking SPF or DKIM independently.

A message might successfully authenticate some domain while displaying another domain to the user.

DMARC helps connect authentication with the identity the recipient actually sees.

Pass Does Not Mean Safe

This is extremely important.

Imagine a criminal legitimately registers:

example-security-alert.com

They properly configure SPF.

They properly configure DKIM.

They properly configure DMARC.

Their fraudulent message might pass all three authentication checks.

Why?

Because those systems can demonstrate that the sender was authorized to send mail for their domain.

They do not determine whether the person operating that domain is honest.

This is similar to our lesson about HTTPS.

Authentication provides evidence about identity and technical authorization. It does not automatically establish intent or trustworthiness.

Message-ID Can Provide Another Clue

You may find something resembling:

Message-ID: <unique-string@example.com>

The Message-ID is intended to provide a unique identifier for a message.

Its format and domain can sometimes provide clues about the system that generated the email.

But again, we should not treat it as unquestionable proof.

It is one piece of evidence to compare with the rest of the message.

Dates and Time Zones Can Tell a Story

Email headers frequently contain multiple timestamps.

Comparing them can help reconstruct when the message moved between servers.

Small differences are completely normal.

A large unexplained delay might be interesting.

Time zones can initially make the sequence confusing, so investigators often normalize timestamps to a common time zone when analyzing complicated mail delivery.

This is another example of security work being partly about reconstructing events.

IP Addresses Can Help Identify the Sending Infrastructure

Received headers may contain IP addresses associated with mail servers.

Those addresses can sometimes help determine which network or provider handled a message.

But an IP address needs context.

A large email provider may operate enormous ranges of addresses. Cloud systems may send mail from infrastructure far away from the apparent sender. Mailing services may legitimately send email on behalf of thousands of organizations.

An unfamiliar IP address is therefore not automatically suspicious.

Security investigation is rarely about finding one strange-looking value.

It is about determining whether all the evidence tells a consistent story.

Think Like an Investigator

Suppose we receive a suspicious message claiming to come from example.com.

Instead of asking only:

Does this look real?

We can begin asking more precise questions:

• What is the actual visible From address?
• Is there a different Reply-To address?
• What domain appears in the Return-Path?
• Which servers handled the message?
• Where does the trustworthy portion of the Received chain begin?
• What did SPF report?
• Which domain signed the message with DKIM?
• Did DKIM validation pass?
• Did DMARC pass?
• Does the authenticated identity align with the visible From domain?
• Does the overall route make sense?

Notice what we are doing.

We are not looking for a single magic field that tells us whether the message is good or bad.

We are correlating evidence.

Corroboration Is a Security Skill

This is an important step toward thinking like a security professional.

One piece of information can be misleading.

Several independent pieces of information telling the same story are much stronger.

A familiar From address is evidence.

A legitimate-looking server path adds evidence.

A valid DKIM signature adds evidence.

SPF adds another observation.

DMARC alignment connects authentication to the visible identity.

The content and context of the message provide still more information.

No single item necessarily answers every question.

Together, they can tell a compelling story.

Headers Can Contain Sensitive Information

There is another practical lesson worth remembering.

Be thoughtful before posting a complete email header publicly.

Headers can contain email addresses, server names, message identifiers, IP addresses, internal routing information, and other details you may not intend to share.

If you ask someone for help analyzing a header, consider what information should be redacted before publishing it publicly.

Try It Yourself

Open a legitimate email from a company or service you know.

Find the option to display the full header or original message.

Then see if you can locate:

• From:
• Reply-To: if present
• Return-Path:
• Received:
• Authentication-Results:
• SPF results
• DKIM-Signature:
• dkim=pass or another DKIM result
• dmarc=pass or another DMARC result
• Message-ID:

Do not worry if much of the header still looks like another language.

Find the pieces you recognize.

Then follow the evidence.

From User to Investigator

At the beginning of this series, we talked about becoming better security administrators of our own digital lives.

Now something interesting is happening.

We are beginning to investigate.

Instead of saying:

“This email looks suspicious.”

We can begin saying:

“Let's find out where it came from, how it was authenticated, and whether the evidence supports the identity it claims.”

That is a very different way of thinking.

And it is one of the foundations of cybersecurity.

Follow the Evidence

An email header may look intimidating at first.

But underneath all those lines is a record of systems communicating with one another.

Servers identify themselves.

Messages are handed from one system to another.

Cryptographic signatures are checked.

DNS records are consulted.

Authentication results are recorded.

Once we understand those pieces, the header stops looking like random technical information.

It becomes evidence.

And good security decisions begin with good evidence.