Guide & Reference — how to read email headers and what this tool does
Every email carries a set of hidden metadata fields called headers. They are written by every mail server the message passes through and record the full journey from sender to recipient. Most email clients hide them by default — you usually only see From, To, Subject, and Date — but the raw headers contain significantly more information.
Headers are written in RFC 5322 format: one field per line, starting with the field name followed by a colon and the value. Multi-line values are continued with leading whitespace (folding). The most recent header is at the top; older ones are below.
Each Received: header is added by one mail server handing the message to the next.
Reading them from bottom to top gives you the complete delivery path.
Most header analyzers display the raw header values in a table or parse them into a flat list. This tool goes further: it resolves live DNS records, traces authentication chains, and decodes proprietary Microsoft 365 headers to explain not just what happened but why — and where exactly something went wrong.
The tool fetches the sender domain's live SPF record and renders each mechanism
as a color-coded token. The exact mechanism that matched the sending IP address —
whether a direct ip4:, an a: record, or a nested
include: — is highlighted in the record so you can see at a glance
why SPF passed or which rule caused it to fail.
When the matching mechanism is an include: directive the tool follows
the chain recursively, resolving each referenced domain's SPF record in turn until
it reaches the leaf mechanism that matched. The full include path is displayed
(e.g. include:spf.protection.outlook.com → ip4:40.92.0.0/15),
so you can confirm exactly which IP range authorized the sender.
When DMARC fails, the tool shows an alignment table: the From: header
domain is compared against the DKIM signing domain (d=) and the
SPF envelope-from domain. Each pair is labelled aligned or not aligned, so you can
see immediately whether the failure is a DKIM alignment issue, an SPF alignment issue,
or both. Remediation hints (e.g. configure a custom Return-Path CNAME) are shown inline.
For each DKIM-Signature: header the tool resolves
selector._domainkey.domain in real time to check whether the public key
still exists in DNS, has been revoked (empty p=), or was never published.
If the current DNS state differs from the delivery-time result the tool flags the
discrepancy — useful for diagnosing whether DKIM failed because of a signing error or
a key rotation that happened after delivery.
ARC (Authenticated Received Chain) allows intermediate mail handlers — mailing lists,
forwarding services — to preserve the original authentication results after they modify
a message. The tool displays the full ARC chain as a visual sequence of nodes
(i=1, i=2, …), each showing the chain-validation value
(cv=none/pass/fail) and the independent SPF/DKIM/DMARC results recorded
at that hop — separate from the final delivery authentication.
Microsoft 365 adds several proprietary headers that most analyzers ignore.
This tool decodes X-Forefront-Antispam-Report,
X-Microsoft-Antispam, and X-MS-Exchange-Organization-*
to show: whether Exchange classified the message as internal or external (AuthAs),
the Spam Confidence Level (SCL) and Bulk Complaint Level (BCL) with their meanings,
the spam filter verdict (SFV), and the message category (CAT). It also detects
hybrid on-premises scenarios from the FromEntityHeader value.
The delivery path is rendered as an interactive diagram showing each hop: the sending and receiving hostnames, IP addresses, timestamps, and delay between hops. IP addresses are classified as internal (RFC 1918 / link-local), Microsoft 365 infrastructure, or external. DNS resolution fills in missing IP addresses for hostnames that appear without one.
When a message arrives from an on-premises Exchange server through a Microsoft 365
hybrid connector, Exchange Online can misclassify it as anonymous (external) even
though it originates internally. The tool detects this pattern —
AuthAs=Anonymous combined with FromEntityHeader=HybridOnPrem
— and shows a warning with the likely causes and the impact on mail flow policies.
The most common fields you will encounter in email headers:
| Header | What it contains |
|---|---|
| Received: | Added by each mail server in the delivery path. Reading bottom-to-top gives the route. Contains sending host, receiving host, protocol, and timestamp. |
| Authentication-Results: | Summary of SPF, DKIM, and DMARC checks performed by the receiving server. The authoritative source for authentication pass/fail results. |
| DKIM-Signature: | Cryptographic signature over selected headers and the message body. Contains the signing domain (d=), selector (s=), algorithm (a=), and signed header list (h=). |
| ARC-Seal: | Part of the ARC set. Seals the ARC headers added at a given hop (i=) and carries the chain validation value (cv=). |
| ARC-Message-Signature: | Like a DKIM signature added by the intermediate handler, covering the message at the point of forwarding. |
| ARC-Authentication-Results: | Snapshot of authentication results (SPF, DKIM, DMARC) as seen by the intermediate handler before it modified or forwarded the message. |
| Return-Path: | The envelope sender (SMTP MAIL FROM) address. Used for SPF checking and bounce handling. May differ from the visible From: address. |
| Message-ID: | Globally unique identifier assigned by the originating server. Used for threading and tracing a specific message in logs. |
| X-Originating-IP: | IP address of the client that submitted the message to the first mail server. Useful for tracing the true origin of webmail-sent messages. |
| X-Forefront-Antispam-Report: | Microsoft 365 proprietary header. Contains the spam filter verdict (SFV), spam confidence level (SCL), category (CAT), client IP (CIP), country (CTRY), and several other filtering signals. |
| X-Microsoft-Antispam: | Microsoft 365 proprietary header. Contains the Bulk Complaint Level (BCL), used to classify bulk/newsletter mail separately from spam. |
| X-MS-Exchange-Organization-SCL: | The Spam Confidence Level as set or overridden by Exchange Online transport rules. Values range from -1 (bypass) to 9 (definite spam). |
| X-MS-Exchange-Organization-AuthAs: | Whether Exchange classified the sender as Internal or Anonymous (external). Used by mail flow rules to apply different policies to internal vs. external mail. |
SPF lets a domain owner publish, in DNS, which mail servers are authorized to send mail
on behalf of that domain. The receiving server checks the sending IP against the
TXT record at the domain used in the SMTP MAIL FROM command
(the envelope sender). Common mechanisms:
ip4:1.2.3.0/24 — authorize an IPv4 address or rangeip6:2001:db8::/32 — authorize an IPv6 address or rangea: / mx: — authorize IPs listed in A or MX recordsinclude:other.domain — pull in another domain's SPF record (used by ESPs like Microsoft 365, Google, SendGrid)~all — softfail: IPs not listed are probably not authorized (still delivered, tagged)-all — hardfail: IPs not listed are not authorized (should be rejected)
SPF alignment for DMARC: the envelope-from domain (checked by SPF)
must match the From: header domain at the organizational level.
Many ESPs send with their own return-path domain by default, breaking SPF alignment
unless you configure a custom Return-Path CNAME.
DKIM provides a cryptographic signature over the message. The sending server signs
selected headers and the body with a private key, and publishes the public key in DNS
at selector._domainkey.domain. Receiving servers verify the signature.
DKIM survives relaying and forwarding (as long as the signed headers and body are not
modified), unlike SPF which is tied to the sending IP.
DKIM alignment for DMARC: the signing domain (d= tag)
must match the From: header domain at the organizational level.
If your ESP signs with their own domain, DKIM alignment will fail even if the signature
is cryptographically valid.
DMARC ties SPF and DKIM together. A domain publishes a DMARC policy in DNS at
_dmarc.domain specifying what receivers should do with mail that fails
both SPF alignment and DKIM alignment: p=none (monitor only),
p=quarantine (move to spam), or p=reject (discard).
DMARC passes if at least one of SPF or DKIM passes with correct alignment.
When a mailing list or forwarding service re-sends a message it breaks SPF (new sending
IP) and often DKIM (modified subject or footers). ARC allows these intermediaries to
record a signed snapshot of the original authentication results. Each intermediate server
adds a set of three headers (ARC-Seal, ARC-Message-Signature,
ARC-Authentication-Results) with an instance number. The final receiver can
evaluate the ARC chain to decide whether to trust the original authentication even if
SPF and DKIM now fail.
.eml file directly.
All processing runs entirely in your browser. No email header data is sent to any server.
The only external requests are DNS lookups via Cloudflare's DoH endpoint
(cloudflare-dns.com), which resolve domain names but do not transmit the
header contents.
Ready to analyze your headers?
Open Email Header Analyzer