Email headers are metadata attached to every email that record who sent it, where it traveled, and whether it passed authentication checks. They are the single most useful diagnostic tool for troubleshooting deliverability, identifying phishing, and understanding why an email ended up in spam. If you have ever wondered why a legitimate message landed in junk, or whether a suspicious email is really from who it claims, headers hold the answers.

Key Takeaway

What email headers are

Email Headers

RFC 5322 · Metadata prepended by each server in the delivery chain

Every email consists of two parts: the headers and the body. The headers are a block of key-value pairs at the top of the raw message. Each mail server (MTA) the email passes through adds its own headers, creating a layered record of the message's journey. The body is everything below the blank line that separates headers from content.

Headers are defined by RFC 5322 (Internet Message Format). Every compliant email server writes and reads them in the same way. The original sender's mail client sets initial headers like From:, To:, Subject:, and Date:. As the message travels from server to server, each MTA prepends a Received: header recording its own identity, the previous server's identity, and a timestamp.

Headers are not visible by default in any major email client. You have to explicitly request the "raw" or "original" message view to see them. But they are always there, on every single email, and they cannot be retroactively stripped by intermediate servers without breaking cryptographic signatures like DKIM.

The most important headers explained

The table below covers every header you are likely to encounter when diagnosing an email issue. Some are set by the original sender, some by intermediate servers, and some by the final receiving server.

Header Set By What It Contains
From: Sender's mail client The display name and email address of the sender. This is what recipients see in their inbox. It can be spoofed without authentication protocols.
To: Sender's mail client The recipient's email address. May list multiple recipients. Does not include BCC recipients.
Subject: Sender's mail client The email subject line as typed by the sender.
Date: Sender's mail client The date and time the email was composed, in RFC 5322 format (e.g., Sat, 12 Apr 2026 09:30:00 -0700).
Received: Each MTA in the chain Records the server name, IP address, protocol (SMTP, ESMTPS), and timestamp for each hop. Read these bottom-to-top: the bottom Received: header is the first server, the top one is the last.
Return-Path: Final receiving MTA The envelope sender address (SMTP MAIL FROM). Set by the last server in the chain. SPF checks this address. A mismatch between Return-Path and From: is a phishing indicator.
Message-ID: Sender's mail server A globally unique identifier for the message (e.g., <[email protected]>). The domain portion should match the sending organization. Forged Message-IDs are a phishing signal.
Authentication-Results: Receiving mail server Contains SPF, DKIM, and DMARC verdicts (pass, fail, none) as defined by RFC 8601. This is the single most important header for diagnosing authentication issues.
DKIM-Signature: Sender's mail server The cryptographic signature fields: d= (signing domain), s= (selector), b= (signature data), bh= (body hash). Receiving servers use these to verify message integrity.
X-Mailer / User-Agent: Sender's mail client Identifies the sending software (e.g., Microsoft Outlook 16.0, Thunderbird 115.0). Useful for identifying the sending client or spotting spoofed clients.
Content-Type: Sender's mail client Specifies the body format: text/plain, text/html, or multipart/alternative for emails with both. Includes the character encoding (e.g., charset=UTF-8).
MIME-Version: Sender's mail client Almost always 1.0. Indicates the message follows the MIME standard for encoding attachments and non-ASCII content.
Reply-To: Sender's mail client Overrides the From: address when the recipient clicks Reply. Legitimate uses include mailing lists and shared inboxes. Often abused by phishers who set From: to a trusted domain but Reply-To: to an attacker-controlled address.
List-Unsubscribe: Sender's mail server Defined by RFC 2369. Provides a mailto: or HTTPS URL for one-click unsubscribe. Required by Google and Yahoo for bulk senders (5,000+ messages/day) since February 2024.

For a full overview of how SPF, DKIM, and DMARC work together, see our email authentication explained guide. For definitions of all email-related terms, see the email glossary.

How to access email headers

Every major email client lets you view the raw headers. The exact steps differ by platform.

Gmail (Web)

Open the email. Click the three-dot menu (top-right of the message). Select "Show original." Gmail displays the full raw headers along with a summary table showing SPF, DKIM, and DMARC results at the top. Click "Copy to clipboard" to paste into an analyzer tool.

Outlook on the Web (outlook.com / OWA)

Open the email. Click the three-dot menu (top-right). Select "View" > "View message source" (or "View message details" in some versions). The raw headers appear in a new window. Copy the full text for analysis.

Apple Mail (macOS)

Open the email. Go to View > Message > All Headers in the menu bar. Alternatively, use the keyboard shortcut Cmd + Shift + H to toggle the full header view. The headers appear directly above the message body.

Yahoo Mail (Web)

Open the email. Click the three-dot menu (top-right). Select "View raw message." The complete headers and raw source open in a new browser tab. Copy the content for analysis.

Once you have the raw headers, paste them into our Email Header Analyzer for an instant, structured breakdown of every field.

How to trace an email's route

The Received: headers form a chain that records every server the email passed through. Each MTA prepends its own Received: header at the top, which means you read the chain bottom-to-top: the bottom-most Received: header is the originating server, and the top-most is the final destination server.

Every Received: header follows the same general pattern:

Received: from [sending-server] by [receiving-server] with [protocol]; [timestamp]

Here is a simplified three-hop example:

Example Received Chain (read bottom-to-top)

Received: from mx2.google.com by mx.recipient.com with ESMTPS; Sat, 12 Apr 2026 09:30:05 -0700

Received: from mail-sor-f41.google.com by mx2.google.com with SMTP; Sat, 12 Apr 2026 09:30:03 -0700

Received: from [192.168.1.10] by mail-sor-f41.google.com with ESMTPSA; Sat, 12 Apr 2026 09:30:01 -0700

Reading bottom-to-top: the sender's device (192.168.1.10) submitted the email to Google's outbound server (mail-sor-f41.google.com) at 09:30:01. Google's internal routing moved it to mx2.google.com at 09:30:03. The recipient's server (mx.recipient.com) received it at 09:30:05. Total transit time: 4 seconds.

Time gaps matter. If you see a 30-minute gap between two consecutive Received: timestamps, that indicates the message was queued at an intermediate server. Common causes include greylisting (the receiving server temporarily rejected the message and the sender retried after a delay), rate limiting, or server overload. Large time gaps are the primary indicator of delivery delays.

How to read Authentication-Results

The Authentication-Results: header is added by the receiving mail server and summarizes the outcome of all authentication checks. It is defined by RFC 8601. Here is a real-world example:

Example Authentication-Results Header

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of [email protected] designates 198.51.100.25 as permitted sender) [email protected];
  dkim=pass header.d=example.com header.s=selector1 header.b=abc12345;
  dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

Breaking this down field by field:

Field Value in Example What It Means
spf=pass The sending IP (198.51.100.25) is authorized The sending server's IP address is listed in the domain's SPF record. The domain checked is the envelope sender (smtp.mailfrom).
dkim=pass Signature from example.com verified The DKIM cryptographic signature in the message is valid. header.d shows the signing domain, header.s the selector used to look up the public key.
dmarc=pass Policy satisfied, p=REJECT The DMARC check passed because either SPF or DKIM (or both) aligned with the From: domain. p=REJECT is the domain's published policy for failures. dis=NONE means no action was taken (because it passed).

All three passing means the email is fully authenticated. The sending server was authorized (SPF), the message was not tampered with in transit (DKIM), and both results aligned with the visible From: domain (DMARC). This is the ideal state for every email you send. Check your domain's current authentication status with our Email Health Score tool.

Identifying phishing from headers

Headers are the most reliable way to determine whether an email is legitimate. Phishing emails can convincingly replicate the visible parts of a message (sender name, logo, formatting), but they cannot fully fake the header chain without triggering authentication failures. Here are the red flags to look for.

Red Flag What to Look For Why It Matters
From: differs from Return-Path From: [email protected] but Return-Path: [email protected] The visible sender and the actual envelope sender are different. Legitimate services sometimes do this (e.g., SaaS platforms sending on your behalf), but combined with other red flags it strongly suggests spoofing.
Authentication failures spf=fail, dkim=fail, or dmarc=fail in Authentication-Results The email failed one or more authentication checks. A legitimate sender's email should pass all three. Multiple failures are a strong phishing indicator.
Suspicious Received chain IPs from unexpected countries; server names unrelated to the claimed sender If an email claims to be from a US-based bank but the Received chain shows servers in a completely different region, the routing does not match the supposed origin.
Forged Message-ID domain Message-ID: <[email protected]> but Received chain shows different servers The Message-ID domain should match the sending infrastructure. A mismatch indicates the attacker set the Message-ID manually to appear legitimate.
Reply-To mismatch From: [email protected] but Reply-To: [email protected] The attacker wants you to see a trusted domain in From: but redirect your replies to a domain they control. Always compare Reply-To with From:.

Multiple Red Flags = High Confidence

A single mismatch (like Return-Path differing from From:) can have legitimate explanations. But when you see two or more red flags together, especially authentication failures combined with routing anomalies, treat the email as malicious until proven otherwise.

X-headers: what they reveal

Headers prefixed with X- are non-standard, vendor-specific extensions. They are not required by any RFC, but many mail servers and spam filters add them. Here are the most commonly encountered X-headers and what they tell you.

X-Header Added By What It Reveals
X-Spam-Score SpamAssassin and similar filters A numeric score indicating spam likelihood. SpamAssassin's default threshold is 5.0: anything above that is classified as spam. Lower is better. A score of 0.5 is clean; 8.3 is almost certainly spam.
X-Spam-Status SpamAssassin Shows Yes or No along with the score and a list of triggered rules (e.g., HTML_MESSAGE, MISSING_DATE, RDNS_NONE). The rule names tell you exactly why the score was elevated.
X-Originating-IP Some webmail providers The IP address of the client that submitted the message (the sender's device). Useful for geolocation checks. If an email claims to be from your colleague in New York but the originating IP resolves to a different country, investigate further.
X-Mailer Sender's email client Identifies the software used to compose the email (e.g., Microsoft Outlook 16.0, Apple Mail). Phishing emails sometimes show unusual or outdated mail clients, or omit this header entirely.
X-Google-DKIM-Signature Google's mail servers An additional DKIM signature added by Google for internal verification. It uses Google's own key rather than the sender's domain key. Confirms the message passed through Google infrastructure.

X-headers are informational. Because they are non-standard, any server can add, modify, or remove them. Do not rely on X-headers alone for security decisions. Always cross-reference with the standard Authentication-Results header.

Troubleshooting deliverability with headers

When emails are delayed, bouncing, or landing in spam, headers provide the diagnostic data you need to identify the root cause. Here are the four most common issues and how headers expose them.

1. Delivery delays

Compare timestamps across consecutive Received: headers. Normal hop-to-hop transit takes milliseconds to a few seconds. A gap of 5 minutes or more between two hops indicates the message was queued. Common causes: greylisting (the receiving server issued a temporary rejection, forcing the sender to retry after a delay), rate limiting by the receiving server, or an overloaded mail queue on the sending side.

2. Routing loops

If the same server name appears multiple times in the Received: chain, the message was caught in a loop. Mail servers typically detect this and reject the message after a set number of hops (usually 25, per RFC 5321). Loops are caused by misconfigured mail routing rules, such as two servers forwarding to each other.

3. Authentication failures

Check Authentication-Results for spf=fail, dkim=fail, or dmarc=fail. Each failure has a specific cause:

4. Missing List-Unsubscribe header

Since February 2024, Google and Yahoo require bulk senders (5,000+ messages per day to Gmail/Yahoo addresses) to include a List-Unsubscribe header with a working one-click unsubscribe mechanism. Missing this header can cause bulk email to be routed to spam. Check your raw headers for List-Unsubscribe: and List-Unsubscribe-Post:. Both should be present. See our bulk sender requirements guide for the full compliance checklist.

For a comprehensive diagnosis of why emails are going to spam, see our complete troubleshooting guide.

36% of data breaches involved phishing (Verizon DBIR 2024)
94% of organizations experienced email phishing (Proofpoint 2024)
8.6M domains with DMARC records published (2025)

Paste-and-analyze tools

Reading raw headers manually is useful for understanding the structure, but for day-to-day troubleshooting you will want a tool that parses and visualizes the data. These free tools do that instantly:

Frequently asked questions

What are email headers and why should I read them?

Email headers are metadata lines attached to every email message. They record the sender, recipient, subject, date, and every server the message passed through on its way to your inbox. Headers also contain the results of authentication checks (SPF, DKIM, DMARC). Reading headers is the most reliable way to verify who actually sent an email, diagnose deliverability problems, identify phishing attempts, and understand why a message was flagged as spam.

How do I find email headers in Gmail?

Open the email in Gmail. Click the three-dot menu in the top-right corner of the message. Select "Show original." Gmail displays the full headers along with a summary showing SPF, DKIM, and DMARC results at the top. You can copy the raw headers and paste them into an email header analyzer tool for a more readable breakdown.

How can I tell if an email is a phishing attempt from its headers?

Look for these red flags: the From: address differs from the Return-Path (envelope sender), SPF/DKIM/DMARC results show "fail" or "none" in Authentication-Results, the Received chain includes unexpected server IPs or domains unrelated to the supposed sender, the Reply-To points to a completely different domain than From:, or the Message-ID domain does not match the sending organization. Any combination of these signals strongly suggests the email is not legitimate.

What does Authentication-Results: spf=pass dkim=pass dmarc=pass mean?

It means the email passed all three major authentication checks. spf=pass confirms the sending server's IP is authorized by the sender's domain. dkim=pass confirms the email's cryptographic signature is valid and the message was not altered in transit. dmarc=pass confirms that either SPF or DKIM (or both) aligned with the From: domain and the domain's DMARC policy was satisfied. When all three pass, the email is fully authenticated and far more likely to reach the inbox.