Skip to content
Back to blog
email headersphishingemail securityforensic analysis

How to Trace the Origin of a Suspicious Email Using Headers

Email headers reveal the real sender, the path taken, and authentication results. A step-by-step practical guide to analyzing the headers of a phishing email.

Thomas Ferreira18 min read

An employee forwards you a suspicious email. The subject line mentions an unpaid invoice for 12,400 euros. The sender displays the name of a supplier you have been working with for three years. The link points to a site that looks like a Microsoft 365 login page.

Your question: did this email really come from that supplier, or is it phishing?

The answer lies in the email headers.

Headers are metadata added by every server that processes the email. They form a trace of the email's full journey, from the real sender to your inbox. Knowing how to read them means knowing how to tell a legitimate email from a phishing attempt in a matter of minutes.

This guide shows you how to access headers, read them, and spot the warning signs.

Free tool. Paste your headers into our email header analyzer for a structured view with authentication results and the network path. 100% client-side, nothing is sent to our servers.

How to Access Email Headers

Every email client provides a way to display full headers. Here are the most common ones.

Gmail

  1. Open the email
  2. Click the three vertical dots in the top right corner
  3. Select Show original
  4. Gmail displays the raw headers along with a summary of SPF, DKIM, and DMARC results at the top

Gmail also provides a summary in the "Show original" panel: three lines for SPF, DKIM, and DMARC with their result (pass/fail). This is a good starting point before diving into the raw headers.

Outlook Desktop

  1. Open the email in a separate window (double-click)
  2. File → Properties
  3. The headers appear in the Internet Headers field

The field is small by default. Select all (Ctrl+A), copy (Ctrl+C), and paste into a text editor for easier reading.

Outlook Web (OWA)

  1. Open the email
  2. Click the three dots (...) → View → View message source

Apple Mail

  1. Open the email
  2. Menu View → Message → All Headers (or Cmd + Shift + H)

Thunderbird

  1. Open the email
  2. Menu View → Message Source (or Ctrl + U)

Yahoo Mail

  1. Open the email
  2. Click the three dots (...) → View raw message

Once you have the headers, you can analyze them manually using this guide, or paste them directly into our free email header analyzer, which automatically identifies each server in the chain and the authentication results.

Anatomy of an Email Header

An email contains dozens of headers. Here are the ones that matter for security analysis, in order of priority.

From (the Displayed Sender)

From: "Billing Department" <billing@supplier.com>

This is the address the recipient sees in their email client. It can be forged. Anyone can put any address in the From field. It is exactly like writing a fake return address on a paper envelope.

Never rely on the From field alone to judge whether an email is legitimate.

Return-Path (the Envelope From)

Return-Path: <bounce-123@sending-server.com>

This is the actual address used for SMTP delivery (envelope From). This is the address SPF checks. If the Return-Path differs from the From, that is a first warning sign.

Note: some legitimate services (newsletters, transactional emails) use a different Return-Path to handle bounces. For example, Brevo uses addresses like bounce@abcd.brevo.com for its clients. This is not necessarily suspicious, but it deserves a closer look.

Received (the Network Path)

Received headers are the most informative for tracing the path an email took. Every server that processes the email adds a Received header. They are stacked from bottom to top: the last Received header (at the bottom of the block) is the first server, the first one (at the top) is the last.

Received: from mail-out.supplier.com (mail-out.supplier.com [203.0.113.42])
        by mx.google.com with ESMTPS id abc123
        Thu, 26 Mar 2026 10:15:23 +0100 (CET)

This header says: the server mx.google.com received the email from mail-out.supplier.com (IP 203.0.113.42) on March 26 at 10:15.

What to check:

  • The originating IP (first server in the chain) - does it belong to a known server of the claimed sender? Use an IP lookup service (ipinfo.io, whois) to identify the owner.
  • The server names - are they consistent with the sender's domain? An email claiming to come from supplier.com but sent from srv47.hostingprovider.net is suspicious.
  • The delays between servers - are they reasonable? A normal email passes through servers in a few seconds. A delay of several hours between two hops can indicate routing through an intermediate server (compromised server, open relay, suspicious queuing).

Authentication-Results

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of billing@supplier.com
         designates 203.0.113.42 as permitted sender)
       smtp.mailfrom=billing@supplier.com;
       dkim=pass header.d=supplier.com header.s=selector1;
       dmarc=pass (p=REJECT sp=REJECT) header.from=supplier.com

This is the receiving server's verdict. Three results to check:

ProtocolResultMeaning
SPFpassThe sending server is authorized by the domain
SPFfailThe sending server is not authorized - warning sign
SPFsoftfailThe server is not authorized, but the policy is lenient
DKIMpassThe cryptographic signature is valid, the content is intact
DKIMfailThe signature is invalid or missing
DKIMnoneNo DKIM signature was found
DMARCpassSPF or DKIM passes with domain alignment
DMARCfailNeither SPF nor DKIM passes with alignment - strong warning sign

A typical phishing email will show spf=fail or dmarc=fail. But be careful: an spf=pass does not guarantee the email is legitimate (the attacker may have configured SPF on their own domain while displaying a different address in the From field).

This is why DMARC is the most reliable result: it checks the alignment between the displayed domain (From) and the domains authenticated by SPF/DKIM.

Reply-To

Reply-To: reply@different-domain.com

If the Reply-To differs from the From, that is a warning sign. The attacker wants you to reply to an address they control, not to the displayed address.

Legitimate support or newsletter emails sometimes use a different Reply-To (for example support@ instead of noreply@). But a Reply-To pointing to a completely different domain than the From is suspicious.

X-Mailer / User-Agent

X-Mailer: PHPMailer 6.0.0

This identifies the software used to send the email. An email from your regular supplier sent via PHPMailer or a Python script instead of their usual mail server (Gmail, Exchange, etc.) is suspicious. Attackers often use scripted sending libraries.

Message-ID

Message-ID: <abc123@mail-out.supplier.com>

The Message-ID is a unique identifier assigned by the sending server. The domain after the @ should match the sender's domain or their email provider. A Message-ID with an unrelated domain (for example @localhost or @vps-random-42.com) is an additional warning sign.

The 6 Warning Signs in Email Headers

1. The Return-Path Does Not Match the From

From: billing@supplier.com
Return-Path: <user@unknown-server.ru>

The From displays a known supplier. The Return-Path reveals an unrelated Russian server. This is the sign of a spoofed email sent from a third-party server.

2. Authentication Results Fail

spf=fail
dkim=fail
dmarc=fail

If all three fail, the email passed no verification. This is a strong signal of spoofing. Some legitimate emails may fail SPF or DKIM individually (forwards, mailing lists), but simultaneous failure of all three is almost always suspicious.

3. The Originating IP Is Inconsistent

The email claims to come from BNP Paribas. The originating IP points to a VPS at a hosting provider in Eastern Europe. Large organizations use identifiable IP ranges and dedicated mail servers.

To check an IP: use an IP geolocation service (ipinfo.io, whois) and compare with the sender's known infrastructure.

4. Abnormal Delays Between Servers

Received: from mx1.intermediary.com ... Thu, 26 Mar 2026 10:15:23
Received: from source-server.net ... Thu, 26 Mar 2026 06:02:41

Over 4 hours between two hops. A legitimate email passes through servers in a few seconds, sometimes a few minutes. A delay of several hours can indicate the email was queued on an intermediate server (compromised server, open relay, or an attempt to bypass time-based filters).

5. Missing or Inconsistent Headers

A legitimate email sent from a professional mail server (Google Workspace, Microsoft 365, Exchange) contains consistent and complete headers: Message-ID, MIME-Version, Content-Type, Date. A hand-crafted email or one sent from a script may be missing these standard headers, or contain them with inconsistent values.

6. A Reply-To Pointing to an External Domain

From: ceo@yourcompany.com
Reply-To: urgent-reply@protonmail.com

The email claims to come from your company's CEO, but asks that replies go to an external Protonmail address. This is a classic pattern of Business Email Compromise (BEC). The real executive would not use an external address to receive replies.

Practical Example: Analyzing a Suspicious Email Step by Step

Let's take a realistic phishing email. The email claims to come from "Microsoft 365" and asks you to "verify your account following unusual activity."

Extracted headers:

From: "Microsoft 365 Security" <security@microsoft.com>
Return-Path: <noreply@srv-mail-47.hostingprovider.net>
Received: from srv-mail-47.hostingprovider.net
  (srv-mail-47.hostingprovider.net [185.234.x.x])
  by mx.google.com with ESMTP id abc456
  Thu, 26 Mar 2026 03:42:18 -0700 (PDT)
Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of security@microsoft.com
         does not designate 185.234.x.x as permitted sender);
       dkim=none;
       dmarc=fail (p=REJECT) header.from=microsoft.com
Reply-To: support-verification@outlook-secure.net
X-Mailer: PHPMailer 6.5.0
Message-ID: <random123@srv-mail-47.hostingprovider.net>

Signal-by-signal analysis:

  1. Return-Path: noreply@srv-mail-47.hostingprovider.net - no connection to microsoft.com. Microsoft uses its own mail servers (protection.outlook.com, mail.protection.outlook.com).

  2. Originating IP: 185.234.x.x - a third-party hosting provider, not a Microsoft server. A whois lookup confirms it is a VPS provider with no link to Microsoft.

  3. SPF: fail - the server 185.234.x.x is not authorized by microsoft.com. Microsoft's SPF record only lists its own servers.

  4. DKIM: none - no DKIM signature was found. Microsoft signs all its outgoing emails with DKIM.

  5. DMARC: fail with p=REJECT - Microsoft has a strict DMARC policy. This email should have been rejected by the receiving server (Gmail flagged it but still displayed the message with a warning).

  6. Reply-To: outlook-secure.net - a domain that is not microsoft.com and does not belong to Microsoft. The attacker wants to capture replies.

  7. X-Mailer: PHPMailer - Microsoft does not use PHPMailer to send its notifications.

  8. Message-ID: domain srv-mail-47.hostingprovider.net - confirms the email was not sent from Microsoft infrastructure.

Verdict: confirmed phishing. Eight converging warning signs.

Automate this analysis. Paste the headers into our free email header analyzer to get this analysis in one click: originating IP, authentication results, network path, delays between servers.

ARC: The Protocol That Handles Forwards

A common problem: a legitimate email is forwarded by an intermediate server. The forward changes the envelope (Return-Path), which breaks SPF. If the intermediate server also modifies the message body (adding a footer, rewriting URLs), DKIM fails too. Result: a legitimate email fails DMARC after being forwarded.

ARC (Authenticated Received Chain) solves this problem. Each intermediate server that modifies the email adds its own ARC signatures. The receiving server can verify the ARC chain to confirm that the email was legitimate before the forward.

ARC is supported by Gmail, Microsoft 365, Yahoo, and most major email providers. If you see ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal headers, that indicates an email that was forwarded by an ARC-compatible server.

ARC-Authentication-Results: i=1; mx.google.com;
       spf=pass (google.com: domain of user@original-sender.com)
       dkim=pass header.d=original-sender.com;
       dmarc=pass header.from=original-sender.com

The i=1 indicates this is the first ARC verification in the chain. If the email passed through multiple servers, you will see i=2, i=3, etc.

Limitations of Header Analysis

Header analysis is useful, but it has its limits.

Received headers on the sender side can be forged. Headers added by the sending server (before the email leaves its network) can be fabricated. Only headers added by trusted intermediate servers and the receiving server are reliable. Always start your analysis from the top (receiving server) and work your way down with caution.

A legitimate email can fail verification. Misconfiguration on the sender's side, expired DNS records, intermediate forwarding. An isolated SPF or DKIM failure is not proof of phishing. It is a signal to put in context with other indicators. What matters is the convergence of signals.

Header analysis is reactive. You are analyzing an email after receiving it. Real protection means training your teams to recognize phishing signals before they click.

Phishing from third-party domains. If an attacker sends an email from their own domain (not yours), with their own valid SPF and DKIM, the authentication checks will pass. Header analysis will show the email came from an unknown domain, but not that it is malicious. Human vigilance remains necessary.

What to Do When You Identify a Fraudulent Email

Internal Steps

  1. Do not click any links and do not open any attachments. If an employee has already clicked, immediately change the affected passwords and check recent account logins.
  2. Report the email to your security manager or IT provider. Forward the email as an attachment (.eml) to preserve the headers.
  3. Block the sender at the mail server level (not just in the user's client).
  4. Warn colleagues who might receive the same email.

External Reporting

  • Cybermalveillance.gouv.fr (France's national cyberattack assistance platform): reporting and assistance portal. In 2024, the site handled over 280,000 assistance requests.
  • Signal Spam (signal-spam.fr) (French spam reporting platform): report fraudulent emails to feed filtering databases.
  • PHAROS (internet-signalement.gouv.fr) (France's online content reporting platform): reporting to the Ministry of the Interior, particularly for fraud attempts.
  • Filing a complaint: if you have suffered financial loss, file a complaint with the police. The THESEE platform (France's online fraud complaint platform) allows pre-filing complaints online for internet-related fraud.

From Analysis to Prevention

Knowing how to analyze email headers is a useful skill for your technical team and your security manager. But your 50, 100, or 500 employees are not going to open the headers of every email they receive. They need simpler reflexes:

  • Check the sender's address (not just the displayed name)
  • Hover over links before clicking (the destination URL appears at the bottom of the browser or email client)
  • Be wary of urgency ("Your account will be suspended in 24 hours")
  • Report suspicious emails instead of trying to analyze them alone

These reflexes are built through practice, not through annual PowerPoint presentations. Regular phishing simulations, followed by targeted micro-training, are the most effective way to reduce click rates. According to the Proofpoint State of the Phish 2025 report, companies that run monthly simulations reduce their click rate by 75% within 12 months.

nophi.sh sends realistic phishing simulations to your teams and automatically trains employees who click. Your security team receives reports and analyzes them. Start for free.

Going Further

Related articles

CEO Fraud and Targeted Phishing: The Most Costly BEC Cases in France

From Pathé (EUR 19.2M) to Vallourec (EUR 22M), a look back at the most expensive CEO fraud cases in France. Techniques, case law, and how to protect your business from BEC.

How to Choose a Phishing Awareness Solution in 2026

10 objective criteria for evaluating phishing simulation platforms. Scoring grid, pitfalls to avoid, and a comparison of leading solutions on the market.

Email security for SMBs: why testing SPF, DKIM and DMARC is urgent

Most small and mid-sized businesses have no DMARC policy set to reject. That means anyone can send an email pretending to be you. Here is how to test your domain and fix the problem.