Email Header Analyzer

In Gmail, open the message, click the three-dot menu, and choose "Show original" — then copy everything from the top. In Outlook on the web, open the message, click the three-dot menu, and choose View > View message details. In classic Outlook desktop it's File > Properties > Internet headers. In Apple Mail, use View > Message > All Headers (or Raw Source). In Yahoo Mail, use More > View raw message. Paste the copied text into the analyzer above.

Each mail server that handles a message adds its own Received line to the top of the header, so the bottom Received line is the origin and the top one is your own mail server. Reading bottom-up traces the full delivery path. This analyzer does the reordering for you: hop 1 is the origin, and each row shows the sending server, the receiving server, the protocol, the timestamp, and the delay since the previous hop.

It's the receiving server's own record of how the message performed against SPF, DKIM, and DMARC. Each method gets a verdict (pass, fail, softfail, none, and so on) plus the domain it was checked against — smtp.mailfrom for SPF, header.d for DKIM, and header.from for DMARC. Because it's written by the server that accepted the message, it's the most trustworthy authentication evidence in the header.

SPF is checked against the Return-Path (envelope) domain, but DMARC additionally requires that domain to align with the visible From domain. If a service sends from bounce.someesp.com while the From address says yourbrand.com, SPF can pass for someesp.com yet DMARC fails because the domains don't align. The fix is a custom Return-Path (bounce) domain on your own domain, or a passing, aligned DKIM signature.

From is the address people see in their mail client; Return-Path is the hidden envelope address where bounces are sent. Email service providers routinely use their own Return-Path domain or a subdomain of yours, so the two rarely match exactly. Same organizational domain (mail.acme.com vs acme.com) is normal and satisfies DMARC's default relaxed alignment. Completely unrelated domains deserve scrutiny — that's the pattern spoofed mail uses.

Sometimes. The earliest Received lines often include the IP of the server — or even the device — that submitted the message, and public IPs can be roughly geolocated. But big webmail providers like Gmail deliberately hide the sender's client IP, and any Received line added before the message reached a server you trust can be forged. Treat header IPs as a lead, not proof.

Look for a DMARC fail in Authentication-Results, a From domain that doesn't align with the Return-Path or DKIM domain, a Reply-To pointing at an unrelated domain, and an origin server that has nothing to do with the claimed sender. Any one signal can have an innocent explanation (forwarding breaks SPF, for example), but several together — especially dmarc=fail on a domain with p=reject — is a strong sign of spoofing.

Common causes are greylisting (the receiver deliberately asks the sender to retry), spam and malware scanning, throttled or queued outbound mail on a busy server, and DNS problems. One slow hop pinpoints where delivery stalls, which is exactly why per-hop delays matter when debugging "your email took hours to arrive" complaints. Note that server clocks can disagree, so small or negative delays are usually clock skew, not real latency.

Headers contain metadata — sender and recipient addresses, server names, IPs, and subject line — but not the message body or attachments. Still, that metadata can be sensitive. This analyzer parses everything locally in your browser and never uploads, logs, or stores what you paste, so nothing leaves your machine. With any tool, prefer ones that state exactly what happens to the data.

Partially. A sender controls everything they generate: From, Subject, Message-ID, X-Mailer, and any Received lines below their own server, so those can all be fabricated. What they can't fake are the headers added after the message reaches trusted infrastructure — your own server's Received line and its Authentication-Results. That's why analysis anchors on the top of the chain and on SPF, DKIM, and DMARC verdicts rather than on what the sender claims.