Free Email Header Analyzer

What are email headers?

Every email carries a hidden log of its own journey. Before the subject line and body you read, there are dozens of header fields: who the message claims to be from, which servers handled it, when each handoff happened, and — most usefully — the results of the authentication checks the receiving server ran the moment it accepted the message. Mail clients hide all of this by default, but it's plain text, and once you can read it, a header answers questions nothing else can: was this message really sent by the domain it claims? Where did it slow down? Why did DMARC fail?

Headers are written newest-first: each server that handles the message prepends its own Received: line and any verdicts to the top. So the top of the header block describes the final delivery, and the bottom describes the origin. The analysis unfolds the wrapped lines, indexes every field, and reads the story back in order.

How to read Authentication-Results

The single most valuable header is Authentication-Results, stamped by the receiving server. A typical Gmail example reads: Authentication-Results: mx.google.com; dkim=pass header.i=@example.com header.s=mail2026; spf=pass smtp.mailfrom=bounces@mail.example.com; dmarc=pass (p=QUARANTINE) header.from=example.com. Reading it piece by piece: mx.google.com is the server that ran the checks. dkim=pass means the cryptographic signature verified — the message wasn't altered, and the domain in header.i (with the DNS selector in header.s) vouches for it. spf=pass means the sending IP was authorized by the SPF record of the envelope domain in smtp.mailfrom — note that it's mail.example.com, not the From address. And dmarc=pass is the summary judgment: at least one of the two passed and aligned with the visible From domain, whose published policy (p=QUARANTINE) would otherwise have sent the message to spam.

One caveat before you trust a verdict: these results are stamped by the receiver. A message copied from your own Sent folder has no Authentication-Results at all, because no receiving server has judged it yet. To test your own sending, mail yourself at Gmail or another major provider and analyze the received copy.

Alignment: why spf=pass can still fail DMARC

This is the misunderstanding behind most DMARC failures. SPF and DKIM each authenticate a domain — but not necessarily your domain. DMARC's extra demand is alignment: the domain that passed must match the domain in the From header that your recipient actually sees. Under the default relaxed mode, a match means sharing the same registrable domain — bounces@mail.example.com aligns with updates@example.com because both boil down to example.com. Under strict mode the domains must be identical.

Now consider a typical ESP setup: your campaigns go out with an envelope sender on the ESP's own domain. SPF checks that domain, passes — and contributes nothing to your DMARC, because esp-provider.com doesn't align with yourbrand.com. If your DKIM signature is also the ESP's default (d=esp-provider.com) rather than your own domain, DMARC fails on a message where both SPF and DKIM show pass. It's the #1 silent DMARC killer, and it's invisible until you read the headers. The fix: a custom return-path domain, an aligned DKIM key, or both. Check what your domain publishes with the free SPF checker, DKIM checker and DMARC checker.

Reading the Received chain

Each Received: line records one handoff — which server passed the message to which, from what IP, at what time. Read bottom-up, the chain traces the message from the sender's infrastructure to the recipient's inbox. Two things are worth looking for. First, the route itself: an unexpected relay in the middle can reveal a forwarder, a security gateway, or (in a phishing sample) infrastructure that has nothing to do with the claimed sender. Second, the timestamps: the gap between consecutive hops is how long the earlier server sat on the message. Healthy hops take a second or two; a gap of minutes points to greylisting, throttling by the receiver, or an overloaded queue — the usual suspects when someone says "your email arrived three hours late." The analysis computes every gap and flags unusually slow hops.

Red flags worth acting on

• Reply-To on a different domain than From — the recipient sees a trusted sender, but replies flow somewhere else entirely. It has legitimate uses, but it's also the single most common pattern in payment-fraud phishing.
• Missing Message-ID — every real mail server generates one. Its absence suggests a crude script, and spam filters score it accordingly.
• Failing or absent authentication — spf=fail with dkim=fail means the message has no verifiable connection to its claimed sender. On your own mail, it means your DNS setup needs fixing before mailbox providers lose patience.
• Unaligned passes — everything says pass, DMARC still fails. See alignment above; fix the return-path or the DKIM d= domain.
• No one-click List-Unsubscribe on bulk mail — since 2024, Gmail and Yahoo require RFC 8058 one-click unsubscribe from bulk senders. Missing it doesn't just annoy recipients; it costs you inbox placement.

What headers can't tell you

A header is a post-mortem of one message. It can't tell you how mailbox providers rate your sending domain this week, which of the 40,000 addresses on your list will hard-bounce tomorrow, or whether your next campaign lands in the inbox or the spam folder. Those answers need measurement before and across sends, not after one: verify addresses before they ever see a campaign, and use deliverability testing to watch placement over time. Reading headers is how you diagnose the last problem; verification and monitoring are how you avoid the next one.