- Email headers are hidden metadata attached to every email that record the message's full journey from sender to recipient.
- Headers contain authentication results (SPF, DKIM, DMARC), routing hops, spam scores, and delivery diagnostics that are essential for troubleshooting.
- The "Received" fields trace each server hop in reverse chronological order, helping you identify delays and routing issues.
- Authentication-Results and ARC headers reveal whether your emails pass or fail security checks at the receiving end.
- Online header analyzer tools parse complex headers into readable formats, making diagnosis faster and more accessible.
When an email lands in spam instead of the inbox, or bounces back with a cryptic error code, the first place to look for answers is the email header. Every email carries a hidden block of metadata that records exactly what happened during transmission: which servers handled the message, whether authentication checks passed, how spam filters scored the content, and where things went wrong if delivery failed.
For email marketers, IT administrators, and deliverability professionals, learning to read email headers is one of the most valuable diagnostic skills you can develop. Headers turn guesswork into precise troubleshooting, helping you identify whether a problem is caused by DNS misconfiguration, authentication failure, content filtering, or server-side issues.
This guide will walk you through every important component of an email header, show you how to access headers in popular email clients, and demonstrate how to use header data to diagnose and resolve common deliverability problems.
What Are Email Headers?
An email header is a block of structured metadata that accompanies every email message. While the email body contains the visible content (text, images, links), the header contains technical information about the message's origin, routing, authentication, and handling. Headers are generated automatically by the sending server and augmented by each server that processes the message along the way.
Think of headers as a passport for your email. Every border crossing (server hop) gets stamped, every security check gets recorded, and the entire travel history is preserved for anyone who knows how to read it.
Headers are not visible in the normal email view. You have to specifically request to see the "raw" or "original" message in your email client to access them. Once you do, you will see a block of text that looks intimidating at first, but follows a consistent, readable structure once you know what to look for.
How to View Email Headers
Every major email client provides a way to view the full headers of a message. Here is how to access them in the most common platforms.
Gmail (Web)
Open the email, click the three-dot menu icon in the upper right corner of the message, and select "Show original." This opens a new tab displaying the full raw message including all headers. Gmail also provides a summary showing SPF, DKIM, and DMARC results at the top.
Microsoft Outlook (Web)
Open the email, click the three-dot menu at the top of the message, and select "View" then "View message source" or "View message details." The exact wording varies by Outlook version, but it will display the complete header block.
Apple Mail
Open the email, go to View in the menu bar, and select "Message" then "All Headers." Alternatively, you can select "Raw Source" to see the complete raw message.
Yahoo Mail
Open the email, click the three-dot menu, and select "View raw message." The full header will be displayed in a new window.
Once you have the raw headers, paste them into our Email Header Analyzer for an instant, structured breakdown of authentication results, routing hops, and potential issues. It is much faster than reading raw headers manually.
Anatomy of an Email Header: Key Fields Explained
Email headers contain dozens of fields, but only a subset are critical for deliverability analysis. Here are the fields you need to understand, grouped by function.
Sender and Recipient Fields
From: The email address displayed to the recipient as the sender. This is the address visible in the inbox and the one that DMARC validates against. It can be different from the actual technical sender.
To: The intended recipient's address.
Reply-To: The address that receives replies if different from the From address. Commonly used in marketing emails where the From address is a no-reply address but replies should go to a support team.
Return-Path: Also known as the envelope sender or bounce address. This is the address that receives bounce notifications (NDRs). SPF validation checks against this domain. If your Return-Path domain does not align with your From domain, it can cause DMARC alignment failures.
Routing and Delivery Fields
Received: These are the most important fields for tracing an email's journey. Every server that handles the message adds a Received header at the top. They are read from bottom (first hop) to top (last hop), creating a complete trail of the message's route. Each Received field typically includes the server name, IP address, protocol used, and timestamp.
Here is what a typical Received header looks like:
Received: from mail-sender.example.com (mail-sender.example.com [203.0.113.25])
by mx.recipient.com with ESMTPS id abc123
for <user@recipient.com>;
Mon, 24 Feb 2026 10:30:15 -0500 (EST)This tells you: the sending server (mail-sender.example.com), its IP address (203.0.113.25), the receiving server (mx.recipient.com), the protocol (ESMTPS, indicating TLS encryption was used), and the exact timestamp of the handoff.
Message-ID: A unique identifier for the message, generated by the sending server. Useful for tracking a specific message across logs and systems.
Date: The timestamp when the message was composed or submitted for sending.
Authentication Fields
These fields are critical for deliverability troubleshooting. They record the results of authentication checks performed by receiving servers.
Authentication-Results: This header is added by the receiving server and summarizes the results of all authentication checks in one place. A typical Authentication-Results field looks like this:
Authentication-Results: mx.google.com;
dkim=pass header.d=example.com header.s=selector1;
spf=pass (google.com: domain of bounce@example.com designates 203.0.113.25 as permitted sender) smtp.mailfrom=bounce@example.com;
dmarc=pass (p=REJECT sp=REJECT) header.from=example.comThis tells you that DKIM passed with the signing domain example.com, SPF passed because the sending IP is authorized for the Return-Path domain, and DMARC passed with a policy of reject. All green, all good.
Tip: When troubleshooting deliverability, the Authentication-Results header should be the first thing you check. If any of the three protocols show "fail" or "softfail," that is likely contributing to spam placement. Use our DKIM checker and DMARC checker to verify your records.
DKIM-Signature: Added by the sending server, this contains the cryptographic signature that receiving servers use to verify message integrity. The key fields within it are d= (signing domain), s= (selector, used to look up the public key), and h= (which headers are included in the signature).
Received-SPF: Some servers add this field specifically for SPF results. It duplicates information from Authentication-Results but in a dedicated field. It shows pass, fail, softfail, neutral, or none along with the checked domain and IP.
ARC (Authenticated Received Chain): ARC headers preserve authentication results across forwarding. When a message is forwarded through a mailing list or forwarding service, the original SPF and DKIM may break. ARC headers record the authentication state at each hop, allowing the final receiver to trust that the message was authenticated at an earlier point even if direct checks now fail.
Spam Filtering Fields
X-Spam-Status: Added by spam filtering systems (commonly SpamAssassin), this shows the spam score and which rules were triggered. A typical entry might read: X-Spam-Status: No, score=1.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS. This tells you the message scored 1.2 (well below the 5.0 spam threshold) and lists the specific tests that contributed to the score.
X-MS-Exchange-Organization-SCL: Microsoft's Spam Confidence Level, a score from -1 to 9. Lower is better: -1 means trusted sender, 0-1 is likely legitimate, and 5+ is increasingly likely to be spam. Values of 5 or 6 typically result in junk folder placement.
X-Google-DKIM: Specific to Gmail infrastructure, this may appear in headers of messages processed by Google's systems and provides additional DKIM verification details.
Using Headers to Troubleshoot Deliverability Issues
Now that you understand the key fields, here is how to apply that knowledge to real-world problems.
Problem: Emails Landing in Spam
Check the Authentication-Results header first. Look for any "fail" or "softfail" entries. Common findings include SPF failures because the sending IP is not included in your SPF record, DKIM failures because the signing key does not match the published DNS record, or DMARC failures due to alignment issues between the From domain and the SPF/DKIM domains. If authentication passes but emails still hit spam, check X-Spam-Status for content-based triggers.
Problem: Delayed Email Delivery
Compare timestamps across Received headers from bottom to top. Each hop should add only seconds of delay. If you see a gap of minutes or hours between two consecutive hops, that server is the bottleneck. Common causes include greylisting (which forces a deliberate delay on first contact), overloaded mail servers, or DNS resolution delays.
Problem: Emails Rejected or Bounced
When an email bounces, the bounce notification (NDR) itself contains headers that explain the rejection. Look for SMTP status codes in the Received or diagnostic fields. Codes starting with 4xx indicate temporary failures that may resolve on retry. Codes starting with 5xx indicate permanent failures. Check our bounce code reference for detailed explanations of specific error codes.
| Header Field | What It Tells You | Common Issues Found |
|---|---|---|
| Authentication-Results | SPF, DKIM, DMARC pass/fail status | Misconfigured DNS records, alignment failures |
| Received (chain) | Server-by-server routing path with timestamps | Delivery delays, greylisting, suspicious routing |
| Return-Path | Envelope sender and bounce destination | SPF/DMARC alignment mismatches |
| X-Spam-Status | Spam score and triggered filter rules | Content-based filtering, URL blocklisting |
| DKIM-Signature | Signing domain and key selector | Expired keys, wrong selector, broken signatures |
| X-MS-Exchange-Organization-SCL | Microsoft spam confidence level | High SCL triggering junk folder placement |
Email Header Analyzer Tools
Reading raw headers manually is possible but time-consuming, especially for complex messages that pass through multiple servers. Header analyzer tools parse the raw text into a structured, visual format that highlights the important information and flags potential problems.
SenderReputation.org Header Analyzer
Our Email Header Analyzer parses headers and displays authentication results, routing hops, and delivery details in a clean, readable format. It highlights SPF, DKIM, and DMARC results prominently and flags any issues that could affect deliverability.
Google Admin Toolbox (Messageheader)
Google's free tool at toolbox.googleapps.com/apps/messageheader provides hop-by-hop analysis with delivery delay calculation. It is particularly useful for identifying where in the routing chain a delay occurred.
MXToolbox Header Analyzer
MXToolbox parses headers according to RFC 822 and provides a detailed breakdown with hop delays, anti-spam results, and blacklist cross-references.
To troubleshoot a deliverability issue using headers: (1) View the original/raw message in your email client, (2) Copy the full header text, (3) Paste it into a header analyzer tool, (4) Check Authentication-Results for SPF/DKIM/DMARC failures, (5) Review Received hops for delays or suspicious routing, and (6) Examine spam filter scores for content triggers.
Best Practices for Email Header Configuration
While many header fields are generated automatically by your mail server, there are several areas where proper configuration directly impacts deliverability.
Align Your From and Return-Path Domains
Ensure that the domain in your visible From address matches (or is a subdomain of) the domain used in the Return-Path header. This alignment is required for DMARC to pass via SPF. Many ESPs use their own domain for Return-Path by default; configure custom Return-Path to match your sending domain.
Implement List-Unsubscribe Headers
Include the List-Unsubscribe and List-Unsubscribe-Post headers in your marketing emails. These enable the one-click unsubscribe functionality that Gmail and Yahoo now require from bulk senders. The header should point to a mailto: address or an HTTPS URL that processes the unsubscribe request instantly.
Use TLS Encryption
Ensure your mail server supports STARTTLS so that messages are encrypted in transit. You can verify this by checking Received headers for "ESMTPS" (encrypted) versus "ESMTP" (unencrypted). Gmail flags messages sent without TLS with a warning icon, and encryption status is a factor in spam filtering decisions.
Set Proper Content-Type Headers
Use Content-Type: text/html; charset=UTF-8 for HTML emails and always include a plain-text MIME part as a fallback. Malformed Content-Type headers or missing character encoding can trigger spam filters and cause rendering issues across different email clients.
According to recent deliverability research, email header analysis can identify the root cause of spam placement approximately 80% of the time. Authentication failures, content triggers, and routing anomalies leave clear traces in the headers that point directly to the problem.
Using Headers for Security and Phishing Detection
Email headers are also a powerful tool for detecting phishing and spoofing attempts. When you receive a suspicious email, checking the headers can reveal whether the sender is who they claim to be.
Look for these red flags: a From address that does not match the domain in the Received chain, SPF or DKIM failures in Authentication-Results, a Return-Path domain that is completely different from the From domain, Received headers showing the email originated from an unexpected country or server, and missing or forged DKIM signatures.
If the Authentication-Results show dmarc=fail, it means the email failed domain verification and may be a spoofed message. This is exactly why DMARC enforcement (p=reject) is so important; it instructs receiving servers to reject messages that fail these checks rather than delivering them.
Frequently Asked Questions
Some header fields like From and Reply-To can be set to arbitrary values by the sender, which is the basis of email spoofing. However, Received headers added by intermediate and receiving servers, along with Authentication-Results, are controlled by those servers and are reliable. This is why SPF, DKIM, and DMARC exist: they provide a verifiable chain of trust that cannot be forged by the sender.
Each server that processes the email adds its Received header at the top of the existing header block. This means the first server to handle the message has its header at the bottom, and the last server (the one that delivered it to your inbox) has its header at the top. Reading from bottom to top traces the message in chronological order from origin to destination.
An SPF softfail (indicated by ~all in the SPF record) means the sending IP is not authorized by the domain's SPF record, but the domain owner has not made a definitive statement about rejection. It is treated as a negative signal but is less severe than a hard fail (-all). Most DMARC implementations treat softfail the same as fail for alignment purposes. Senders should audit their SPF record to ensure all legitimate sending IPs are included.
Look at the Received headers in a delivered test email. If the connection used encryption, you will see "ESMTPS" (SMTP over TLS) or "with TLS" in the Received field. If you see plain "ESMTP" or "SMTP" without any TLS indicator, the connection was unencrypted. Google Postmaster Tools also reports what percentage of your emails are sent with TLS encryption.
Headers contain technical metadata such as server names, IP addresses, timestamps, and email addresses involved in the transaction. They do not contain the email body content. However, the originating IP address could potentially reveal the sender's approximate location if they sent from a personal mail client rather than a cloud-based service. When sharing headers for troubleshooting, be aware that they may contain email addresses and server details.