Back to Blog
Understanding Email Headers: How Security Analysts Spot Spoofed Mail
PublishedSeptember 14, 2026•8 min read•Beginner

Understanding Email Headers: How Security Analysts Spot Spoofed Mail

Learn how email headers work, how to trace an email's true path, and how authentication protocols like SPF, DKIM, and DMARC spot phishing attempts.

Cyber SecurityCybersecurityEmail SecurityPhishingSecurity Operations
Written byAbdul Muqeet Tabraiz

When you open your email client, you usually see three main details about a message: who sent it, the subject, and the message content. However, the display name and email address shown in the “From” line are remarkably easy to fake.

Attackers take advantage of this by impersonating trusted colleagues, banks, or services to trick users into clicking malicious links or giving up credentials. To figure out where an email actually came from, security analysts don’t rely on what the email client displays on the surface. They look at the email header.

Understanding how to read email headers is one of the most practical skills you can learn in cybersecurity. It allows you to analyze suspicious messages, verify senders, and understand how email systems interact across the internet.

What Is an Email Header?

Every email consists of two main parts: the body (the actual content of the message, including images and text) and the header (metadata containing technical details about how the message was routed and delivered).

Think of an email like a physical envelope sent through the mail:

  • The body is the letter inside the envelope.
  • The header is the collection of postmarks, return addresses, and tracking stamps applied by each post office that handled the letter along its journey.

Email clients like Gmail, Outlook, or Apple Mail hide most of these headers by default to keep the interface clean. But when you inspect the raw email source, the full header reveals every server the message touched, authentication test results, and timestamp logs.

Key Fields in an Email Header

While headers contain dozens of lines of metadata, a few core fields are critical when investigating suspicious emails.

1. The Standard Envelope Fields

  • From: The email address displayed to the recipient. This field is purely informational and can easily be forged.
  • To: The intended recipient’s email address.
  • Subject: The topic line created by the sender.
  • Date: The time the email was composed according to the sender’s device clock.

2. The Routing Fields

  • Return-Path: Also known as the “envelope sender.” This tells receiving mail servers where to send bounce-back notifications if the message fails to deliver. Attackers often use a real domain in the From field but control the domain listed in Return-Path.
  • Received: These lines record the journey of the email. Every mail server that handles the message appends a new Received: line to the top of the header.

Because each server adds its entry to the top, you must read Received: headers from the bottom up to trace the email chronologically from its origin server to its final destination.

How Attackers Spoof Email

To understand why email headers matter, you need to know how email transmission works under the hood.

Emails are sent using SMTP (Simple Mail Transfer Protocol). When SMTP was designed decades ago, internet standards did not include built-in identity verification. The protocol essentially allowed the sending mail client to specify any address it wanted in the sender fields—much like writing any return address you want on a paper envelope.

An attacker running their own mail server can send a message claiming to be billing@yourbank.com. If your mail provider simply accepted that claim at face value, the fake email would land straight in your inbox looking completely genuine.

To fix this vulnerability, three core security mechanisms were added to modern email systems: SPF, DKIM, and DMARC.

The Three Pillars of Email Authentication

When a mail server receives a message, it checks the sender’s domain using three DNS-based rulesets. The results of these checks are recorded directly in the email header under the Authentication-Results: field.

       [ Sending Server ]
               │
               ▼
┌──────────────────────────────┐
│ Email Delivery in Transit    │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│  Receiving Server Checks:    │
│  - SPF  (Authorized IP?)     │
│  - DKIM (Valid Signature?)   │
│  - DMARC (Policy Check)      │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│ Header Marked & Delivered    │
└──────────────────────────────┘

1. SPF (Sender Policy Framework)

SPF allows a domain owner (like company.com) to publish a list of IP addresses or servers allowed to send email on their behalf.

  • How it works: When an email arrives from company.com, the receiving server checks the sender’s IP address against the public SPF record published in company.com’s DNS settings.
  • Header result: If the IP matches, SPF passes (spf=pass). If an unauthorized server sent it, SPF fails (spf=fail or spf=softfail).

2. DKIM (DomainKeys Identified Mail)

While SPF checks where the email came from, DKIM checks if the email was altered during transit and verifies domain ownership using cryptography.

  • How it works: The sending server attaches a digital signature to the email header. The receiving server looks up the sender’s public cryptographic key in DNS and verifies the signature.
  • Header result: If the signature matches the message contents, DKIM passes (dkim=pass). If the message was modified or signed with an invalid key, DKIM fails.

3. DMARC (Domain-based Message Authentication, Reporting, and Conformance)

SPF and DKIM operate independently, but DMARC ties them together. DMARC tells the receiving server what to do if SPF or DKIM checks fail.

A domain owner can set a DMARC policy to one of three levels:

  • none: Collect reports, but deliver the email even if authentication fails.
  • quarantine: Send failed emails to the recipient’s Spam or Junk folder.
  • reject: Block failed emails completely before they reach the inbox.

DMARC also enforces alignment. This means the domain shown in the visible From: header must match the domain validated by SPF and DKIM.

Inspecting a Real Phishing Header

Let’s look at a practical example of a suspicious header to see how these pieces come together during an investigation.

Imagine a user receives an urgent email claiming their corporate account will be suspended unless they click a password reset link. The email appears to come from IT Support <support@example-company.com>.

Here is a simplified section of the header from that email:

Delivered-To: victim@example-company.com
Received: from mail-relay.target-domain.com (mail-relay.target-domain.com [203.0.113.10])
    by mx.target-domain.com with ESMTP id e12345
    for <victim@example-company.com>; Mon, 14 Sep 2026 09:14:22 -0400
Received: from mail.evil-attacker-host.net (mail.evil-attacker-host.net [198.51.100.45])
    by mail-relay.target-domain.com with ESMTP id a67890
    for <victim@example-company.com>; Mon, 14 Sep 2026 09:14:20 -0400
Authentication-Results: mx.target-domain.com;
    spf=fail (sender IP 198.51.100.45 is not authorized by domain of example-company.com) smtp.mailfrom=evil-attacker-host.net;
    dkim=none;
    dmarc=fail (p=QUARANTINE dis=QUARANTINE) header.from=example-company.com;
From: "IT Support" <support@example-company.com>
Reply-To: support-helpdesk-reset@gmail.com
To: victim@example-company.com
Subject: URGENT: Password Reset Required

Breaking Down the Findings:

  1. The Displayed Sender (From:):
    • Shows support@example-company.com. At first glance, it looks like an internal company message.
  2. The Actual Origin (Received:):
    • Reading the lowest Received: line, we see the email originated from server mail.evil-attacker-host.net at IP address 198.51.100.45. This host has no relation to example-company.com.
  3. Authentication Failures (Authentication-Results:):
    • SPF: Failed (spf=fail). The IP address 198.51.100.45 is not listed in example-company.com’s SPF record.
    • DKIM: None (dkim=none). The message had no cryptographic signature.
    • DMARC: Failed (dmarc=fail). Because the visible From: domain didn’t match the actual sending server, DMARC flagged it for quarantine.
  4. The Response Destination (Reply-To:):
    • While the message claims to come from IT support, replying to the message would send responses to an unrelated external Gmail address (support-helpdesk-reset@gmail.com).

Based on these header details, an analyst can immediately confirm this message is a spoofed phishing attempt.

Defensive Recommendations for Beginners

If you are just starting in security operations or managing IT for a small organization, here are key practices for dealing with email security:

  • Learn how to view raw headers in your client:
    • In Outlook: Open the email, click File > Info > Properties, and look at Internet headers.
    • In Gmail: Open the email, click the three vertical dots next to the reply button, and select Show original.
  • Use Header Analyzer Tools: If raw text headers are hard to read, paste them into free web utilities like Google Admin Toolbox Messageheader or Microsoft Message Header Analyzer. These tools format the routing steps and authentication details into clear charts.
  • Enforce Strong DMARC Policies: If you manage a domain, don’t leave your DMARC policy set to p=none permanently. Work toward setting it to p=quarantine or p=reject to protect your domain from being spoofed by outsiders.
  • Don’t Rely on Authentication Alone: Attackers sometimes register new domains (e.g., examp1e-company.com) and configure valid SPF, DKIM, and DMARC records for them. In that case, the technical authentication tests will pass, but the domain name itself is illegitimate. Always cross-reference the sender’s exact domain against expected business domains.

Summary

Email headers provide the underlying context needed to evaluate whether a message is authentic. While attackers can fake the display name and sender address shown in a mailbox, they cannot easily fake the server hops recorded in Received: lines or bypass strict SPF, DKIM, and DMARC checks.

By taking a moment to inspect raw headers when a message looks suspicious, you can quickly separate legitimate corporate communication from spoofed phishing attacks.

More Security Articles