The complete technical guide to email headers for security analysis and forensics
For Security Professionals: This reference covers all major email headers used in authentication, routing, and threat analysis. Each header includes syntax, purpose, security implications, and red flags to watch for.
Essential headers that identify the message and its participants
Syntax:
From: Display Name <address@domain.com>Purpose:
Specifies the author and sender of the message. This is what recipients see in their inbox.
Security Implications:
Can be easily spoofed. The display name can say anything. Always verify the actual email address matches expected domain.
Standard:
RFC 5322
Examples:
From: "John Smith" <john@example.com>From: security@paypal.comRed Flags:
Syntax:
To: recipient@domain.comPurpose:
Specifies the primary recipient(s) of the message.
Security Implications:
Generally not spoofed, but BCC can hide additional recipients.
Standard:
RFC 5322
Examples:
To: user@example.comTo: "Jane Doe" <jane@company.com>, bob@company.comRed Flags:
Syntax:
Subject: Message topicPurpose:
Brief description of the message content.
Security Implications:
Common social engineering target - urgent/threatening subjects designed to bypass critical thinking.
Standard:
RFC 5322
Examples:
Subject: Quarterly ReportSubject: URGENT: Account Verification RequiredRed Flags:
Syntax:
Date: Day, DD Mon YYYY HH:MM:SS +ZONEPurpose:
When the message was composed by the sender.
Security Implications:
Can be forged. Compare with Received header timestamps for actual transmission time.
Standard:
RFC 5322
Examples:
Date: Mon, 15 Jan 2024 14:30:00 -0500Date: Tue, 3 Dec 2024 09:15:32 +0000Red Flags:
Syntax:
Message-ID: <unique-identifier@domain>Purpose:
Globally unique identifier for this message. Used for threading, duplicate detection, and forensics.
Security Implications:
Domain should match sender's mail server. Useful for tracking and correlation.
Standard:
RFC 5322
Examples:
Message-ID: <20240115143000.ABC123@mail.example.com>Message-ID: <CABcD1234@mail.gmail.com>Red Flags:
Headers that track the message's journey through mail servers
Syntax:
Received: from server by server; timestampPurpose:
Added by each mail server that handles the message. Read bottom-to-top to trace the email's path from sender to recipient.
Security Implications:
CRITICAL for forensics. Shows actual IP addresses, server names, and timing. Cannot be forged by sender.
Standard:
RFC 5322
Examples:
Received: from mail.example.com (mail.example.com [192.168.1.1]) by mx.gmail.com; Mon, 15 Jan 2024 14:31:05 -0500Red Flags:
Syntax:
Return-Path: <bounce-address@domain>Purpose:
Where bounce messages and delivery failures are sent. Also called 'envelope from' or 'MAIL FROM'.
Security Implications:
Often different from From header. Legitimate bulk email services use separate bounce addresses.
Standard:
RFC 5321
Examples:
Return-Path: <bounces@emailservice.com>Return-Path: <sender@example.com>Red Flags:
Syntax:
Reply-To: reply-address@domain.comPurpose:
Where replies should be sent (if different from From address).
Security Implications:
MAJOR phishing indicator when different from From address. Attackers use to harvest replies.
Standard:
RFC 5322
Examples:
Reply-To: support@company.comReply-To: attacker@gmail.comRed Flags:
Headers that verify sender identity and prevent spoofing
Syntax:
Authentication-Results: server; spf=pass dkim=pass dmarc=passPurpose:
Results of email authentication checks (SPF, DKIM, DMARC) performed by receiving server.
Security Implications:
CRITICAL for phishing detection. These are CLAIMS by the receiving server, not independently verified.
Standard:
RFC 8601
Examples:
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=passRed Flags:
Syntax:
Received-SPF: pass/fail/softfailPurpose:
SPF (Sender Policy Framework) check result. Verifies sending server is authorized for that domain.
Security Implications:
Pass means server is in domain's SPF record. Fail means spoofing attempt or misconfiguration.
Standard:
RFC 7208
Examples:
Received-SPF: pass (google.com: domain of sender@example.com designates 192.168.1.1 as permitted sender)Red Flags:
Syntax:
DKIM-Signature: v=1; a=rsa-sha256; d=domain.com; s=selector; ...Purpose:
Cryptographic signature proving message hasn't been altered and comes from claimed domain.
Security Implications:
Very difficult to forge. DKIM pass is strong authentication signal.
Standard:
RFC 6376
Examples:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=default; ...Red Flags:
Syntax:
ARC-Authentication-Results: i=N; server; resultsPurpose:
Authenticated Received Chain - preserves authentication results through mailing lists and forwarders.
Security Implications:
Newer standard to solve DMARC issues with email forwarding.
Standard:
RFC 8617
Examples:
ARC-Authentication-Results: i=1; mx.google.com; spf=passRed Flags:
Headers describing message content and structure
Syntax:
Content-Type: text/html; charset=UTF-8Purpose:
Describes the type of content (text, HTML, multipart) and character encoding.
Security Implications:
Multipart messages can hide malicious content. HTML can contain tracking pixels and malicious scripts.
Standard:
RFC 2045
Examples:
Content-Type: text/plain; charset=UTF-8Content-Type: text/html; charset=iso-8859-1Content-Type: multipart/alternative; boundary=boundary123Red Flags:
Syntax:
MIME-Version: 1.0Purpose:
Indicates the message uses MIME (Multipurpose Internet Mail Extensions) format.
Security Implications:
Should always be 1.0. Absence or other values indicate unusual/old mail clients.
Standard:
RFC 2045
Examples:
MIME-Version: 1.0Red Flags:
Syntax:
Content-Transfer-Encoding: base64/quoted-printable/7bit/8bitPurpose:
How the message body is encoded for transmission.
Security Implications:
Base64 can hide malicious content from simple scanners.
Standard:
RFC 2045
Examples:
Content-Transfer-Encoding: quoted-printableContent-Transfer-Encoding: base64Red Flags:
Headers added by spam filters and security systems
Syntax:
X-Spam-Status: Yes/No, score=X.XPurpose:
Spam filter verdict and score. Higher scores indicate more spam-like characteristics.
Security Implications:
Useful indicator but not definitive. Sophisticated phishing can have low spam scores.
Standard:
N/A (SpamAssassin convention)
Examples:
X-Spam-Status: No, score=-0.1 required=5.0X-Spam-Status: Yes, score=8.5 required=5.0Red Flags:
Syntax:
X-Microsoft-Antispam: BCL:X; SCL:X; ...Purpose:
Microsoft's spam and bulk mail indicators. BCL = Bulk Confidence Level, SCL = Spam Confidence Level.
Security Implications:
Microsoft-specific scoring. BCL 9 = definite bulk, SCL 9 = definite spam.
Standard:
N/A (Microsoft proprietary)
Examples:
X-Microsoft-Antispam: BCL:0; SCL:1Red Flags:
Syntax:
X-Forefront-Antispam-Report: CIP:IP; CTRY:XX; ...Purpose:
Detailed Microsoft anti-spam analysis including IP, country, authentication results.
Security Implications:
Rich forensic data. CIP = connecting IP, CTRY = country, LANG = language.
Standard:
N/A (Microsoft proprietary)
Examples:
X-Forefront-Antispam-Report: CIP:192.168.1.1; CTRY:US; LANG:en;Red Flags:
Headers used for tracking, threading, and privacy
Syntax:
List-Unsubscribe: <mailto:unsub@domain>, <http://domain/unsub>Purpose:
Provides unsubscribe mechanism for bulk mail. Required by many email services.
Security Implications:
Legitimate bulk mailers include this. Absence suggests spam or phishing.
Standard:
RFC 2369
Examples:
List-Unsubscribe: <mailto:unsub@newsletter.com>List-Unsubscribe: <https://example.com/unsubscribe?id=123>Red Flags:
Syntax:
Precedence: bulk/list/junkPurpose:
Indicates message priority and type. 'bulk' = mass mailing.
Security Implications:
Helps identify legitimate bulk mail vs spam.
Standard:
N/A (convention)
Examples:
Precedence: bulkPrecedence: listRed Flags:
Syntax:
In-Reply-To: <message-id>Purpose:
Links replies to original messages for threading.
Security Implications:
Can be forged to make message appear as continuation of conversation.
Standard:
RFC 5322
Examples:
In-Reply-To: <original-message-id@server.com>References: <msg1@server.com> <msg2@server.com>Red Flags:
Start with Authentication Headers
Check SPF, DKIM, and DMARC results first. These are your primary spoofing indicators.
Trace the Received Chain
Read Received headers bottom-to-top. Verify the origin matches the claimed sender.
Compare From vs Return-Path vs Reply-To
Mismatches between these headers are major phishing indicators.
Check Timestamps
Compare Date header with Received timestamps. Large discrepancies suggest forgery.
Verify Geographic Consistency
Check if routing path and timezones match claimed sender location.
Use Multiple Tools
Combine header analysis with content inspection and link checking for complete assessment.