Email Header Analyzer

Paste the headers of a suspicious message (or the whole message source) to see who really sent it: the path it took, what your mail provider recorded for SPF, DKIM and DMARC, and the tricks phishing mail relies on, such as a display name that contains someone else's address or a look-alike domain. The headers are parsed on this page and nothing in them is looked up or contacted.

Runs locally — nothing you enter is sent Security Free · no signup

How to use

Copy the raw headers. Gmail: open the message, ⋮ → Show original → Copy to clipboard. Outlook desktop: File → Properties → Internet headers. Outlook on the web: ⋯ → View → View message source. Apple Mail: View → Message → All Headers.
Paste them into the box, or drop a saved .eml file. If you paste the whole message, everything after the first blank line (the body) is ignored.
Read the red flags first. Each one says why it matters and when it is harmless.
Check the Authentication box: SPF, DKIM and DMARC as recorded by your provider's server, with the domain each result applies to.
Look at the delivery path, oldest hop first. The hop marked as the hand-off is the server that passed the message to your provider: its IP address is the most trustworthy sender address in the headers.
Use Copy report to paste a plain-text summary into a ticket or a message to your security team.

Examples

Input (excerpt)

Authentication-Results: mx1.example.com; dkim=none;
  spf=softfail smtp.mailfrom=bounce@mailer.example.org;
  dmarc=fail header.from=xn--exmple-cua.net
From: =?UTF-8?B?SVQgSGVscGRlc2sgaGVscGRlc2tAZXhhbXBsZS5uZXQ=?= <alerts@xn--exmple-cua.net>
Reply-To: <it-support-desk@example.org>

Red flags (excerpt)

[HIGH] From display name contains a different address: "IT Helpdesk helpdesk@example.net" vs alerts@xn--exmple-cua.net
[HIGH] From uses an internationalised (punycode) domain: shown as "exämple.net"
[HIGH] DMARC fail
[WARN] Reply-To goes to a different domain than From

Supported formats

Raw RFC 5322 headers as shown by Gmail (Show original), Outlook (Internet headers / View message source), Apple Mail, Thunderbird (View source) and most other clients.
Whole .eml files and plain-text exports; only the header section is read (the first megabyte of a dropped file).
Folded (multi-line) headers and RFC 2047 encoded words in base64 or quoted-printable, in UTF-8, ISO-8859-x, Windows-125x, KOI8 and the other character sets your browser can decode.
Received headers written by Postfix, Exim, Sendmail, Gmail and Microsoft 365 / Exchange; Authentication-Results, ARC-Authentication-Results, Received-SPF, DKIM-Signature and ARC-Seal.

Privacy

This tool runs entirely in your browser. Nothing you enter or open is sent anywhere. Privacy policy.

Limitations

The tool reports what the receiving servers wrote into the headers. It does not verify DKIM or ARC signatures, query SPF or DMARC records, or look up any IP address or domain, so it cannot tell you anything those servers did not record.
Received headers added before the message reached your own provider were written by the sender's side and can be forged. Trust the hops from the hand-off onwards, and the topmost Authentication-Results header.
The provider boundary is guessed from host names. When sender and recipient use the same provider (for example two Microsoft 365 tenants), the hand-off hop cannot be told apart and is shown as the first hop.
Domain comparisons use a simplified organisational domain (the last two labels, or three for suffixes such as co.uk), not the full Public Suffix List, so unusual suffixes can produce a false mismatch.
Outlook .msg files are a binary format and are not read. Open the message and copy its Internet headers, or save it as .eml.
No red flags does not mean a message is safe. Header checks say nothing about the links or attachments in the body.

FAQ

How do I find the real sender of an email?

Look at the hand-off hop in the delivery path: the server that connected to your mail provider, and the IP address your provider recorded for it. Everything below that point in the raw headers was written by the sending side and could be invented. Then check DMARC: a pass means the From domain authorised the message; a fail means it almost certainly did not.

What do SPF, DKIM and DMARC actually prove?

SPF checks that the delivering server may send for the envelope sender (the Return-Path domain). DKIM checks a signature added by the domain in d=. DMARC passes only when SPF or DKIM passes for a domain that matches the visible From address, which is why it is the most useful of the three for spotting spoofing.

Why does the Return-Path differ from the From address?

Mailing services and newsletter platforms receive bounces on their own domain, so a different Return-Path is normal for bulk mail. It matters when DMARC fails, or when the From domain has no DMARC policy at all.

SPF failed but DMARC passed. Is that bad?

Usually not. Forwarding and mailing lists break SPF because a different server delivers the message, while the DKIM signature still verifies. DMARC needs only one of the two to pass for the From domain.

Can this tool verify a DKIM signature?

No. Verifying needs the sender's public key from DNS and the unaltered message body, and this page makes no network requests. It shows the signature's domain, selector, algorithm and signed headers, and the dkim= result your provider recorded when the message arrived.

Is it safe to paste email headers here?

The headers are parsed by JavaScript on this page and are not uploaded or stored. They do contain email addresses and internal host names, so treat the copied report the way you would treat the email itself.