Log inTry the sandbox free

Email authentication

Email header analyser

Paste a raw email header block and read every Received hop, its delay and every SPF, DKIM and DMARC verdict in plain words.

Free, no accountIn your browser

Paste the whole block, blank lines and all. Nothing you paste here leaves your browser.

Try

Result

Nothing to analyse yet

Paste a raw header block and the hops, their delays and every authentication verdict are read out as you type.

What this is

This email header analyser takes the raw block you paste - the full source behind "Show original" in Gmail, "Message details" in Outlook, or "All Headers" in Apple Mail - and reads out every Received hop with its delay, and every SPF, DKIM and DMARC verdict the receiving service recorded. No domain name, no DNS lookup, and nothing you paste leaves your browser.

Every relay a message passes through prepends its own Received header, so the oldest hop ends up at the bottom of what you paste and the newest sits on top - RFC 5321 §4.4 calls this trace information, and it is the only part of a header block a sender could not simply have written themselves. A hop is read against the one before it: the host a hop says it handed off to has to be the host the next hop down says it came from, never guessed at from how long the gap between the two was.

Not every property inside an Authentication-Results header is one of the three verdicts this page judges. RFC 8601 §2.2 only defines the ptype.property=pvalue grammar a method’s result sits inside; Microsoft 365 goes further and stamps a composite compauth= verdict with a three-digit reason= code in that same header, beside its own spf=, dkim= and dmarc= results (Microsoft, Anti-spam message headers). This analyser reads a pair like that into the verdicts table as one more property, but it does not decode what the code means.

How to read the result

The hop table runs oldest first, the opposite order from the paste, and each row’s delay is measured against the row above it rather than against the very first hop - a wait of several minutes at one slow relay is ordinary and says nothing about any other hop in the chain. A missing hop is reported separately, from a handoff that does not join up, and never inferred from a delay on its own.

The authentication table lists the newest Authentication-Results header first, since that is the one your own receiving service wrote; anything below it was carried forward by whichever relay saw the message earlier, and may describe an address this copy no longer carries. A DKIM pass only ever names the domain that signed, per RFC 6376 §3.5, so a pass beside a From: address it does not match is read as somebody else’s signature, not the sender’s own.

This page reads the hops and verdicts one message already carries, not why SPF, DKIM or DMARC produced them. For how the three protocols fit together, what order to fix them in, and what to do once one fails, see our guide How SPF, DKIM and DMARC work together, and what to do when one fails.

Common mistakes

What goes wrong most often, and how to tell.

  • Reading a DKIM pass as proof of the From: nameA dkim=pass only says the key named in d= signed the message (RFC 6376 §3.5); it says nothing about the address a reader sees in From:. A mailing list, a forwarder or a sending platform that signs with its own domain produces exactly this pass, which is why this page separates what signed from what the reader was shown.
  • Blaming a slow hop for a missing oneA long gap between two timestamps is a queue, a retry or a rate limit - not evidence that a relay is missing. A missing hop is a different fact entirely: one line’s handoff target and the next line’s claimed source stop matching, which this page checks directly rather than guessing from how long a hop took.
  • Copying headers from a reading pane instead of the raw sourceA mail client’s summary view drops exactly the lines this page reads: the Received chain and the Authentication-Results header are both added above the message a sender wrote, and a reading pane shows the message, not its envelope. Open the raw source instead and copy from there.
  • Treating an older Authentication-Results header as this message’s own verdictA header block can carry more than one Authentication-Results line when a mailing list or a forwarder re-sent the message, and only the newest one - the one on top - is your own receiving service’s verdict. An older one below it is whatever an earlier relay decided, carried forward verbatim.

Questions

What people ask about this tool.

  • Every relay prepends its own Received header rather than appending one, so the top line in your paste is always the last hop before delivery and the bottom line is the first - RFC 5321 §4.4 names this trace information. This page reverses that order in its table so hop 1 is where the message actually started.

  • Yes, and that is the single most useful thing this page checks. DKIM only verifies the domain in its own d= tag (RFC 6376 §3.5); a forwarder, a mailing list or a sending platform that signs with its own domain gets exactly the same pass a genuine sender would, so a pass for a domain that is not the From: address is read as somebody else’s signature.

  • No. It only reads the text you paste: the Received chain, the Authentication-Results header and any DKIM-Signature, judged against each other, and nothing leaves your browser. The verdicts shown are the receiving service’s own, made against DNS as it stood when the message arrived, not re-checked here.

  • Those are Microsoft 365’s own additions: a composite verdict and a three-digit code describing which signal decided it, stamped in the same header as the standard spf=, dkim= and dmarc= results (Microsoft, Anti-spam message headers). This page reads the pair as a property but does not decode the code itself.

Sources

Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.

Use it from the API

The same check, as one request.

Request
curl -X POST https://resellerhq.com/api/tools/email-header-analyser \
  -H "Content-Type: application/json" \
  -d '{"headers":"Hey team,\n\nJust wanted to check if everyone's free for lunch on Friday. Let me know!\n\nThanks,\nAlex"}'
Response
{
  "tool": "email-header-analyser",
  "input": {
    "headers": "Hey team,\n\nJust wanted to check if everyone's free for lunch on Friday. Let me know!\n\nThanks,\nAlex"
  },
  "result": {
    "verdict": {
      "tone": "warning",
      "headline": "This paste has no headers in it",
      "summary": "Nothing here is a header field, so there is no chain to follow and no verdict to read."
    },
    "findings": [
      {
        "id": "not-a-header-block",
        "severity": "warn",
        "title": "No header fields were found in this paste",
        "detail": "A header is a field name, a colon and a value. Nothing in this paste has that shape, which usually means what was copied is the message body, or a reading pane’s summary of it, rather than the raw source.",
        "fix": "Open the raw source and copy from there: in Gmail, the message menu then \"Show original\"; in Outlook, \"View\" then \"Message details\"; in Apple Mail, View then Message then All Headers."
      }
    ],
    "parts": []
  }
}

Resell mailbox licences for the domains you just checked, under your own brand.

Get started

Company names and logos are trademarks of their owners, shown only to identify each service.