Should you analyze the headers of every suspicious email?

No. Header analysis is a tool for the security team. Employees should report suspicious emails (report button or forward), and the security team reads the headers when it needs to classify the threat.

Are email headers reliable?

Headers added by intermediary servers and the receiving server are reliable (Received headers, Authentication-Results). Headers added by the sender (From, Reply-To, Subject, X-Mailer) can be forged.

What tools should I use to analyze headers?

Our free nophi.sh analyzer parses headers and displays a structured view. Other options: MXToolbox Header Analyzer, Google Admin Toolbox MessageHeader, mailheader.org. For security teams, SIEMs like Splunk or ELK can ingest and index headers at scale.

How do I identify the originating IP of an email?

Read the Received headers from bottom to top. The first hop (the last Received header in the text) contains the IP in brackets [x.x.x.x]. This is the IP of the initial sending server. Use whois or ipinfo.io to identify the owner of that IP.

What if the email fails SPF but passes DKIM?

This is common for forwarded emails. Forwarding breaks SPF because the intermediary server is not in the original domain's SPF record. If DKIM passes (the signature is intact) and DMARC passes (DKIM alignment), the email is probably legitimate. Check the d= in the DKIM pass to confirm the signing domain.

How to analyze email headers: a guide for security teams

Your security team receives a report: an employee got a suspicious email. Before closing the ticket, you need to know whether it is phishing or a legitimate email that looked odd. The answer is in the headers.

This guide is a reference for security teams. It covers how to read email headers, how to interpret authentication results and which anomalies to look for, with real examples and the commands to verify what you find.

Our free email header analyzer parses headers and displays a structured view. It runs entirely in your browser, so no data is sent to our servers.

What to check first

The From header shows the address the recipient sees, while the Return-Path reflects the SMTP envelope. Comparing the two domains is the first check on a suspicious email.
Read Received headers from bottom to top to trace an email’s path. An originating IP in an unexpected country, delays of several hours between hops, and missing TLS encryption are warning signs.
The Authentication-Results header summarizes the SPF, DKIM and DMARC checks. A triple failure is a strong signal, but a triple pass does not guarantee legitimacy.
DMARC alignment requires the domain verified by SPF or DKIM to match the domain in the header From. Without alignment, an spf=pass on a different domain does not protect against From spoofing.
A Reply-To that differs from the From is a classic sign that the attacker wants replies sent to an address they control.

Structure of an email

An email has two parts: the SMTP envelope (used for delivery) and the message (headers and body). The postal analogy helps:

SMTP envelope: the address written on the physical envelope (MAIL FROM and RCPT TO). The mail carrier reads it; the recipient never sees it.
Header From: the address written at the top of the letter, inside the envelope. This is what the recipient reads, and it can differ from the address on the envelope.

Email spoofing relies on this separation. An attacker writes your address on the letter (header From) and their own address on the envelope (envelope From / Return-Path). Without DMARC, the receiving server doesn’t compare the two.

Part 1: The main headers

From and Return-Path

From: "Finance Department" <cfo@company.com>
Return-Path: <bounce-5847@mail-marketing.net>

Start by comparing the two domains. Here, the From is company.com but the Return-Path is mail-marketing.net. There are two possible explanations:

Legitimate: the company uses a third-party service (Brevo, Mailchimp) to send this email, and the Return-Path belongs to that service.
Suspicious: the email claims to come from the finance department but was sent from an unrelated third-party server.

To decide, check whether mail-marketing.net is a known service and whether the company uses it.

Received (the transmission chain)

Each server adds its own Received header on top of the previous ones. To read them in chronological order, start from the bottom:

Received: from mail-out.marketing.net (mail-out.marketing.net [198.51.100.23])
        by mx1.company.com with ESMTPS id xyz789
        for <employee@company.com>;
        Wed, 26 Mar 2026 14:30:12 +0100 (CET)

Received: from internal-queue.marketing.net (internal-queue.marketing.net [10.0.1.42])
        by mail-out.marketing.net with SMTP id abc456;
        Wed, 26 Mar 2026 14:30:10 +0100 (CET)

Reading from bottom to top:

The internal server internal-queue.marketing.net (private IP 10.0.1.42) handed the email to mail-out.marketing.net at 14:30:10
The server mail-out.marketing.net (IP 198.51.100.23) handed the email to mx1.company.com at 14:30:12
Delay: 2 seconds, which is normal.

Warning signs in Received headers:

Signal	Explanation
Originating IP in an unexpected country	An email from a French company sent from a VPS in Southeast Asia
Delay of several hours between two hops	The email sat on an intermediary server (compromised relay, suspicious queue)
Server name inconsistent with the domain	`mail.vendor.com` resolving to `vps-cheap-hosting.net`
No encryption	`with SMTP` instead of `with ESMTPS` (no TLS)

Authentication-Results

Your receiving server adds this header. It summarizes the checks it performed:

Authentication-Results: mx1.company.com;
       spf=pass (sender IP is 198.51.100.23) smtp.mailfrom=marketing.net;
       dkim=pass (2048-bit key) header.d=marketing.net header.s=s1;
       dmarc=pass (p=REJECT) header.from=marketing.net

How to read the results:

Result	Interpretation
`spf=pass`	The sending server is authorized by the Return-Path domain
`spf=fail`	The server is not authorized. Possible spoofing or misconfiguration
`spf=softfail`	The server is not explicitly authorized, but the policy is lenient (~all)
`spf=neutral`	The domain makes no statement about this server (?all)
`dkim=pass`	The cryptographic signature is valid. The message has not been modified
`dkim=fail`	The signature is invalid. The message was modified or the key doesn’t match
`dmarc=pass`	SPF or DKIM passes with domain alignment (the verified domain matches the header From)
`dmarc=fail`	Neither SPF nor DKIM passes with alignment. The email should not be treated as coming from this domain

Alignment is the detail that matters. DMARC checks more than whether SPF or DKIM passes: the domain verified by SPF or DKIM must match the domain in the header From. Without alignment, an spf=pass on a different domain does not protect against From spoofing.

Part 2: Secondary headers

Reply-To

Reply-To: support@trap-domain.com

If the Reply-To differs from the From, the attacker wants your replies to reach an address they control. This is a classic warning sign.

Message-ID

Message-ID: <abc123@mail.company.com>

The domain in the Message-ID should match the sending server. A Message-ID with an inconsistent domain (or an unusual format) can indicate a forged email.

X-Mailer / User-Agent

X-Mailer: Microsoft Outlook 16.0

This header identifies the client software. An email supposedly sent from Outlook but showing X-Mailer: PHPMailer is suspicious.

X-Originating-IP

X-Originating-IP: [203.0.113.42]

Some mail servers add the IP of the machine that composed the email (the sender’s PC, not the mail server). It helps with geolocation.

ARC (Authenticated Received Chain)

ARC is a fairly recent protocol that preserves authentication results across forwards and mailing lists. ARC-Authentication-Results headers contain the results computed by the intermediary server before the forward.

Part 3: Verification commands

Verify an IP

whois 198.51.100.23

This identifies the owner of the IP block (AS, organization, country). Compare it with the claimed sender.

nslookup 198.51.100.23
# or
dig -x 198.51.100.23

Reverse DNS: does the IP resolve to a server name consistent with the sender?

Verify an SPF record

dig TXT company.com | grep spf

Compare the list of authorized servers in the SPF record with the email’s originating IP.

Verify a DKIM record

dig TXT selector1._domainkey.company.com

Replace selector1 with the selector shown in the header.s= of the Authentication-Results header.

Verify a DMARC record

dig TXT _dmarc.company.com

Check the policy (p=none, p=quarantine, or p=reject) and the report address (rua=).

Part 4: Standard analysis procedure

When an employee reports a suspicious email, follow these steps:

Retrieve the full headers. Ask the employee to use “Show original” (Gmail) or “View source” and copy the entire content.
Identify the real sender. Compare the From, the Return-Path and the originating IP, and look for inconsistencies.
Check authentication. Read the SPF, DKIM and DMARC results. A triple failure is a strong signal. A triple pass does not guarantee legitimacy, because the attacker may be using their own well-configured domain.
Analyze the network path. Trace up through the Received headers. Is the originating IP consistent with the sender? Are the delays normal?
Check the content. Does the link point to a suspicious domain? Is the attachment suspicious (macro, executable)?
Classify the incident: confirmed phishing, suspicious (monitor), or false positive. Document it with the full headers and your analysis.
Act. For confirmed phishing, block the sender, add the URL to your blocklist and alert employees who may have received the same email. If someone clicked, start the incident response procedure.

With nophi.sh, employees forward suspicious emails to a dedicated address (or use the Microsoft 365 Report button pointed at it). An AI verdict with its reasons comes back, usually in under a minute, and your security contacts get an alert with the analysis. Try it free for 14 days.