Understanding the Email Header Decoder

The Email Header Decoder is a client-side utility built with Alpine.js that parses raw RFC 5322 email headers. By examining the structural metadata of an email, this tool extracts routing paths, cryptographic authentication results, and fundamental message details. Because it operates entirely within your browser using JavaScript, the sensitive metadata contained in your email headers is never transmitted to an external server for processing.

Core Parsing Logic and Header Folding

Email headers are not always simple single-line key-value pairs. According to RFC specifications, headers can be "folded" across multiple lines. The decoder handles this structural complexity using a line-by-line parsing algorithm. It splits your input text by standard and carriage-return newlines (\r?\n).

As it reads each line, the tool checks for whitespace at the beginning of the string (^\s). If a line starts with a space or tab, the tool recognizes it as a continuation of the previous header and seamlessly appends it. For standard lines, it locates the first colon character (:), using everything to the left as the header key (normalized to lowercase) and everything to the right as the value. This ensures that complex fields, especially lengthy authentication results or routing hops, remain intact.

Message Summary Extraction

Once the header block is normalized into a programmatic object, the tool isolates the five most critical fields for a quick summary:

• Subject: The subject header.
• From: The declared sender in the from header.
• To: The intended recipient in the to header.
• Date: The origination timestamp in the date header.
• Message-ID: The globally unique identifier located in the message-id header.

Security and Authentication Analysis

Email spoofing is prevented through three primary authentication frameworks: SPF, DKIM, and DMARC. The decoder explicitly looks for these signatures to determine the message's legitimacy.

• SPF (Sender Policy Framework): The tool scans for the received-spf or authentication-results header. If it detects the substring pass (case-insensitive), it flags the SPF status as a success. Otherwise, it defaults to a fail/neutral status.
• DKIM (DomainKeys Identified Mail): It inspects the dkim-signature or authentication-results headers. If the signature indicates a pass, it displays success. For visual clarity, the raw DKIM cryptographic string is truncated to the first 100 characters in the security summary. If the result doesn't explicitly state a pass, the tool labels it as unknown.
• DMARC: The parser searches specifically within the authentication-results header for the string dmarc. If found, it strictly looks for the exact phrase dmarc=pass. If this exact match isn't present, the DMARC status is flagged as fail.

Routing and Hop Trace (The Received Chain)

To trace the exact path an email took across the internet, the decoder analyzes the Received headers. The tool scans the document bottom-up (as MTAs prepend headers) and aggregates all received: lines, including any folded continuation lines.

For each hop, it applies specific Regular Expressions:

• Sender Server: Extracted using from\s+([^\s]+) to isolate the sending MTA.
• Receiving Server: Extracted using by\s+([^\s]+) to identify the receiving MTA.
• Timestamp: Extracted by matching the end of the line following a semicolon ;\s+(.+)$.

Worked Example: Parsing a Raw Header

Consider the following snippet of raw email header input:

Message-ID: <[email protected]>
Subject: Server Alert
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of [email protected] designates 192.168.1.1 as permitted sender)
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com
Received: from mail.example.com (mail.example.com. [192.168.1.1])
        by mx.google.com with ESMTPS id abcdef12345
        for <[email protected]>; Wed, 20 Aug 2026 12:00:00 -0700 (PDT)

When evaluated by the decoder:

1. Header Folding: The Authentication-Results and Received lines begin with spaces on subsequent lines, so the tool collapses them into single strings in memory.
2. Security Checks: The Authentication-Results field contains both spf=pass and dmarc=pass. The tool's case-insensitive check matches "pass" and "dmarc=pass", assigning a "pass" badge to both SPF and DMARC.
3. Hop Extraction: Using regex on the Received block, the tool identifies mail.example.com as the "From Server", mx.google.com as the "By Server", and Wed, 20 Aug 2026 12:00:00 -0700 (PDT) as the time of the hop.

Frequently Asked Questions

How does the decoder handle multi-line header fields?

The parser follows RFC conventions for header folding. If it encounters a newline followed immediately by a whitespace character (a space or a tab), it recognizes that the line is a continuation of the previous header key and joins them together before extracting the data.

Why does the DKIM status show as "unknown"?

The tool assigns an "unknown" status to DKIM if it locates a dkim-signature or authentication-results header, but cannot find the explicit word pass (case-insensitive) within the value. This often happens if the signature failed verification or if the receiving server formatted the result string non-standardly.

How are the routing "hops" identified?

Hops are generated exclusively from Received: headers. The tool captures the entire Received block (including folded lines) and runs three specific regex patterns to pull the first contiguous non-whitespace string after the word "from", the string after the word "by", and the date timestamp following the final semicolon in the block.

Why is my DMARC result showing as "fail" when SPF passed?

The DMARC check is deliberately strict. The tool searches the authentication-results header specifically for the exact substring dmarc=pass. Even if SPF and DKIM pass individually, if the receiving server didn't explicitly output dmarc=pass in the results header, the tool will mark DMARC as failed.