Every email you receive carries a hidden payload of technical metadata in the email header. While most people never look past the From and Subject lines, the full header tells the complete story of an email’s journey: where it actually originated, how it was authenticated, whether it was encrypted in transit, and whether it might be spoofed or fraudulent.
Whether you’re a marketer troubleshooting deliverability, an IT professional investigating a phishing attempt, or just curious about how email works under the hood, understanding headers gives you a powerful diagnostic tool.
Paste your email header below to get a full breakdown instantly.
Paste Email Header
Analyze Email Header
Clear
Analyzing header…
How to Copy Your Email Headers
Apple Mail
Open the email.
Go to View → Message → All Headers (or press ⇧⌘H).
Copy the full header text displayed above the message body.
Gmail
Open the email.
Click the three-dot menu (⋮) in the top-right corner of the message.
Select Show original.
Copy the full header text displayed at the top of the page.
Outlook (Web)
Open the email.
Click the three-dot menu (···) at the top of the message.
Select View → View message source.
Copy all the text.
Outlook (Desktop)
Double-click the email to open it in its own window.
Go to File → Properties.
Copy the text from the Internet headers box at the bottom.
How To Read An Email Header
Email headers are governed by RFC 5322 (the modern successor to the original RFC 822, published in 1982). This standard defines the format of Internet message headers as a series of field-value pairs, each on its own line, that record metadata about the message’s composition, routing, and authentication. Every email client and mail server along the delivery path can add or modify headers, creating a layered record that is read from bottom to top in chronological order.
Let’s walk through each section of a parsed email header.
Envelope & Routing
This section reveals the actual delivery path of the email, which often differs from what’s displayed in your inbox.
Return-Path is the address where bounces and delivery failure notifications are sent. It’s set by the sending mail server during the SMTP transaction and doesn’t have to match the visible “From” address. Bulk email services almost always use their own bounce-handling address here (e.g., bounces-436860190@aa.d.sender-sib.com), which allows them to process delivery failures programmatically.
Delivered-To is the final recipient address where the email landed. This is added by the receiving mail server and confirms the actual mailbox that accepted the message.
From, To, Date, Subject, and Message-ID are the core identity headers defined by RFC 5322. The Message-ID is a globally unique identifier assigned to the email at the time it’s created, typically formatted as a random string followed by the sending server’s domain (e.g., <202603020349.78576606253@smtp-relay.mailin.fr>). No two emails should ever share a Message-ID.
MIME Information
MIME (Multipurpose Internet Mail Extensions) headers extend the original plain-text-only email format defined in RFC 822 to support rich content — HTML, attachments, images, and character sets beyond ASCII.
MIME-Version is almost always 1.0. Its presence signals that the message uses MIME formatting.
Content-Type specifies the format of the message body. A value of text/html; charset=utf-8 means the email body is HTML-encoded using UTF-8 character encoding, which supports virtually every written language. Multipart emails (those containing both plain text and HTML, or attachments) use types like multipart/alternative or multipart/mixed, with a boundary string separating each part.
Content-Transfer-Encoding defines how the message body is encoded for safe transit through mail servers that may only support 7-bit ASCII. quoted-printable is common for HTML emails — it keeps most readable characters intact while encoding special characters as =XX hex pairs. The other common encoding is base64 typically used for binary attachments.
Received Chain (Routing Hops)
This is arguably the most revealing section of any email header. Each Received header represents one hop in the email’s journey from sender to recipient. Mail servers prepend these headers as the message passes through, so the most recent hop is at the top, and the original sending server is at the bottom.
Each Received header typically contains:
from: the server that handed off the message (its hostname and IP address)
by: the server that received the message
with: the protocol used (eg. SMTP)
for: the intended recipient
timestamp: when the hop occurred
Reading the chain from bottom to top, you can trace the email’s complete path. For example, an email might originate at an ESP’s outbound relay (like aa.d.sender-sib.com at IP 185.41.28.128), travel via ESMTPS (SMTP with TLS encryption) to Google’s mail exchange server (mx.google.com), and finally be delivered internally to the recipient’s mailbox.
Why this matters: If an email claims to be from a major bank but the Received chain shows it originated from an unrelated IP address or an unknown server in an unexpected country, that’s a strong phishing indicator. The Received chain is much harder to forge than the “From” address.
Encryption indicators in this section are also critical. Look for ESMTPS or explicit TLS cipher details (e.g., TLS1_3 cipher=TLS_AES_256_GCM_SHA384), which confirms the message was encrypted between those two hops. Hops uses plain SMTP transmission to transmit the message in cleartext, meaning it could have been intercepted.
Authentication & Security
Modern email relies on three interlocking authentication protocols to fight spoofing and phishing. All three should pass as legitimate emails.
SPF (Sender Policy Framework)
SPF allows a domain owner to publish a DNS record listing which IP addresses are authorized to send email on behalf of that domain. When a receiving server gets an email, it checks the sending IP against the SPF record for the domain in the Return-Path.
A result of spf=pass means the sending IP was authorized. A fail or softfail means it wasn’t, which is a red flag for spoofing.
DKIM (DomainKeys Identified Mail)
DKIM adds a cryptographic signature to the email header. The sending server signs the message using a private key, and the receiving server verifies it using a public key published in the sender’s DNS records.
Key fields in the DKIM-Signature header include:
d= — the signing domain (e.g., aifamous.ai)
s= — the selector, which identifies which DNS key record to use (e.g., brevo1)
h= — the list of headers included in the signature (from, subject, date, to, etc.)
b= — the actual cryptographic signature
bh= — a hash of the message body
A dkim=pass result means the signature was valid — the message wasn’t tampered with in transit, and the signing domain vouches for it. A failure suggests the message was altered or the signature was forged.
DMARC (Domain-based Message Authentication, Reporting & Conformance)
DMARC ties SPF and DKIM together and adds a policy layer. It requires that either SPF or DKIM (or both) pass and align with the domain in the visible From header. This prevents an attacker from passing SPF with their own domain while spoofing the From address.
The DMARC result includes:
p= — the domain owner’s requested policy: NONE (monitor only), QUARANTINE (send to spam), or REJECT (block entirely)
sp= — the policy for subdomains
dis= — the disposition (what the receiving server actually did)
A dmarc=pass with p=NONE means the email passed alignment checks but the domain owner hasn’t yet enforced a strict policy. Domains with p=REJECT have the strongest protection against spoofing.
ARC (Authenticated Received Chain)
ARC is a newer protocol designed to preserve authentication results when messages pass through intermediaries like mailing lists or forwarding services — scenarios that often break SPF and DKIM. ARC headers (ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results) create a chain of custody, with each intermediary adding a signed set indicating i=1, i=2, etc. The cv= (chain validation) field shows whether the previous links were valid (pass) or if this is the first link (none).
Delivery, Spam & List Headers
These headers control how the email interacts with spam filters, mailing list infrastructure, and recipient mail clients.
X-Received is Google’s internal tracking header, recording the specific server and timestamp for internal routing within Gmail’s infrastructure.
List-Unsubscribe provides a URL (and sometimes a mailto: address) that email clients can use to offer a one-click unsubscribe button. This is required by RFC 8058 and is now enforced by Gmail and Yahoo for bulk senders. The companion List-Unsubscribe-Post header with the value List-Unsubscribe=One-Click signals support for the one-click HTTP POST method of unsubscription, which is the preferred mechanism because it doesn’t require the user to visit a webpage.
Feedback-ID is used by email service providers (ESPs) to track feedback loops — specifically, when recipients mark emails as spam. The structure typically encodes the sending IP, campaign ID, and ESP identifier, allowing the sender to identify and suppress problematic campaigns.
Additional / Custom Headers
Headers prefixed with X- are non-standard, custom headers. They aren’t defined by any RFC but are widely used by ESPs, security tools, and internal systems.
X-Api-Version indicates which version of the ESP’s API was used to send the message.
Origin-MessageID is the original Message-ID assigned by the ESP’s internal relay before any rewriting occurs.
X-Mailin-Eid is a Base64-encoded tracking identifier used by Brevo (formerly Sendinblue) to link the email to a specific send event, recipient, and account.
X-Sib-Id is another Brevo-specific tracking identifier used for internal delivery analytics.
X-Csa-Complaints points to the Certified Senders Alliance complaint address (csa-complaints@eco.de), indicating the sender participates in the CSA program — a European email deliverability certification that requires adherence to anti-spam best practices.
What to Look For: Quick Diagnostic Checklist
When analyzing an email header, focus on these key questions:
Does SPF, DKIM, and DMARC all pass? If any fail, the email may be spoofed or misconfigured.
Is the Received chain consistent with the claimed sender? Trace the origin IP and server hostnames to verify they match the sending domain or its known ESP.
Was the email encrypted in transit? Look for ESMTPS and TLS cipher details in the Received headers.
Does the Return-Path match the From domain? A mismatch isn’t always malicious (ESPs commonly use their own bounce domains), but combined with authentication failures, it’s suspicious.
Is there a valid List-Unsubscribe header? Legitimate bulk senders include this. Its absence in a marketing email is a deliverability red flag and may indicate spam.
Email headers are the closest thing email has to a flight recorder. Learning to read them transforms you from a passive recipient into an informed one — able to verify authenticity, diagnose delivery problems, and spot threats before they land in your inbox.
©2026 DK New Media, LLC, All rights reserved | DisclosureOriginally Published on Martech Zone: App: Email Header Analyzer