Paste raw email headers to instantly parse authentication results, trace mail server hops, and diagnose SPF, DKIM, and DMARC failures.
What are email headers?
Every email has two parts: the body which is the content you see, and the headers, which are hidden metadata that travel with the message. Headers are plain-text fields added by each mail server that touches the message on its way from sender to recipient. They record who sent it, who it’s addressed to, which servers handled it, when each handoff happened, and whether it passed authentication checks.
Most email clients hide headers by default. They are the raw technical layer beneath the readable email — and when something goes wrong with delivery, authentication, or spam filtering, headers are where the answer is.
What information is in an email header?
Headers are structured as Field-Name: value pairs, one per line, at the top of the raw message. A typical email contains 20–40 header fields. The most diagnostically useful ones are:
| Field | What it contains | Diagnostic use |
|---|---|---|
| From: | The visible sender address shown in email clients. | Verify this matches the Return-Path — a mismatch is a spoofing signal. |
| Return-Path: | The envelope sender — where bounces are delivered. | Should align with the From domain for DMARC to pass. |
| Received: | One entry added by each mail server that handled the message. | Reading bottom-to-top reconstructs the delivery route and timestamps. |
| Message-ID: | A globally unique identifier assigned by the originating server. | Used to track a specific message across logs and support tickets. |
| Date: | Timestamp of when the message was sent. | Compare to Received timestamps to find delivery delays. |
| Authentication-Results: | SPF, DKIM, and DMARC verdicts added by the receiving server. | The primary field for diagnosing authentication failures. |
| DKIM-Signature: | A cryptographic signature over the message headers and body. | Presence confirms the sending domain signed the message. |
| Received-SPF: | The SPF check result for the sending IP. | Shows whether the sending server was authorized by the domain’s DNS. |
| X-Spam-Status: | Spam score and rule hits assigned by the receiving server. | Shows why a message was flagged or filtered. |
| X-Mailer / X-Sender: | The software or service used to send the message. | Identifies the ESP, mail client, or automation tool. |
How to read Received headers
Received: headers are the delivery trail. Each server that handles the message prepends a new Received: line, so the headers are in reverse chronological order — the bottom entry is the first hop (origin), the top entry is the final delivery to your inbox. Reading them bottom-to-top reconstructs the full path.
Each Received: line typically follows this pattern:
Received: from mail.sender.com (mail.sender.com [203.0.113.42])
by mx.recipient.com with ESMTPS id abc123
for <[email protected]>;
Wed, 25 Jun 2025 17:30:10 +0000 (UTC)The from clause names the server that handed off the message. The by clause names the server that received it. The timestamp records when that handoff happened. By comparing timestamps across consecutive hops, you can calculate per-hop delivery delays and identify where a message was held up.
What authentication results mean
The Authentication-Results: header is added by the receiving mail server and contains the verdicts for SPF, DKIM, and DMARC. A fully authenticated message looks like this:
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of [email protected] designates 203.0.113.42 as permitted sender)
dkim=pass [email protected]
dmarc=pass (p=reject) header.from=example.comspf=pass means the sending IP is authorized in the domain’s SPF DNS record. dkim=pass means the cryptographic signature was valid — the message was not altered in transit. dmarc=pass means the visible From: domain aligned with a passing SPF or DKIM check. Any of these reading fail, softfail, or neutral indicates a configuration gap worth investigating.
How to get raw email headers
The method varies by email client. In Gmail, open the message, click the three-dot menu in the top-right corner of the email, and select Show original — this opens a new tab with the full raw headers and body. In Outlook (web), open the message, click the three-dot menu, select View, then View message source. In Apple Mail, open the message and go to View → Message → All Headers in the menu bar. Copy everything from the top of the raw view down to the start of the message body, then paste it into the analyzer above.
Common issues found in email headers
The most frequently diagnosed problems are SPF failures caused by missing or incorrect DNS records, DKIM failures caused by misconfigured signing at the ESP level, and DMARC failures caused by misalignment between the From: domain and the signing domain. Delivery delays surfaced by hop timestamps usually point to greylisting (a deliberate first-pass delay used by some servers), spam filter queuing, or DNS resolution slowness. A mismatch between the From: address and the Return-Path is a common indicator of spoofing or misconfigured bulk sending infrastructure.
Frequently asked questions about email headers
1. Is this tool safe to use with real email headers?
Yes. Analysis runs entirely in your browser — your headers are not sent to any server or stored anywhere. You can safely paste headers from real messages without exposing email content.
2. Why do my headers show SPF pass but DMARC fail?
DMARC requires not just that SPF passes, but that the authenticated domain aligns with the visible From: address. If your message is sent through an ESP that uses its own domain for the envelope sender (Return-Path), SPF will pass against the ESP’s domain but fail DMARC alignment against your From: domain. The fix is to either configure DKIM signing with your own domain, or set up a custom Return-Path with your ESP.
3. What does “softfail” mean in SPF results?
softfail (~all in the SPF record) means the sending IP is not explicitly authorized but the domain owner has asked receivers to accept it with lower trust rather than reject it outright. It is common during SPF rollout periods but should not be the permanent state — a -all hard fail policy is the goal once all legitimate senders are enumerated.
4. How many Received headers should a normal email have?
Most legitimate emails have 2–4 Received: headers. A message that passes through many hops (6+) may indicate unusual routing, forwarding chains, or that the message was deferred and requeued multiple times. A single Received: header is also unusual and may indicate header manipulation.
5. Can email headers be forged?
The visible display headers — From:, Subject:, Date: — can be trivially forged by the sender. The Received: headers added by each mail server are harder to forge because they are inserted by the receiving server, not the sender. The Authentication-Results: header added by your own mail server is the most trustworthy — it reflects checks your server performed independently.
6. My email has a large delay between hops, what does that mean?
A delay of several minutes between consecutive Received: timestamps usually means the message was queued at that server. Common causes are greylisting (an anti-spam technique that intentionally defers first-time senders for a few minutes), spam filter scanning, or server load. Delays of hours indicate the message was deferred due to a temporary error — often a DNS issue or a recipient server being temporarily unavailable.