Free tool

Email header analyzer

Paste the raw headers from an email you received and see what the receiving mail system actually decided: its own SPF, DKIM and DMARC results, whether the domains lined up, and every relay the message passed through.

No sign-up, no email address, no upload. The parsing runs in your browser — see below for why that is not just a convenience.

Paste the headers

Send yourself an email from your sending domain, open it, and copy its headers. In Gmail that is ⋮ → Show original; in Outlook, File → Properties → Internet headers. Paste everything down to the first blank line.

Headers are read in your browser — nothing is uploaded, stored or logged. They contain recipient addresses and internal hostnames, so that seemed like the right default.

How to get the headers

In Gmail, open the message and choose ⋮ → Show original. In Outlook, File → Properties → Internet headers. In Apple Mail, turn on View → Message → All Headers. Copy everything down to the first blank line — that blank line is where the headers end and the body begins.

What the three verdicts mean

The receiving mail system writes its conclusions into an Authentication-Results header. That line is the one thing on this page that is a measurement rather than an interpretation, so it is reported separately and labelled as theirs.

  • SPF asks whether the server that handed over the message is allowed to send for the domain in the envelope sender — the Return-Path, not the address the recipient sees.
  • DKIM asks whether the cryptographic signature on the message validates against a public key published in DNS, which also proves the signed parts were not altered in transit.
  • DMARC asks whether either of those passed for the domain the recipient actually sees. That last part is the one people miss: a message can pass SPF and still fail DMARC, because the SPF pass belonged to a different domain. The analyzer reports that alignment separately for exactly this reason.

A verdict of temperror or permerror is reported here as not checked rather than as a failure. The receiver is saying it could not run the check — usually a DNS timeout — and treating that as a failure is how people end up rewriting a record that was fine.

Why this runs in your browser

Email headers carry every recipient address on the message, internal hostnames, and internal IP addresses. Most tools in this category ask you to upload them. There is no technical reason to: parsing a header block needs no server, so this page does not have one. Nothing you paste is sent anywhere, stored, or logged — you can confirm that by disconnecting from the network and running it anyway.

What this cannot tell you

It cannot tell you whether the message landed in the inbox or in spam. Nothing in the headers records placement, and any tool claiming otherwise from a header paste is guessing. What it can tell you is whether authentication was the reason — which is the first thing worth ruling out, and the one you can fix yourself.

Something failed and you need to fix it?

Our setup guides are written for the failure, not for the happy path — what a failing check actually means, what to publish, and how to tell propagation apart from a record that is simply wrong.

Set up DKIMSet up DMARCTroubleshooting