Email Header Analyzer.
Paste raw email headers. We reconstruct the delivery path, surface SPF/DKIM/DMARC verdicts, and flag deliverability issues — every Received hop, every Authentication-Results line, every clue.
checklist What the analyzer checks
- check Received chain — every hop the message took, in reverse chronological order, with timestamps and hostnames.
- check Authentication-Results — every SPF, DKIM, DMARC, ARC, and BIMI verdict the receiver reported.
- check From / Return-Path alignment — whether the visible sender and the bounce address match for DMARC.
- check DKIM signatures — selector, domain, header fields covered, algorithm.
- check SPF verdict — pass/fail/softfail, and the policy that produced it.
- check Hop timing — how long each leg took. Slow hops often indicate greylisting or relay congestion.
Paste headers above to start.
You can copy headers from Gmail (Show original), Outlook (Properties), Apple Mail (View → Message → All Headers), or any mail client. We never store the content; analysis is in-memory.
verified Authentication summary
timeline Delivery path
policy Authentication-Results
data_object Key headers
How to copy raw headers from your mail client
Email headers live underneath the message body and most clients hide them by default. Here's where to find them — paste everything from the first Received: line onward.
Open the message → ⋮ (three-dot) menu → Show original → copy everything from the "Original Message" panel.
Open the message → File → Properties → copy from the "Internet headers" box at the bottom.
Open the message → ⋯ (more actions) → View → View message source → copy the full source.
Open the message → View → Message → All Headers (or ⇧⌘H) → copy the headers panel.
Open the message → View → Headers → All (or Ctrl+U for source) → copy the header view.
Mobile clients usually don't expose raw headers. Forward the message to yourself, then open the forwarded copy in a desktop client to retrieve them.
Why MSPs lean on a header analyzer
Most deliverability tickets begin the same way: a client forwards a bounce or a "this customer didn't get my invoice" complaint. The fastest path to root cause is the headers of the failing message. Without a parser, the technician spends ten minutes mentally reversing the Received chain, cross-referencing Authentication-Results against the From: domain, and squinting at DKIM-Signature tags. With a parser, the same triage takes ninety seconds. Multiply that by the number of deliverability tickets across a portfolio of fifty clients and the time saved compounds into real margin.
- check_circle Reduce the average deliverability ticket from 30 minutes to under 10 by skipping the manual header reverse-engineering.
- check_circle Standardize triage across the team — every analyst sees the same parsed view, so handoffs don't lose context.
- check_circle Document evidence quickly — copy the parsed summary into the ticket instead of attaching raw 4KB header blobs.
- check_circle Catch alignment failures (the most common silent deliverability killer) without having to remember the exact DMARC rule.
- check_circle Spot ARC chain integrity issues in forwarded mail without manually decoding the seal.
Worked example: a real triage
Here's the exact mental model an experienced analyst follows. Use this as your runbook when staring at a fresh set of headers.
-
1
Read the top Authentication-Results first
It's the verdict added by your final receiver — the most authoritative line in the entire header block. Three pass verdicts means the message is authenticated; any fail means there's work to do. Lines added by upstream hops can be informational but should never override the bottom-line verdict.
-
2
Compare From: to Return-Path:
If the domains differ, alignment depends on DKIM. Note both — you'll need them when you check the DKIM-Signature's d= tag against the From: domain. If the domains match, alignment is automatic and your only check is whether the records authenticate at all.
-
3
Walk the Received chain bottom-to-top
The bottom Received: is the originating server. Each subsequent line is the next hop forward in time. Long gaps between hops (>30s) suggest greylisting; impossible reverse-time gaps suggest forgery. The top Received: should be your own receiving server.
-
4
Inspect each DKIM-Signature's d= tag
Every legitimate signer adds a DKIM-Signature. The d= tag tells you who signed it. Compare d= to the From: domain — if they match (or share an organizational domain), DKIM alignment passes.
-
5
If ARC headers are present, check cv= on the most recent ARC-Seal
cv=pass means the chain is intact and the original auth verdict survived the forwarding. cv=fail means something broke the chain — usually a list server that modified the body without re-signing.
-
6
Form the verdict + write the ticket
Now you have everything you need. Document the verdict (legitimate / spoofed / broken-but-legitimate), the specific failing check, and the remediation. The whole process should take under two minutes once it's muscle memory.
Reading the verdicts
Every Authentication-Results header reports verdicts using a small fixed vocabulary. Here's what each means — and what action (if any) it should trigger.
pass
What it means: The check succeeded. SPF authorized the sending IP, DKIM verified cryptographically, or DMARC found at least one aligned authenticated identity.
Action: Nothing to do. This is the desired state for every legitimate message.
fail
What it means: The check explicitly failed. For SPF: the sending IP isn't in the policy. For DKIM: the signature didn't verify. For DMARC: no aligned authenticated identity was found.
Action: Investigate. Legitimate mail failing means a missing SPF include, a wrong DKIM selector, or a broken alignment. Spoofed mail failing means DMARC did its job.
softfail
What it means: SPF-specific. The sending IP isn't authorized but the policy ends with ~all (soft fail) rather than -all (hard fail). Receiver usually accepts but downgrades reputation.
Action: Audit SPF. If the IP should be authorized, add the include. If not, tighten the policy to -all once you're confident the inventory is complete.
neutral
What it means: SPF policy is explicitly "no opinion" (?all). Almost never appropriate for production senders.
Action: Replace ?all with -all or ~all. ?all signals the receiver to ignore SPF, which defeats the protection.
none
What it means: No relevant record was found. For SPF/DKIM, the domain hasn't published one. For DMARC, no _dmarc TXT exists for the From: domain.
Action: Publish the missing record. "none" is functionally equivalent to "no protection" — receivers can't enforce a policy that isn't there.
temperror
What it means: The check couldn't complete due to a transient error — usually a DNS timeout or rate limit at the receiver.
Action: Re-check the same domain a few minutes later. If it persists, investigate the authoritative DNS provider's health.
permerror
What it means: The check couldn't complete due to a permanent error — usually a malformed record or an SPF lookup-count overflow.
Action: Fix the underlying record. permerror is one of the silent-killer states; many receivers treat it the same as fail.
Spotting phishing red flags in headers
Header analysis is your first-line tool for confirming whether a suspected phishing message is forged or legitimate. The patterns that almost always indicate a problem:
Classic spoofing technique — bounces go to the attacker's domain so SPF passes, but the human-visible sender looks like the target brand. DMARC alignment is the protection.
The attacker has set up DKIM for their own throwaway domain and is hoping you don't notice that the signature doesn't authenticate the From: identity.
Legitimate corporate mail rarely originates from residential broadband or directly from spot-instances. Worth a closer look at the sending platform.
Common in business-email-compromise (BEC) attacks — the visible sender looks right but replies go to the attacker.
Legitimate enterprise mail goes through M365, Workspace, or a known transactional platform. Mass-mailing scripts often leak themselves in X-Mailer.
Forged Message-IDs are a tell that the sender is impersonating multiple identities in one message.
Attackers sometimes forge Received chains. Backward-running timestamps or hops to nowhere are dead giveaways.
Which DMARC-AI tool should you use?
Header analysis answers "what happened to this one message". The rest of the suite answers "what's the configuration state of the domain". Match the question to the tool:
| Question | Use this tool |
|---|---|
| A specific message bounced or got marked spam | Email Header Analyzer arrow_forward |
| Is this domain's DMARC policy correct? | DMARC Checker arrow_forward |
| Building a new DMARC record for a client | DMARC Record Generator arrow_forward |
| SPF includes are getting close to the 10-lookup limit | SPF Analyzer arrow_forward |
| A DKIM selector seems wrong or missing | DKIM Validator arrow_forward |
| Need a wider DNS snapshot across resolvers | DNS Lookup arrow_forward |
| Inbox logos / brand impersonation question | BIMI Generator arrow_forward |
| MITM / TLS-downgrade concerns on inbound mail | MTA-STS Check arrow_forward |
Privacy: what happens to your headers
Headers often contain sensitive metadata — recipient lists, internal infrastructure hostnames, audit trails. We treat them accordingly. When you drop a file or paste headers, the content is held only in your browser until you press Analyze. The submit is a single POST to the analyzer endpoint, parsed in memory, returned as structured JSON, and discarded. We do not log headers, we do not cache them, and they never touch our database. The badge counter that increments on submit only stores the From: domain (lowercased) for aggregate "today's analyses" display — never the message content.
Anatomy of an email header
Every Received hop, Authentication-Results line, and signing tag plays a specific role in establishing whether a message is legitimate. Here's what the analyzer pulls out — and what each field actually means.
Received:
Hop record
One line per mail server that handled the message, in reverse chronological order. The bottom-most Received: is the originating server; the top-most is your inbox's final hop. Forged senders often have suspicious or missing early hops.
Authentication-Results:
Verdict summary
Added by the receiving server. Reports the SPF, DKIM, DMARC, ARC, and (sometimes) BIMI verdicts the receiver computed. This is the line your DMARC reports are ultimately summarizing.
Return-Path:
Envelope sender
The address bounces go to. SPF checks against this domain — not the visible From:. When Return-Path and From: are different domains, you may need DKIM alignment to pass DMARC.
From:
Visible sender
What the user sees. DMARC alignment requires either SPF or DKIM to authenticate a domain that matches From: — that's the anti-spoofing guarantee.
DKIM-Signature:
Cryptographic signature
Each Authorized Sending Identity adds its own DKIM-Signature header. Tags include d= (signing domain), s= (selector), h= (headers covered), a= (algorithm). The receiver verifies the signature against the public key at s._domainkey.d.
ARC-* (Seal, Signature, Authentication-Results)
Indirect-flow integrity
When messages traverse mailing lists or forwarders, ARC preserves the original authentication verdict downstream. ARC is the reason "but it worked before they forwarded it" no longer means a guaranteed DMARC fail.
Message-ID:
Unique identifier
Assigned by the originating server. Useful for cross-referencing bounce reports, abuse complaints, and downstream incident investigations.
Received-SPF:
Detailed SPF result
A more verbose alternative to the SPF line inside Authentication-Results. Includes the policy that was evaluated and the IP that was checked.
Common header-analysis findings
When deliverability is broken, the answer is almost always in the headers. Here are the eight patterns we see most often — and what each one means.
priority_high high SPF pass, DKIM pass, DMARC fail expand_more
Classic alignment failure. SPF authenticated the Return-Path; DKIM authenticated d=; neither matches the From: domain. You need at least one of SPF or DKIM to align with From:. Usually means you're relaying through a third party that bounces to their own domain.
priority_high high DKIM signature missing expand_more
Sender never signed the message. Either DKIM isn't configured at the originating platform, or the platform is using a selector that doesn't exist in DNS. Check that selector._domainkey.signing-domain returns a public key.
priority_high high DKIM signature present but verification failed expand_more
The signature didn't cryptographically verify. Usually means a relay in the path modified the body (added a footer, rewrote URLs) or the signing key has been rotated and the old public key is gone. Check h= for which headers were signed and l= for body-length limits.
warning medium SPF softfail (~all → ~) expand_more
The sender's IP isn't in the SPF record but the policy is "soft fail". Receivers usually accept these but may downgrade reputation. Audit the SPF record — if this IP should be authorized, add the include. If not, harden SPF to -all.
warning medium Too many Received hops (>10) expand_more
Unusual hop counts often indicate a forwarding loop, a relay that's incorrectly inserting itself, or a misconfigured MX. Each extra hop adds latency and risks DKIM body modification.
warning medium ARC chain broken (cv=fail) expand_more
The Authenticated Received Chain failed validation at some intermediate hop. Means downstream receivers can no longer trust the original authentication verdict — the message will be evaluated as if it came directly from the last hop.
info low Slow hops (>30s between Received lines) expand_more
Long delays between hops usually mean greylisting (deliberate first-time delay) or queue congestion. Not a security issue by itself, but worth flagging for time-sensitive transactional mail.
info low BIMI selector defined but no VMC/CMC expand_more
BIMI record exists but the certificate URL is missing or invalid. Logo won't display in supporting clients. Either complete BIMI setup with a Verified Mark Certificate, or drop the BIMI record to avoid noise in your reports.
Header Analyzer vs eyeballing the source
Reading raw headers in a terminal is a skill some engineers genuinely enjoy. But for routine deliverability triage — especially across an MSP portfolio — a parser saves time and prevents the kind of mistakes that happen at the end of a long day. The analyzer chronologically orders Received hops (raw headers are in reverse order, which is the source of half the wrong conclusions), highlights the Authentication-Results line that's actually authoritative (vs the ones forwarders added), and surfaces DMARC alignment without making you mentally cross-reference Return-Path and From:. For one-off investigations of a sophisticated phishing attempt, drop to a terminal. For triage volume, use the parser.
Pair the analyzer with the rest of the stack
DMARC Validator
Once headers show DMARC failures, check the policy itself — pct=, sp=, fo= reporting flags.
SPF Analyzer
If headers show SPF fail, walk through the SPF record and see which authorization is missing.
DKIM Validator
When DKIM verification fails, validate the public key at selector._domainkey to rule out a DNS issue.
DNS Lookup
Inspect SPF, DMARC, DKIM, MX, A records across multiple resolvers to compare propagation.
Continue learning
Header analysis covers the symptom. These articles cover the root cause.
DMARC Alignment Explained
Why SPF can pass and DMARC still fail — the alignment requirement spelled out.
Reading DMARC Aggregate Reports
The XML format, what each field means, and what to act on first.
Why DKIM Signatures Break in Transit
Body modification, header rewrites, mailing-list forwarders — and how ARC fixes some of it.
Forensic (RUF) Reports vs Headers
When to use forensic reports vs paste the headers you already have from a single complaint.
Authoritative references
The standards the analyzer is checking your headers against.
Header Analyzer FAQ
Do you store the headers I paste? expand_more
No. Analysis is in-memory only. The headers leave our server after the response is sent — they are not logged, not cached, not retained.
Why is my SPF showing pass but DMARC failing? expand_more
SPF can pass against the envelope-sender (Return-Path) while the visible From: header is a different domain — DMARC requires alignment between From: and either SPF or DKIM. Read more in the DMARC Alignment Explained article.
Can I paste partial headers? expand_more
Yes, but the more you paste the deeper the analysis. We need at least the Authentication-Results and one Received line to produce a useful verdict.
What about ARC (Authenticated Received Chain)? expand_more
We parse ARC-Authentication-Results, ARC-Seal, and ARC-Message-Signature when present, and surface the chain integrity status (cv=pass/fail/none).
How do I find the originating IP of a phishing attempt? expand_more
Look at the bottom-most Received: line — that's the first hop. Be careful: sophisticated senders forge Received lines below their actual entry point, so corroborate with SPF's claimed IP and the actual signing domain in DKIM-Signature.
Why does my Authentication-Results show multiple lines? expand_more
Each receiver in the chain may add its own Authentication-Results. The one to trust is the line added by your final receiving server (the top-most one) — the others may have been added by an attacker upstream.
Can I use this for forensic investigations of phishing? expand_more
It's a triage tool, not a forensic platform. For deep investigation, pair the analyzer output with your DMARC aggregate reports, your SIEM, and the raw .eml file in a forensic mailbox.
What does cv=pass on ARC mean? expand_more
cv stands for chain validation. cv=pass means the ARC chain from the originating signer through every intermediate hop is intact — receivers downstream can trust the original auth verdict.
Stop chasing deliverability mysteries.
Header analysis is reactive. DMARC AI continuously monitors auth posture across every client domain so you spot deliverability drift before users complain.