Paste email headers to trace the sender's delivery path
This tool takes the raw header text of an email that you paste in, splits it into Field-Name: value pairs, lists the most useful ones (sender, recipient, subject, date and a few others) in a separate block, and numbers every Received record so you can roughly follow the servers a message passed through. It only parses and tidies text. It does not look up IPs or domains online, it does not verify SPF, DKIM or DMARC itself, and it does not decide whether a message is phishing or spam. If the header contains Authentication-Results, Received-SPF, DKIM-Signature or ARC fields, they are listed in a separate section exactly as the header states them (for example spf=pass), but that is text written into the header by a server, not a verdict from this tool. Think of it as a way to make headers easier to read, not as a security scanner.
The output below comes from running the same parsing logic the tool uses. The input header had two Received records (each continued on a second line that starts with whitespace, which marks a continuation), plus From, To, Subject, Date and Message-ID. The tool first joins the indented continuation lines onto the line above, so the first Received parses as: from mx.example.net (mx.example.net [203.0.113.5]) by mail.example.org with ESMTPS; Tue, 2 Jan 2026 09:00:05 +0800. The second parses as: from sender-pc (unknown [198.51.100.7]) by mx.example.net with SMTP; Tue, 2 Jan 2026 09:00:02 +0800. The page labels the first one #2 and the second one #1, so reading from #1 to #2 follows the message from the sending machine through mx.example.net to mail.example.org. The domains and IP addresses in this example are reserved documentation values used only for illustration.
Each server that handles a message adds its own Received line at the top of the header block. So lines lower down are older and lines higher up are newer. That is why the tool marks the bottom one as #1.
It is common and not necessarily a problem. Bulk mail, mailing lists and third-party sending services often use a different bounce address. But if a message claims to come from your bank or employer and the origin details clearly do not fit, be cautious. Use the verification result your mail client shows, and what the authentication section reports the header as saying, alongside this, because the tool only lays the fields out for you.
Not on its own. It shows the SPF, DKIM and DMARC results the header claims but does not verify them, and it does not inspect links or attachments. You can compare From, Reply-To and Return-Path side by side, but trust still depends on the message content, the sending domain and the warnings from your mail provider. For anything involving payments or passwords, confirm through an official channel.
If the box is empty or contains only whitespace, no result is shown. If nothing you pasted has a line with a colon, the page shows a red message. Copying from some web pages can also lose indentation or line breaks, which makes fields merge or split wrongly, so try copying straight from your client's original message window.
Headers can contain email addresses, server hostnames and IP addresses. All parsing here happens in your browser. The page contains no network request code and does not store what you paste. Even so, before sending a header to someone for help, review it and remove anything you do not want to share.