Email Header Analysis

// What are Email Headers?

Email headers are metadata prepended to every email. They contain the complete delivery path, sender information, authentication results, timestamps, and technical details about the message. The email client hides them by default � but for security analysis, they are essential.

Headers are added at each hop as the email travels from the sender's mail client ? sender's mail server ? intermediate relays ? recipient's mail server ? recipient's inbox. Each server prepends its own Received: header, building a chain from destination back to origin.

How to view headers

// The Received Chain

The most important part of the header for tracing email origin. Each mail server adds a Received: header at the top as the message passes through. Because each new header is prepended, the chain reads bottom to top � the bottom entry is where the email originated, the top entry is where it was delivered.

Anatomy of a Received header

Received: from mail.evil.com (mail.evil.com [185.220.101.42])
        by mx.victim.org (Postfix) with ESMTP id A3F2B1C4D5
        for <user@victim.org>; Mon, 15 Jan 2024 09:32:11 +0000 (UTC)

// Key Header Fields

// SPF � Sender Policy Framework

SPF is a DNS TXT record that lists the IP addresses and mail servers authorised to send email on behalf of a domain. When a receiving server gets an email, it checks whether the sending IP is listed in the sender domain's SPF record.

SPF record example

v=spf1 include:_spf.google.com include:mailgun.org ip4:203.0.113.10 -all

SPF results

// DKIM � DomainKeys Identified Mail

DKIM adds a cryptographic signature to outgoing emails. The sending server signs the email headers and body with a private key. The public key is published in DNS, and receiving servers use it to verify the signature � proving the email was sent by a server with access to the domain's private key and hasn't been modified in transit.

DKIM-Signature header

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=example.com; s=selector1;
        h=from:to:subject:date:message-id;
        bh=2jUSOH9NhtIezdxbLPkV5MrHqkRs8/4+MNaJ2SY6TdU=;
        b=AuUoFEfDxTDkHlLXSZEpZj79LICEpsvy98LdGvqD...

// DMARC � Domain-based Message Authentication

DMARC ties SPF and DKIM together and adds a policy telling receiving servers what to do if checks fail. It requires alignment � the domain in the From: header must align with the domain used in SPF and/or DKIM. This closes the gap where SPF and DKIM could pass even for spoofed From: addresses.

DMARC record example

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; pct=100; adkim=s; aspf=s

// Authentication-Results Header

The receiving mail server writes the results of SPF, DKIM, and DMARC checks into an Authentication-Results: header. This is the quickest way to see the authentication verdict at a glance.

Authentication-Results: mx.victim.org;
    dkim=pass header.i=@example.com header.s=selector1;
    spf=pass (mx.victim.org: domain of sender@example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=sender@example.com;
    dmarc=pass action=none header.from=example.com

Authentication-Results: mx.victim.org;
    dkim=none;
    spf=fail (mx.victim.org: domain of noreply@paypal.com does not designate 185.220.101.42 as permitted sender) smtp.mailfrom=noreply@paypal.com;
    dmarc=fail action=reject header.from=paypal.com

// Identifying Spoofing & Phishing

Once you can read headers, here is what to look for when investigating a suspicious email.

// Extracting IOCs

From a suspicious email, these are the IOCs to extract for further investigation and threat intel lookups.

// Analysis Tools