Patchkit

Free tool

Email Header Analyzer

Paste the headers of one message to see whether SPF, DKIM and DMARC passed, why, and the path it took to reach you.

Your headers never leave your browser. Nothing is sent to Patchkit or stored.

By Ahmet Karaca · Updated · Checked against RFC 8601 (Authentication-Results), RFC 7208 (SPF), RFC 6376 (DKIM), RFC 8617 (ARC, experimental), RFC 5322 (message format), RFC 5321 (SMTP), Gmail Help on full headers and Microsoft's guide to message headers in Outlook on

What the headers show

Every server that handles an email adds a few lines to the top of it. Your mailbox provider adds the most useful one: an Authentication-Results header that records whether SPF, DKIM and DMARC passed for that message. Below it sit the Received lines of each server on the way, the DKIM-Signature of every service that signed the message, and, when a mailing list or forwarder was involved, an ARC chain that carries the earlier results along.

That is the fastest way to answer a specific question about one message: why did this invoice land in spam, which service actually sent this newsletter, which DKIM selector does our help desk sign with. DMARC aggregate reports give the same answers for all of your mail at once, but a day later.

How to get your headers

  • Gmail: open the message, choose the three-dot menu next to Reply and select Show original. Copy everything above the message body. Google explains it in Gmail Help on full headers.
  • Outlook: open the message, then in Outlook on the web choose More actions, View, View message details; in Outlook for Windows choose File, Properties and copy the Internet headers box. See Microsoft's guide to message headers.
  • Any other client: look for "view source", "show original" or "message headers". Pasting the whole message is fine: the tool stops at the first blank line and never reads the body.

How the verdicts are read

SPF, DKIM and DMARC verdicts come from the top Authentication-Results header, the one your own receiving server wrote, and the tool names that server next to them. Headers of the same kind further down were added by earlier hops and can be forged by anyone on the way, so they are listed but never trusted. When a message has no such header, the SPF verdict falls back to Received-SPF and DKIM and DMARC are shown as "no result recorded" instead of being guessed.

The tool then does its own alignment check: it compares the From domain with each DKIM d= domain and with the MAIL FROM (Return-Path) domain, in both relaxed and strict mode. The relaxed check is based on the Public Suffix List, which finds each organizational domain. If the receiver's own dmarc= verdict disagrees, for example because it trusted an ARC chain, the receiver wins and the difference is shown as a note. A message with more than one From address is flagged, because the receiver may have evaluated a different domain than the one shown.

What this tool checks

  • SPF, DKIM and DMARC verdicts from the top Authentication-Results header (RFC 8601), with earlier hops listed separately.
  • The Received-SPF result, client IP, envelope sender and HELO name, when the message has that header (RFC 7208).
  • Each DKIM-Signature's domain, selector, algorithm, signed headers and whether it had expired at delivery, with a link to check the key.
  • Relaxed and strict alignment of DKIM and SPF with the From domain, and messages with more than one From address.
  • Whether an ARC chain is complete from i=1 upward, with each instance once and cv values in order, and what its last seal says (RFC 8617).
  • The delivery path from sender to mailbox, with the delay of each hop and servers that claim TLS.

What it doesn't check

  • It doesn't verify DKIM or ARC signatures cryptographically; that needs the message body and DNS.
  • It can't prove the top Authentication-Results header came from your receiver; it shows the server name so you can judge.
  • It doesn't know your DMARC policy's alignment mode; it shows both modes and links to the DMARC checker.
  • "Encrypted in transit" is each server's own claim, not something the tool can confirm.
  • Rare public suffixes may be grouped differently in your browser than on our servers, which only affects the alignment sentence.

Found a selector? How to find your DKIM selector explains where else it appears, and DMARC fails even though SPF passes walks through the most common alignment problem.

Related tools and guides

Frequently asked questions

+Are my headers sent to Patchkit?

No. The headers are read by code running in your browser and never leave it. Nothing is uploaded, stored or logged, analytics only counts that the tool was used, and the page address doesn't change. You can confirm it in your browser's network tab: analyzing headers makes no request that carries them.

+Which Authentication-Results header counts?

Only the top one, written by the server that received the message for you; the tool shows its verdicts as "according to" that server's name. Authentication-Results headers added by earlier hops can be forged by anyone on the way, so they are listed for reference and never used as the verdict. A sender can also fake a top header, so check that its name belongs to your mailbox provider.

+Why does the tool say DKIM aligns while my receiver says DMARC failed?

Headers don't say whether your DMARC policy asks for relaxed or strict alignment. Relaxed alignment accepts a subdomain, based on the Public Suffix List; strict needs the exact domain. The tool shows both, and when its reading differs from the receiver's own dmarc= verdict it says so. The receiver's verdict wins: it is the one that decided delivery.

+Does the tool verify DKIM and ARC signatures?

No. Verifying a signature needs the full message body and a DNS lookup of the public key. The tool reads the results your receiver recorded and the tags inside each signature, such as the domain, the selector and the expiry time. A signature is flagged as expired only if it had already expired when the message was delivered, measured by the top Received header's time. If that time can't be read, the tool says it can't tell instead of guessing.

+What does clock skew mean in the delivery path?

Each server stamps the time it received the message. When a later server's stamp is earlier than the one before it, the gap is labeled clock skew and left out of the total delay, because the servers' clocks disagree rather than the mail being delayed. When a stamp can't be read at all, the hop shows "time unknown" instead of a delay.

We use Google Analytics cookies only if you accept. Privacy policy