Email Header Analyzer

What email headers are

Every email carries a stack of metadata describing every server that touched it on its way to your inbox — when, by which protocol, with what authentication results, and what spam scores it accumulated along the way. Most email clients hide all of this behind a "from / subject / body" summary, but the headers are still there.

The headers tell a story. You can trace a message hop by hop from its origin server through every relay to your inbox, see which authentication checks it passed or failed, and spot the common signatures of phishing, spoofing, or accidental misdelivery.

How to find raw headers

• Gmail — Open the message, click the three-dot menu next to the reply button, choose Show original. The new tab will show authentication results at the top and the full raw message below.
• Outlook (web) — Open the message, click the three-dot menu, choose View message source.
• Outlook (desktop) — File → Properties → "Internet headers" box at the bottom.
• Apple Mail — View → Message → All Headers.
• Yahoo Mail — Open the message → three-dot menu → View raw message.
• Thunderbird — View → Message Source (Ctrl+U / ⌘U).

Copy everything from the first header line through the blank line that separates headers from the body. The blank line is the boundary — don't include the body.

Reading the Received chain

Email servers stamp a Received: header onto every message they handle, recording the previous hop and themselves. New headers are added to the top of the message, so the order in the raw headers reads newest-first. To follow the actual route the message travelled, you read the Received: headers from bottom to top. The tool above does this automatically and shows the chain in chronological order.

Each hop typically reads Received: from X by Y with PROTOCOL; TIMESTAMP. The delays between consecutive timestamps are the most diagnostic data you have: a few seconds is normal, several minutes suggests greylisting, and an hour-plus usually means a backed-up queue somewhere.

Authentication results

Modern mail providers add an Authentication-Results: header summarising the three big checks:

• SPF verifies that the sending server is authorised to send for the domain in the envelope sender. /spf resolves the full SPF record for any domain.
• DKIM verifies a cryptographic signature over the message headers and body. The signing domain (header.d=) and selector (header.s=) identify which key was used.
• DMARC ties them together and tells the receiver what to do on failure (none, quarantine, reject). /dmarc looks up the policy for any domain.

All three should pass for legitimate transactional mail from a well-configured sender. One failure isn't proof of fraud — a forwarded message often breaks SPF, and DKIM signatures can break if a mailing list modifies the body — but a message that fails all three and lands in your inbox is a red flag worth investigating.

Red flags to watch for

• From ≠ Return-Path — the visible "from" address differs from the envelope sender. Legitimate use cases exist (mailing lists, bounce handling), but it's the most common signature of envelope spoofing.
• Reply-To different from From — phishing messages often set Reply-To to an attacker-controlled address while leaving From as a recognised name.
• Long delays at a single hop — usually greylisting, but a multi-hour delay at a relay can indicate the relay was queueing under load or a compromise was happening.
• Failing or absent authentication — especially DMARC=fail with a strict policy in place. If the receiver still delivered the message, look carefully.
• Suspicious X-Mailer or User-Agent — bulk-mailer software not used by the legitimate sender.
• X-Spam-Score close to or above the receiver's threshold — even if the message was delivered, it tripped multiple spam checks.