ItsMyIp

Analyze an email's headers

Paste a message's raw headers (“Show original” in Gmail): server-by-server path, delays, SPF / DKIM / DMARC verdicts and originating IP. Everything is analyzed in your browser, nothing is sent.

  • The analysis happens entirely in your browser: the pasted headers are sent nowhere — not to ItsMyIp, not to anyone. Verifiable in your developer tools' Network tab.

01What an email's headers tell

Every email carries, invisibly, its travel log: each server it crosses prepends a Received header, so reading them bottom-up reconstructs the full path, from the originating server to your mailbox — with a timestamp at every step. The receiving server adds its authentication verdicts (SPF, DKIM, DMARC): the message's identity papers.

Reading these headers serves two purposes: unmasking a suspicious email (spoofed sender, hijacked reply address, originating IP unrelated to the displayed sender) and diagnosing a delivery problem (where did the message linger? which server held it?). The originating IP can then be inspected with our whois and our blacklist check; the sending domain's configuration, with the email check.

02Understanding each header

Received
The trace added by each server crossed: who handed it the message (from), who received it (by), when. Stacked bottom-up — the lowest one is the first server, hence the origin.
Authentication-Results
The receiving server's verdicts: spf=, dkim=, dmarc= followed by pass, fail, softfail… This is the authoritative header, added by your mailbox provider.
From
The displayed sender — what the recipient sees. It is the field DMARC protects, because it is the easiest to forge.
Reply-To
The address that will receive replies, when it differs from the From. Legitimate (customer service), but also the favorite tool of email scams.
Return-Path
The technical bounce address, taken from the SMTP envelope. It is what SPF verifies — often hosted at the sending provider.
Message-ID
The message's unique identifier, generated by the originating server. A domain inconsistent with the sender is one more clue.

03Where to find the raw headers?

Every mail client hides them somewhere different — copy the entire displayed block:

Gmail
Open the message → ⋮ menu top right → “Show original” → copy everything (or “Copy to clipboard”).
Outlook
Open message → ⋯ → “View” → “View message details” (web) or File → Properties → “Internet headers” (desktop).
Apple Mail
Message selected → View menu → Message → “All Headers” (or “Raw Source”).
Thunderbird
Open message → Ctrl+U (“Message source”) or View → Headers → All.
Yahoo / others
Look for “View raw message” or “Message source” in the message's ⋯ menu.

04Frequently asked questions

Is my email content sent to ItsMyIp?

No. The analysis runs as JavaScript in your browser: what you paste never leaves the page — no network request goes out, which you can verify in the developer tools' Network tab. You may also paste only the headers, without the message body: that is all the analysis needs.

How do I spot a spoofed email from its headers?

Three strong signals: a dmarc=fail verdict (the displayed sender is not authenticated), a Reply-To on a domain unrelated to the From (replies go to the fraudster), and an originating IP hosted somewhere inconsistent with the supposed sender. None is absolute proof alone, but their accumulation is telling — and dmarc=pass on the right domain is very reassuring.

What are the delays between servers for?

Locating a delivery slowdown. An email that takes an hour to arrive lingered somewhere: the per-hop delays show exactly where — a queue at the sender, greylisting (deliberate anti-spam holding) at reception, an overloaded relay. Normal transit is measured in seconds.

Can the originating IP locate the sender?

Rarely in the “person” sense: it is the IP of the server that emitted the message, not the individual's. Gmail, Outlook and most webmails never expose their users' IP addresses — you will see their servers. It remains valuable to identify the emitting network (whois) and its reputation (blacklists), especially for spam sent by compromised servers.

Why does the analysis find no SPF/DKIM/DMARC verdicts?

Either you pasted only part of the headers (From, Subject…): you need the full block obtained via “Show original”. Or your receiving server does not add an Authentication-Results header — the case with some shared hosting providers. The verdicts are those of the server that received the message: they alone are authoritative.

05More network tools