Email Header Analyzer – Trace Routing, Verify Authentication, and Detect Spam
Every email message carries a set of invisible headers — structured metadata fields appended by each mail server that processes the message. These headers record the routing path, authentication results, spam filter verdicts, and dozens of other details that help diagnose delivery problems, identify spoofed senders, and understand how a message was handled in transit. This Email Header Analyzer parses raw email headers and presents each field with a plain-English explanation so you can quickly make sense of what happened to a message.
How to Find Your Email Headers
The method varies by mail client:
- Gmail: Open the message, click the three-dot menu (⋮) in the top-right corner, and select Show original. Copy everything from the top of the page down to the blank line before the message body.
- Outlook (Desktop): Open the message, go to File → Properties, and copy the Internet headers field.
- Apple Mail: Open the message and go toView → Message → All Headers (or press Shift+Cmd+H).
- Thunderbird: Open the message and press Ctrl+U (Cmd+U on Mac) to view the raw source including all headers.
Understanding the Routing Path
The Received header is added by every mail server that relays the message from sender to recipient. Servers appear in reverse order — the most recent hop is at the top. The analyzer reads these in chronological order and displays them as a numbered routing path, showing the sending server (from), the receiving server (by), the protocol (with ESMTPS, etc.), and the timestamp. Where timestamps are available, the delay between consecutive hops is calculated and highlighted. Delays over 30 seconds may indicate a slow relay, greylisting, or spam-filtering queue.
Some providers — notably Google — also add X-Received headers for internal routing steps. The analyzer includes these in the hop count for a complete picture of the delivery path.
SPF, DKIM, and DMARC Authentication
Modern email authentication relies on three complementary standards that are reported in the Authentication-Results header:
- SPF (Sender Policy Framework) — Checks whether the sending IP address is listed in the sender domain's DNS TXT record as an authorised mail server. A
spf=passresult means the sending server is permitted;spf=failorspf=softfailmay indicate a spoofed sender address. - DKIM (DomainKeys Identified Mail) — Verifies a cryptographic signature added by the sending domain's mail server. A
dkim=passresult confirms that the message body and key headers have not been altered in transit and that the signing domain takes responsibility for the message. - DMARC (Domain-based Message Authentication, Reporting & Conformance)— Builds on SPF and DKIM to give domain owners control over what happens to unauthenticated mail. A
dmarc=passresult means at least one of SPF or DKIM aligns with the From domain. The DMARC policy (p=reject,p=quarantine, orp=none) tells receivers what to do with failures.
Reading Spam Filter Results
Many mail servers run SpamAssassin or a similar content filter and record the verdict in headers like X-Spam-Status, X-Spam-Score, andX-Spam-Flag. The analyzer surfaces the spam score and flag prominently in the summary. A typical threshold for marking mail as spam is a score of 5.0, though server administrators can raise or lower this value. A high spam score combined with failed SPF, DKIM, or DMARC checks is a strong signal that a message is fraudulent or unsolicited.
Common Use Cases
Diagnosing Delayed or Undelivered Messages
When a recipient reports that an email was late or never arrived, the routing path reveals exactly where the delay occurred and which server last handled the message before delivery failed. If the last Received header shows your outgoing mail server but no subsequent hop, the problem likely lies with the recipient's domain — possibly a full mailbox, a filtering rule, or a DNS misconfiguration.
Investigating Phishing and Spoofed Emails
Attackers frequently forge the From display name or address to impersonate a trusted sender. Checking the authentication headers quickly reveals whether the sending IP is actually authorised for the claimed domain (SPF) and whether the message was signed by that domain (DKIM). A combination of spf=fail anddkim=none alongside a suspicious routing path is a reliable indicator of a spoofed or phishing message.
Verifying Your Own Mail Configuration
After configuring SPF, DKIM, and DMARC records on your domain, send a test message and paste the received headers into this analyzer. The Authentication-Results block will confirm whether all three checks pass, saving you from repeatedly consulting DNS debugging tools.
Privacy and Security
All parsing and analysis runs entirely in your browser. Your email headers — which may contain sender addresses, session tokens, internal server names, and recipient details — are never transmitted to any external server. You can safely analyze headers from sensitive or confidential messages.