Email Header Analyzer
Paste raw email headers to inspect reported SPF, DKIM, and DMARC results—including assertions preserved in ARC headers—and trace the message route from its origin toward your inbox.
Private, local-only analysis
Your pasted headers stay in this browser tab. They are not uploaded, stored, added to the URL, or sent to an analysis API.
What does an email header analyzer show?
Email headers record routing and processing metadata added as a message moves between mail systems. This tool unfolds copied RFC 5322 header fields, summarizes common message identifiers, reads reported authentication assertions, and reverses Received fields into a more natural origin-to-inbox timeline.
How to find raw email headers
In your mail provider, open the message menu and look for an option such as “Show original,” “View source,” or “View message details.” Copy the complete header block, including Received and Authentication-Results fields, then paste it above. You can paste a full message, but Zunavek stops before the body and does not inspect attachments, links, or tracking pixels.
- Gmail: open the message, select More next to Reply, choose Show original, then use Copy to clipboard.
- New Outlook or Outlook on the web: select More actions, then View and View message details. In classic Outlook for Windows, open the message and use File, Properties, then Internet headers.
- Apple Mail on Mac: open the message and choose View, Message, All Headers. Copy the full source when available so folded and repeated fields remain intact.
How to read the Received route
A mail server normally adds a Received field above the fields already present. That means the raw message shows the newest transfer first. Zunavek reverses those fields so the table starts with the oldest observed handoff and ends near the recipient. Each row separates the reported sending host, receiving host, transport protocol, and timestamp when those parts can be parsed conservatively.
A long interval between two timestamps can indicate queueing, greylisting, content scanning, a temporary remote-server failure, or clocks that disagree. It does not identify blame by itself. Missing rows are also possible: internal systems can omit details, gateways can rewrite fields, and a copied excerpt may be incomplete. Use the raw values and mail-server logs when an exact delivery investigation matters.
SPF, DKIM, DMARC, and ARC in message headers
Authentication-Results records what a receiving service says it checked. SPF evaluates whether the sending IP was authorized for the envelope sender. DKIM reports whether a cryptographic signature validated for its signing domain. DMARC evaluates alignment between an authenticated SPF or DKIM domain and the domain visible in From. ARC can preserve earlier authentication observations when an intermediary such as a mailing list modifies or forwards a message.
A reported pass is useful troubleshooting evidence, but it is not a trust verdict. A legitimate domain can be compromised, a lookalike domain can authenticate correctly, and an attacker can insert a forged Authentication-Results field. Only the recipient's trusted mail boundary can decide which result fields it created and trusts. This analyzer therefore keeps the reporting service beside every parsed result and never labels a message safe.
Accuracy and trust limits
A copied header is evidence supplied by the message itself. Attackers can add misleading fields, timestamps can be malformed, and only a receiving system knows which authentication service identifiers it trusts. Use this report for troubleshooting, not as a phishing, malware, reputation, or safety verdict. For current DNS policy checks, use the Email Security Checker.
Privacy model
Raw headers can expose personal email addresses, internal hostnames, public or private IP addresses, mailing list identifiers, and unique message IDs. Zunavek parses the text in page memory and does not place it in a request, URL, cookie, local storage, or saved report. Clear removes the current input and result from the page. Closing or refreshing the tab also discards the analysis. If you share a screenshot or copied result, review those identifiers and redact anything sensitive first.
Related email and DNS tools
- Reverse DNS Lookup — inspect PTR records for a mail server IP.
- Forward DNS Lookup — inspect MX, TXT, A, AAAA, and NS records.
- SPF, DKIM, and DMARC guide — understand how the three authentication layers work together.
Email header analyzer FAQ
Does this verify DKIM signatures?
No. It reads a receiving server's reported DKIM result from copied headers. Independent verification would require the original signed message bytes and the current public key, and copied content can change in ways that invalidate a signature.
Can a header reveal the sender's real IP address?
Sometimes a Received or X-Originating-IP field contains an address associated with an early handoff. Many webmail and privacy-conscious providers omit the user's address, while relays and gateways add their own addresses. Treat every address as route evidence, not guaranteed proof of a person's location.
Why is a message missing SPF, DKIM, or DMARC results?
The recipient may not publish results in the copied header, an upstream system may have stripped them, or only part of the source was copied. A missing field means this paste contains no parseable assertion; it does not prove that the check never happened.
Can I use this to confirm phishing?
No. Headers help investigate routing and authentication, but phishing can arrive from authenticated, compromised, or deceptive domains. Review message content, requested actions, destination links, account context, and your organization's security process before acting.