Email header parser guide

Every mail client hides headers by default. To see them:

• Gmail. Open the message, click the three dots next to Reply and choose "Show original". Gmail also shows a short summary of SPF, DKIM and DMARC at the top.
• Outlook on the web and new Outlook. Open the message, use the three dots menu, then "View" and "View message details".
• Classic Outlook for Windows. Open the message in its own window, then File and Properties. The headers are in the "Internet headers" box.
• Apple Mail. View, Message, All Headers, or save the message as a .eml file.

Copy everything from the first line down to the first blank line. That block is the header. Paste it into the free email header parser, which lists the hops, delays and authentication results without sending anything to a language model.

A header is a list of Name: value lines. Long values continue on the next line, indented with a space or tab. Two kinds of headers matter for analysis:

• Headers written by the sender's software: From, To, Subject, Date, Message-ID, Reply-To, MIME-Version. The sender controls them, so they prove nothing on their own. A forged From line looks exactly like a real one.
• Headers added on the way: Received, Authentication-Results, ARC headers, DKIM-Signature, Return-Path. Each server that handles the message adds its own lines at the top. The ones added by your own provider are the ones you can trust.

That last point explains the reading order. The top of the header is the most recent and most trustworthy, the bottom is the oldest and closest to the sender.

Each server adds one Received line describing the hop it was part of. A typical line:

Received: from mail-out.vendor.example (mail-out.vendor.example [198.51.100.24])
        by mx.yourcompany.example with ESMTPS id 4f9a2c
        for <[email protected]>;
        Tue, 14 Oct 2026 09:12:41 +0000

Read it as: the server by received the message from the server named in the first part, at the given time. Two names appear in the from part. The first is the name the sending server announced about itself. The one in brackets, with the IP address, is what the receiving server actually saw. When they disagree, believe the bracket.

Walk the chain from the bottom line up:

1. The lowest Received line is the first hop, often inside the sender's own network. Its contents are only as trustworthy as that network.
2. Follow each hop upward. The by server of one line should be the from server of the line above it.
3. The first line added by your own provider marks the boundary. Everything above it is your infrastructure. Everything below it is claimed by others.

Internal hops with private addresses (10.x, 172.16.x to 172.31.x, 192.168.x) are normal inside large providers and do not indicate a problem.

Each Received line has a timestamp. The difference between consecutive lines is the time the message spent on that hop. A header parser does this arithmetic for you and converts time zones, which is where manual reading usually goes wrong.

Things to keep in mind:

• A long delay usually sits on the hop where one organization hands over to another. Greylisting and temporary refusals cause retries measured in minutes.
• A negative delay means one server's clock is wrong. It does not mean the message travelled back in time, and it makes delay figures on that hop unreliable.
• Compare the Date header with the first Received line. A large gap there means the sender's client held the message, for example in an outbox while offline.

Your provider records the outcome of its checks in an Authentication-Results header:

Authentication-Results: mx.yourcompany.example;
       spf=pass smtp.mailfrom=bounces.vendor.example;
       dkim=pass header.d=vendor.example header.s=s1;
       dmarc=pass (p=REJECT) header.from=vendor.example

DMARC is the one that connects the checks to what the reader sees. A message can pass SPF for bounces.mailing-tool.example and still claim to be from your bank. Only DMARC alignment ties the pass to the From domain.

Results you will see: pass, fail, softfail (SPF only, the domain says "probably not allowed"), neutral, none (no record published), temperror and permerror (a DNS problem or a broken record). Forwarded mail often fails SPF because the forwarding server is not in the original sender's record. DKIM normally survives forwarding unless a mailing list changes the subject or body, and ARC headers can carry the original results across such hops.

Only trust Authentication-Results lines added by your own provider. A sender can insert a fake line further down the header.

• Message-ID is a unique id the sending software assigns, such as <[email protected]>. It identifies the message across forwards and copies, which makes it the most reliable key for spotting duplicates. Its domain part often reveals the software or service that created the message.
• In-Reply-To and References list the Message-IDs of earlier messages in a thread. Mail clients use them to group conversations.
• Return-Path is the envelope sender, where bounces go. It often differs from From when mail is sent through a sending service.
• Reply-To overrides where replies go. A Reply-To on a different domain than From is a classic sign of invoice fraud.

Message-ID is also how parsing tools avoid working on the same email twice. ParsedMail, for example, treats a second email with the same Message-ID in the same inbox within 30 days as a duplicate. The article on inbound email webhooks explains why that matters for automations.

None of these patterns is a verdict on its own. Combine them with the route, the timing and the content before you decide a message is fraudulent.

1. Find the first Received line added by your provider and note the IP address it saw.
2. Read Authentication-Results from that same provider. Is DMARC pass, and for which domain?
3. Compare the From domain, the Return-Path domain, the DKIM header.d and the Reply-To domain. Unexplained differences need an explanation.
4. Check the delays. A message that claims to be urgent but was written hours before it was sent is worth a second look.
5. Look at the Message-ID domain. A message claiming to come from a large company with a Message-ID from an unrelated host is unusual.

Header analysis is about routing and authenticity. When you need the content of emails turned into data, such as order numbers, totals or lead details, that is a job for an email parser instead. To parse email headers and authentication results in one step, paste them into the free header tool.