How to Analyze Email Headers: A Practical Guide for Security Teams

Your security team receives a report: an employee got a suspicious email. Before closing the ticket, you need to determine whether it's a phishing attempt or a legitimate email that was misidentified. The answer is in the headers.

This guide is a practical reference for security teams. It covers reading email headers, interpreting authentication results, and identifying anomalies. Each section includes real-world examples and the commands to verify the information you extract.

Companion tool. Our free email header analyzer automatically parses headers and displays a structured view. 100% client-side - no data is sent to our servers.

Structure of an email

An email consists of two parts: the SMTP envelope (used for delivery) and the message (headers + body). The postal mail analogy is helpful:

SMTP envelope: the address written on the physical envelope (MAIL FROM and RCPT TO). This is what the mail carrier reads. 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. It can differ from the address on the envelope.

This separation is at the heart of email spoofing. An attacker writes your address on the letter (header From) while using their own address on the envelope (envelope From / Return-Path). Without DMARC, the receiving server doesn't compare the two.

Part 1: Essential headers

From and Return-Path

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

First check: compare the two domains. Here, the From is company.com but the Return-Path is mail-marketing.net. Several possible explanations:

Legitimate: the company uses a third-party service (Brevo, Mailchimp) to send this email. The Return-Path belongs to the service.
Suspicious: the email claims to come from the finance department but is 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)

Received headers are stacked by each server. To read them chronologically, 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)

Chronological reading (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. 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

This header is added by your receiving server. It summarizes the checks 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

Reading guide:

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

The detail that matters: alignment. DMARC doesn't just check whether SPF or DKIM passes. It checks that the domain verified by SPF or DKIM matches the domain in the header From. That's alignment. Without alignment, an spf=pass on a different domain does not protect against From spoofing.

Part 2: Useful secondary headers

Reply-To

Reply-To: support@trap-domain.com

If the Reply-To differs from the From, the attacker wants to capture your replies at 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

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 client machine that composed the email (not the mail server, but the sender's PC). This is valuable information for geolocation.

ARC (Authenticated Received Chain)

ARC is a relatively recent protocol that preserves authentication results across forwards and mailing lists. If you see ARC-Authentication-Results headers, they contain the authentication results from the intermediary server before the forward occurred.

Part 3: Verification commands

Verify an IP

whois 198.51.100.23

Identifies the owner of the IP block (AS, organization, country). Compare 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 this procedure:

1. Retrieve the full headers. Ask the employee to use "Show original" (Gmail) or "View source" and copy the entire content.

2. Identify the real sender. Compare the From, the Return-Path, and the originating IP. Look for inconsistencies.

3. Check authentication. Read the SPF, DKIM, and DMARC results. A triple failure is a strong signal. A triple pass does not guarantee legitimacy (the attacker may be using their own well-configured domain).

4. Analyze the network path. Trace up through the Received headers. Is the originating IP consistent with the sender? Are the delays normal?

5. Check the content. Does the link point to a suspicious domain? Is the attachment suspicious (macro, executable)?

6. Classify the incident. Confirmed phishing, suspicious (monitor), or false positive. Document with the full headers and your analysis results.

7. Act. Confirmed phishing: block the sender, add the URL to your blocklist, alert employees who may have received the same email. If someone clicked: trigger the incident response procedure.

Automate reporting. With nophi.sh, employees forward suspicious emails in one click. The AI analyzes the email and delivers a verdict in 30 seconds. The security team receives an alert with the analysis details. Start for free.