Email Header Analyser

Every email message carries a block of metadata called headers, added by each mail server that handles it. Defined in RFC 5322 and extended by RFC 2822, these headers record who sent the message, who received it, when, via which route, and the authentication verdicts from each server along the way. This tool parses that raw header block and presents all of it in a structured, tab-organised format. Authentication results, routing path, spam scores, and every individual header field.

The Authentication tab shows SPF, DKIM, and DMARC results extracted from the Authentication-Results header. The most authoritative authentication signal in any email, because it is written by the receiving server (which you control or trust) rather than by the sender. A message with all three passing is authenticated end-to-end. Any failure is worth investigating: it may indicate a spoofed sender, a domain with weak authentication, a phishing attempt, a misconfigured mail server, or a legitimate message forwarded through a relay that broke SPF alignment.

The Routing tab reconstructs the delivery path chronologically from the originating server to your inbox, with per-hop timestamps and delay calculations. The originating IP, extracted from the oldest Received header, is the actual IP address of the server that first injected the message into the internet's mail infrastructure. Unlike the From: header (which any attacker can forge), the originating IP cannot be spoofed because it is written by your receiving server, not the sender. Discrepancies between the claimed sending domain and the originating IP's registered owner are among the strongest indicators of a spoofed or phishing message.

Email headers are the ground truth of email delivery. While the visible interface of an email client shows you only From:, Subject:, and Date:, all three of which can be trivially forged, the headers show the actual servers that handled the message, the cryptographic authentication results that cannot be faked, and the routing timeline that reveals whether the message travelled a normal or suspicious path. For anyone investigating a suspicious email, the headers are always the first stop.

For email deliverability troubleshooting, headers reveal what actually happened to a message. Not what was supposed to happen. A transactional email that is landing in spam will show an elevated X-Spam-Score and often a DMARC p=none policy (monitoring mode, no enforcement), a missing DKIM signature, or an SPF softfail. The headers tell you exactly which of these is the problem. Checking the same information at the DNS level using the Email Health Checker or the Email Privacy Auditor confirms whether the issue is a configuration gap or a per-message authentication failure.

For security investigations, headers expose Business Email Compromise (BEC) attempts and phishing emails that visual inspection alone cannot catch. The most sophisticated phishing emails are visually identical to legitimate messages. Same logo, same formatting, same domain in the visible From: field. The headers reveal the reality: a DMARC fail, an SPF fail from an unrecognised IP, a missing DKIM signature, and a Return-Path pointing to an attacker-controlled domain. This combination is unmistakable in the headers even when the email looks completely authentic to a non-technical recipient.

For email marketing and cold outreach, headers provide confirmation that your authentication stack is working correctly for delivered messages. DKIM is signing, SPF is passing, and DMARC is aligned. A single real sent message analysed here gives you more certainty than any DNS checker, because you are seeing the authentication result that the actual receiving server reported for that specific message.

Most authentication failures and suspicious patterns in email headers fall into a small number of recognisable patterns. Here is what each one means and how to respond.

The three authentication standards that appear in email headers work together as a layered system. Understanding what each one validates, and crucially what it does not validate, is essential for correctly interpreting header analysis results.

SPF (Sender Policy Framework, RFC 7208) answers: is this IP address authorised to send email for the envelope domain? It checks the Received-SPF header, which contains the sending IP, the envelope MAIL FROM domain, and the result (pass, fail, softfail, neutral, none, permerror, temperror). Critically, SPF validates the Return-Path domain, the hidden envelope address used for bounces, not the visible From: header. This is why SPF pass does not mean the From: address is genuine, and why spf=pass alongside dmarc=fail can still indicate a spoofed message. You can verify a domain's SPF configuration independently using the SPF Record Checker.

DKIM (DomainKeys Identified Mail, RFC 6376) answers: was this message cryptographically signed by the domain in the d= tag, and has it been altered since signing? The DKIM-Signature header contains the signing domain (d=), selector (s=), algorithm (a=, typically rsa-sha256), the headers included in the signature (h=), and the signature itself (b=). A dkim=pass result means the signature verified correctly against the public key in DNS. DKIM survives forwarding, making it the more reliable alignment mechanism for third-party ESPs. Use the DKIM Analyzer to inspect a domain's published key strength and status.

DMARC (RFC 7489) answers: does the authenticated domain match the visible From: header? It enforces alignment. The SPF Return-Path domain or the DKIM d= domain must match (or be a subdomain of, in relaxed mode) the From: domain. The Authentication-Results header shows the DMARC verdict (pass/fail) and the policy applied (none/quarantine/reject). A dmarc=pass means at least one mechanism passed with alignment. A dmarc=fail means neither did. And the message's claimed From: domain is not what actually sent it. The DMARC Checker shows a domain's current policy and whether rua= reporting is configured.

The interaction between these three standards produces the most important rule in email security: a message can have spf=pass and dkim=pass and still be a spoofed phishing email. If SPF passes for the Return-Path domain (not the From: domain) and DKIM passes for the signing domain (not the From: domain), and neither aligns with the From: header, DMARC will fail. This is exactly why phishing emails from sophisticated actors often show individual SPF and DKIM passes alongside a DMARC fail. The DMARC result is the authoritative verdict. When combined with a domain-level policy of p=reject, that verdict should have blocked the message before delivery.