Analyzing a Phishing Email from Headers and Domain Information

Phishing emails often imitate well-known companies and services closely enough that the message body alone may not reveal where the email actually came from.

When I received several suspicious emails, I began looking beyond the visible sender name and message content.

The analysis focused on information that could be preserved and reviewed without interacting with suspicious links.

The process included:

• preserving the original email as an .eml file
• calculating a SHA-256 hash
• examining email headers
• reviewing SPF, DKIM, and DMARC results
• extracting URLs and hostnames
• identifying registered domains
• checking domain registration information
• comparing multiple suspicious emails
• organizing the findings into a reusable report

The objective was not simply to decide whether an email looked suspicious.

It was to understand what evidence could be extracted from the message itself and how that evidence could be structured for later review.

Start by Preserving the Original Email

Before analyzing a suspicious message, I preserve the original email whenever possible.

Saving the message as an .eml file retains information that may not be visible in the normal mail interface, including detailed headers and message routing information.

I also calculate a SHA-256 hash of the original file.

The hash does not determine whether the email is malicious. Its purpose is different: it provides a way to confirm that the preserved file has not changed during later analysis.

A simplified workflow is:

Original email
→ Preserve as EML
→ Calculate SHA-256
→ Analyze a working copy or extracted data

Keeping preservation and analysis separate makes the investigation easier to reproduce.

What I Check in the Email Headers

The visible From field is only one part of an email.

For suspicious messages, I review several header fields and authentication-related values together.

These can include:

• From
• Return-Path
• Reply-To
• To
• Received
• Message-ID
• Authentication-Results
• SPF results
• DKIM results
• DMARC results

No single field should automatically be treated as proof of legitimacy or fraud.

Instead, I compare the values and look for inconsistencies.

For example, the visible sender name may resemble a legitimate company while the actual sending infrastructure, return path, or linked domain belongs to an unrelated domain.

Authentication Results Are Evidence, Not the Whole Answer

SPF, DKIM, and DMARC are important signals, but their interpretation requires context.

A message can pass an authentication check for a domain that has nothing to do with the company being impersonated.

Therefore, I avoid interpreting a result such as SPF=pass as meaning that the email itself is trustworthy.

The more useful question is:

Which domain was authenticated,
and does that domain correspond to the organization represented in the message?

This distinction is particularly important in impersonation attacks.

Extracting URLs and Domains

URLs contained in suspicious messages can provide additional evidence.

Rather than opening the links, I extract the URL strings from the preserved message and identify:

• hostname
• registered domain
• path structure
• unusual subdomains
• redirects visible in the message source

The registered domain is particularly useful because a long hostname can sometimes make an unrelated domain less obvious.

For example:

account.example.login.suspicious-domain.example

The important part is not necessarily the leftmost words. The registered domain must be identified correctly.

Checking Domain Registration Information

After identifying a registered domain, I may check publicly available registration information, such as RDAP data.

Useful fields can include:

• registrar
• creation date
• expiry date
• domain status
• name servers

This information does not prove that a domain is malicious.

However, it can provide additional context when combined with the email headers, URLs, and other evidence.

For example, a recently registered or unrelated domain appearing in a message that imitates an established service may justify closer examination.

Comparing Multiple Emails

One suspicious email can provide useful evidence, but patterns become clearer when multiple messages are compared.

I organize extracted information into structured data so that I can compare fields such as:

This makes it easier to identify repeated infrastructure or differences between campaigns.

From Manual Analysis to a Local Tool

After repeating this process across several emails, I realized that much of the evidence extraction could be automated.

That led to the design of a local analysis tool for Windows.

The intended workflow is:

EML files
→ Hash calculation
→ Header extraction
→ Authentication result extraction
→ URL and domain extraction
→ Comparison data
→ Markdown analysis report

A key design principle is that the tool should operate locally.

The original email files do not need to be uploaded to an external AI service merely to extract headers, hashes, or URLs.

AI can still assist with interpretation or documentation, but evidence preservation and mechanical extraction can remain local.

Separating Evidence from Interpretation

One of the most useful lessons from this process has been the importance of separating observed facts from conclusions.

For example:

Observed evidence

• a specific sender domain
• an SPF result
• a DKIM result
• a URL hostname
• a domain registration date

Interpretation

• whether the infrastructure is related to the represented organization
• whether multiple emails appear connected
• whether the message should be treated as phishing

Keeping these layers separate reduces the risk of treating assumptions as evidence.

A Reusable Investigation Flow

The overall process can be summarized as:

Preserve
→ Extract
→ Verify
→ Compare
→ Interpret
→ Document

This is similar to other research work I do.

The subject is different, but the underlying approach remains consistent:

Question or suspicious event
→ Evidence collection
→ Information structuring
→ Verification
→ Reusable knowledge or tool

The experience also became the starting point for developing a reusable local phishing evidence analysis workflow.

This Research Note describes a general investigation workflow based on personal technical research. Identifying details, email addresses, and unnecessary indicators have been omitted or generalized. Domain registration information and authentication results should be interpreted together with other evidence and should not be treated as proof of malicious activity on their own.