Skip to main content

Email Header Analyzer

Available
Security

Analyze raw email headers: authentication results, Received routing, sender identity, timestamps, and header anomalies, all in your browser.

Email Header Analyzer tool

Email header input

Email headers can contain addresses, IPs, server names, message IDs, and other metadata. Only analyze headers you are authorized to inspect. Processing happens in your browser and the headers are not uploaded.

Paste only the email headers. Do not paste the email body. The body is not needed. Folded (multi-line) headers, repeated headers and any header order are supported. Press Ctrl/Cmd+Enter to analyze.

Where to find email headers

Gmail: open the message, choose the three-dot menu (More), then Show original, and copy the header block at the top.

Outlook: open the message, choose File then Properties (desktop), or View message details / View message source (web), and copy the Internet headers.

Apple Mail: choose View, Message, All Headers (or Raw Source).

Other providers: look for "Show original", "View source", "Message headers" or "Internet headers" in the message menu. Menu wording changes between versions and providers, so the labels above may differ slightly.

Copy only the headers (the lines before the first blank line). If you paste the whole message, the body is ignored.

No analysis yet

Paste raw email headers to inspect authentication results, mail-server routing, timestamps, and header anomalies. Use Load Example to try a sample.

Privacy & Limitations

Your email headers may contain sender addresses, recipient addresses, IP addresses, message IDs, mail-server names, and other metadata. Process headers only from messages you are authorized to inspect. This tool parses and analyzes the headers in your browser. Nothing you paste is uploaded, stored, sent to analytics, or looked up with any external service, and no IP geolocation is performed.

Email headers can provide useful authentication and routing information, but they cannot by themselves prove that a message is safe or malicious. This tool reports technical observations. It does not label a message safe, malicious or phishing, and the Email Authentication Health score is not a phishing score.

About email headers

What are email headers?

Email headers are the lines of metadata at the top of every message, before the body. They record who the message is from and to, the subject, the date, a unique Message-ID, the route it took through mail servers, and the results of checks such as SPF, DKIM and DMARC. Mail apps hide most of them, but they are the main evidence when you need to understand why a message was delayed, rejected, filtered or looks odd.

This email header analyzer (you may also think of it as an email header checker, parser or decoder) turns the raw text into a structured view of authentication, routing, timestamps and anomalies. It reads standard headers, so it works with Gmail, Microsoft 365, Yahoo, Postfix, Exim and other servers without provider-specific rules.

What this analyzer checks

  • Header structure: folded lines, repeated headers, case-insensitive names, malformed lines and control characters.
  • SPF, DKIM, DMARC and ARC results as reported by receiving servers, kept separate for every Authentication-Results header.
  • Sender identity: From, Reply-To, Sender and Return-Path, with domain alignment shown against DMARC.
  • The Received chain as a delivery path, with servers, IP addresses, protocols, TLS indications and time between hops.
  • Date and timestamps converted to UTC, plus clock anomalies and potential delays.
  • Technical observations with a severity and a recommended next step, and a transparent Email Authentication Health score.

How email authentication works

SPF lets a domain list the servers allowed to send mail for its envelope sender. DKIM lets a domain sign a message so receivers can confirm it was not altered. DMARC ties the two to the visible From domain and tells receivers what to do when neither aligned check passes. ARC lets intermediaries such as forwarders and mailing lists preserve the results they saw.

The receiving server performs these checks and records the outcome, usually in an Authentication-Results header. This tool reads that record. It does not repeat the checks: it performs no DNS lookups, fetches no DKIM keys and verifies no signatures, so a missing result is shown as unknown, never guessed.

How to interpret the results

  • Received headers are read bottom to top. The bottom line is the first server that received the message. Lines added by servers outside your control are claims, not guarantees.
  • Date vs Received: the Date header is set by the sender and may be wrong. Received timestamps are added by receiving servers.
  • Severity: Good means a check passed as reported, Info is context, Warning is worth a look, and High is reserved for strong technical reasons such as a DMARC fail or multiple From headers.
  • Private IPs and mismatched domains are common in legitimate mail, so they are shown for context rather than raised as alarms.

Limitations

Email headers can provide useful authentication and routing information, but they cannot by themselves prove that a message is safe or malicious. A phishing email can pass SPF, DKIM and DMARC for a domain the attacker owns, and a legitimate message can fail after forwarding. This is not a phishing detector, the score is not a safety rating, and an IP address in a header does not show where a person is.

DKIM and ARC signatures are detected but not cryptographically verified here. Organizational-domain matching for relaxed alignment uses a short built-in suffix list, so it is approximate for unusual domains.

Privacy

Headers can contain addresses, IPs, server names and message IDs. Processing happens in your browser and the headers are not uploaded, stored, sent to analytics or looked up externally. Only analyze headers from messages you are authorized to inspect. If you need to share a header for support, mask the sensitive parts first with the Log Sanitizer.

Related tools and guides

Reviewing how your website protects visitors is the web-side counterpart of email authentication: the HTTP Security Headers Analyzer and CSP Analyzer check the response headers your site sends, the Redirect Chain Analyzer follows link redirects hop by hop, and the Open Graph & Social Preview Analyzer checks how a page looks when shared.

New to this? Start with How to Read Email Headers, SPF vs DKIM vs DMARC Explained and How to Investigate Suspicious Emails Using Headers.

Did this help you make sense of an email header?

If these free developer tools save you time, consider buying me a byte. Your support helps keep DevCraftKit free and growing.

Buy me a byte 💾

Resources

View all

Explore more developer tools

Browse the full collection, or see everything in Security.

Email Header Analyzer FAQ

What is an email header?
An email header is the block of metadata lines that travels with every message, above the body. It records the sender and recipients, the subject, the date, a unique Message-ID, and a Received line added by each mail server that handled the message. Authentication results such as SPF, DKIM and DMARC are usually recorded there too. Most mail apps hide headers by default, but they are the main source of evidence when you troubleshoot delivery or inspect a message.
How do I find email headers?
In Gmail, open the message, choose the three-dot menu and then Show original. In Outlook, open the message properties or the message details, and look for Internet headers. In Apple Mail, choose View, Message, All Headers. Other providers usually call it Show original, View source or Message headers. Menu wording changes between versions, so treat these labels as a guide. Copy only the header lines, not the body.
Can I trace an email using its headers?
You can reconstruct the path a message took between mail servers by reading the Received headers from the bottom (the first server) to the top (the final recipient server). That shows which servers handled the message and when. It does not reliably reveal who wrote it or where they were. Headers added by servers you do not control are claims, and the Received lines below your own provider's can be invented by a sender.
What does Received mean?
Each mail server that accepts a message adds a Received header at the top, noting which server it came from, which server received it, the protocol used, a queue ID and a timestamp. Because every server adds its line above the previous ones, the headers read newest first. The analyzer reverses them into a delivery path and shows the time between hops.
What does SPF PASS mean?
SPF PASS means the receiving server checked the domain in the message's envelope sender (the Return-Path / MAIL FROM, or the HELO name) and found that the connecting IP address is authorized by that domain's SPF record. It does not check the visible From address, and it does not mean the message is trustworthy. This tool shows the result the receiving server reported; it does not look up SPF records itself.
What does DKIM PASS mean?
DKIM PASS means the receiving server verified a cryptographic signature added by a domain, which shows that the signed headers and body were not changed after signing and that the signing domain's key was used. The signing domain may or may not be the same as the From domain, and the signature says nothing about whether the content is safe. This tool shows what the receiver reported. It detects DKIM-Signature headers but does not perform cryptographic verification.
What does DMARC PASS mean?
DMARC PASS means that SPF or DKIM passed and that the passing domain aligned with the domain in the visible From address, as required by the From domain's DMARC policy. It is the check that ties authentication to the address people actually see. It does not mean the sender is honest: a malicious sender can authenticate with a domain they own.
Can email headers prove who sent an email?
No. Headers give useful technical evidence, such as which domains authenticated and which servers handled the message, but many headers are written by the sender's own system and can be falsified. Authentication results recorded by your own receiving provider are the most reliable parts. Even a fully authenticated message only proves that the authenticating domain approved it, not who the person behind it is.
What is Return-Path?
Return-Path records the envelope sender, the address bounce messages go to. The final receiving server usually writes it from the SMTP MAIL FROM command. It is what SPF checks. It often differs from the From address, especially for newsletters and cloud mail services, and that is normal. It does not prove who actually sent the message.
What is Authentication-Results?
Authentication-Results is a header added by a receiving mail system to record the outcome of its checks, such as spf=pass, dkim=pass and dmarc=pass, along with the domains involved and the name of the server that produced the results. A message can contain several of these headers because different systems record results at different points. Only results added by a system you trust, normally your own mail provider, should be relied on.
Why does Reply-To differ from From?
There are many legitimate reasons: support desks, contact forms, mailing lists, newsletters and assistants sending on someone's behalf all use a different reply address. It can also be used to redirect replies to an attacker, so it is worth a second look when the message is unexpected. The analyzer flags the difference as something to review, not as proof of anything.
Can I find the sender's IP address?
Often you can see the IP address of the server that connected to the first receiving server, in the oldest Received header. That is the sending mail server, not necessarily the person's own device, and it is frequently a shared server belonging to a mail provider. Some webmail services hide or never record the user's address. This tool lists IP addresses with their source header and labels private and public ranges, but it performs no lookups and no geolocation.
Why are there multiple Received headers?
Every mail server, gateway, spam filter, mailing list and forwarder that handles a message adds its own Received line. Several hops are normal: the sender's mail server, an outbound relay, a security gateway at the recipient, and finally the mailbox server. Internal hops often show private IP addresses, which is expected.
Can this tool detect phishing?
No. Email headers can provide useful authentication and routing information, but they cannot by themselves prove that a message is safe or malicious. This tool highlights technical observations such as failed authentication, mismatched Reply-To or malformed headers so that you can review them, and its Email Authentication Health score reflects those observations only. Judging whether a message is phishing also requires its content, links, attachments and context.
Is my pasted email header stored?
No. The analysis runs entirely in your browser. Nothing you paste is uploaded to a server, saved to a database, written to local storage, sent to analytics, or looked up with any external service. Closing or reloading the page discards it. Email headers can still contain personal information, so only analyze headers from messages you are authorized to inspect.

Found a bug or an incorrect result in Email Header Analyzer?

Report it, or suggest an improvement. Messages go straight to the developer.

Send feedback