# Email Header Analyzer > Parse raw email headers locally into receiver authentication verdicts, a chronological delivery route, identity roles, DKIM and ARC evidence, unsubscribe-policy checks, and an exportable incident report. - **Category:** Deliverability - **Updated:** July 2026 - **Canonical page:** [https://emailbump.com/tools/email-header-analyzer](https://emailbump.com/tools/email-header-analyzer) - **Interactive tool:** [Open the email header analyzer](https://emailbump.com/tools/email-header-analyzer) ## What the tool does Paste raw message headers or a complete message. The analyzer reads the header section before the first empty line and ignores the body. It then: - Normalizes CRLF and other pasted line endings - Unfolds continued header fields - Preserves repeated fields and their original order - Flags malformed lines - Checks physical line lengths - Parses Authentication-Results method clauses and properties - Reverses Received trace fields into chronological order - Extracts hop hosts, protocols, identifiers, recipients, IP addresses, and timestamps - Calculates observable per-hop and total transport durations - Parses DKIM-Signature tag lists - Maps visible From, Sender, Reply-To, Return-Path, and To identities - Inventories ARC sets and chain-validation declarations - Reviews List-Unsubscribe and List-Unsubscribe-Post - Produces priority findings - Makes every unfolded field searchable - Copies a text incident report - Exports structured JSON evidence Analysis is performed in the browser. Raw headers are not submitted to Email Bump or another service. ## Treat raw headers as sensitive Headers can contain: - Sender and recipient addresses - Internal hostnames - Private and public IP addresses - Message identifiers - Queue and provider identifiers - Campaign, tenant, account, or workspace IDs - Mailing-list identifiers - Unsubscribe URLs containing recipient-specific tokens - Anti-abuse and filtering metadata - Internal routing and infrastructure details Do not paste customer headers into public chats, issue trackers, or external tools without considering authorization and redaction. A redacted header may also lose the exact evidence needed to diagnose routing or alignment. The analyzer intentionally stays local. Exported JSON remains sensitive and should be handled like the original header source. ## Obtain the original source Mailbox interfaces often show a friendly authentication summary rather than the complete message source. For forensic work, use the client action named “Show original,” “View source,” “View raw message,” or an equivalent provider export. Copy the complete header section. A reliable source preserves: - Repeated Received fields - Authentication-Results - DKIM-Signature - ARC fields - Return-Path - Message-ID - Original folding and field order Screenshots and UI summaries omit syntax, order, signing coverage, and trace evidence. ## RFC 5322 field parsing An Internet message consists of a header section followed by an optional body. The body begins after the first empty line. A field has a name, colon, and field body: ```text Subject: Your July sending report ``` Long field bodies can be folded across physical lines. A continuation begins with whitespace: ```text DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026; h=from:date:subject:message-id; bh=...; b=... ``` RFC 5322 defines unfolding as removing the CRLF immediately followed by whitespace before semantic evaluation. The analyzer performs this operation and retains the original folded representation in memory. RFC 5322 limits each physical line to 998 characters excluding CRLF and recommends no more than 78 characters. An unfolded field can be much longer. The analyzer therefore checks the pasted physical lines before unfolding. ## Authentication-Results trust boundary Authentication-Results, standardized by RFC 8601, records authentication work performed by a receiving system. A simplified field looks like: ```text Authentication-Results: mx.example.net; dkim=pass header.d=example.com header.s=mail2026; spf=pass smtp.mailfrom=bounce.example.com; dmarc=pass header.from=example.com ``` The first identifier is the `authserv-id`: the authentication service reporting the result. The critical rule is trust, not parsing. A malicious sender can add a convincing Authentication-Results field before sending the message. Receiving systems are expected to remove or distinguish untrusted instances at their boundary according to local policy. Trust an authentication result only when: - It was added by the receiving infrastructure you control or trust - Its authserv-id belongs to that infrastructure - Upstream untrusted instances were handled correctly - You understand where in the route the evaluation occurred The analyzer cannot discover your trust boundary. It displays each authserv-id and repeats this limitation rather than presenting every parsed pass as authoritative. ## Reading method results ### SPF SPF normally authenticates an SMTP identity such as the MAIL FROM domain, shown as `smtp.mailfrom`. It does not directly authenticate the visible From field. Common results include: - `pass`: the evaluated policy authorized the client - `fail`: policy explicitly did not authorize it - `softfail`: the policy marked it as probably unauthorized - `neutral`: the policy made no assertion - `none`: no applicable policy was found - `temperror`: a transient evaluation problem - `permerror`: an invalid policy or permanent evaluation problem The exact disposition remains receiver policy. ### DKIM A DKIM pass means the verifier found a suitable key and cryptographically validated the signature and body hash. The authenticated signing domain is commonly reported as `header.d`; the selector may appear as `header.s`. A DKIM-Signature field without an Authentication-Results DKIM pass is only evidence that a signature was attached. It is not evidence that verification succeeded. ### DMARC DMARC evaluates the visible From domain against authenticated SPF and DKIM identities under its alignment and policy rules. The evaluated visible domain commonly appears as `header.from`. A DMARC pass means at least one supported mechanism passed with alignment. It does not require both SPF and DKIM to pass. A message can have SPF fail and DKIM-aligned pass, or the reverse, and still pass DMARC. A DMARC fail should be interpreted with: - The receiver's authserv-id - The evaluated From domain - Reported disposition or policy properties - Aligned versus merely passing identifiers - Forwarding or intermediary modifications - ARC evidence when applicable ## Received trace fields Each receiving SMTP system prepends a Received field. The topmost Received field is normally the newest; the bottommost is the oldest. The analyzer reverses them for a journey view: 1. Oldest observed source handoff 2. Intermediate relays 3. Receiving boundary 4. Local delivery It attempts to extract: - `from` host - `by` host - `with` protocol - Queue or message `id` - Envelope `for` recipient - Bracketed or plain IP addresses - Date-time after the final semicolon Header syntax varies extensively between products. Values the analyzer cannot identify remain available in the full field ledger. ## Timing and delay For chronological trace fields with parseable dates, the analyzer subtracts the previous hop timestamp from the next. A large positive gap can indicate: - Queueing - Connection retry - Greylisting - Provider throttling - Temporary DNS or network failure - Deferred content or policy scanning A negative gap can indicate: - Clock skew - Incorrect timezone syntax - A malformed date - Header reordering - A forged or otherwise untrustworthy upstream trace field Received timestamps are diagnostic evidence, not synchronized telemetry. A sending host controls the trace it adds, and untrusted upstream fields can be forged. The total observed transit time covers only the earliest and latest parseable Received timestamps. It is not necessarily the time from a user pressing Send to inbox rendering. ## Identity map One email carries several identity roles. ### From The RFC 5322 From field is the visible author identity and the reference domain for DMARC. ### Sender Sender can identify the agent responsible for transmission when different from the author represented by From. ### Reply-To Reply-To directs human responses somewhere other than the From mailbox. A different domain can be legitimate for support or routing, but it changes recipient behavior and can be abused in impersonation. ### Return-Path Return-Path exposes the final envelope reverse path after delivery. It is used for bounce handling and commonly reflects the MAIL FROM identity evaluated by SPF. Providers often use a dedicated bounce subdomain or their own infrastructure domain. Simple string equality with From is not the DMARC rule; organizational-domain alignment and the actual authentication result matter. ### DKIM d= The `d=` value in DKIM-Signature is the signing domain. It claims responsibility for the signature and may or may not align with From for DMARC. The analyzer reports differing roles as context rather than automatically calling them attacks. ## DKIM-Signature analysis For each signature, the tool parses: - `d=`: signing domain - `s=`: selector - `a=`: signature algorithm - `c=`: header/body canonicalization - `i=`: Agent or User Identifier - `t=`: signing timestamp - `x=`: expiration - `l=`: signed body length - `h=`: signed header list The current DKIM cryptographic update prohibits RSA-SHA1. The analyzer flags `a=rsa-sha1`. The From field must be signed. A parsed `h=` list that omits From is reported as blocking. ### Body-length tag `l=` limits the number of canonicalized body bytes included in the body hash. Content after that point is not protected by the signature. RFC 6376 describes security concerns with this behavior. The analyzer warns whenever the tag appears. ### Duplicate signed fields The order and repetition of names in `h=` can matter. A robust forensic review should compare the actual message fields with the complete signing list. The tool inventories the list but does not reproduce DKIM header selection or cryptographic verification. ### Expiration When both `t=` and `x=` parse as integers, expiration earlier than signing time is structurally invalid. A signature that is expired today may have been valid when the historical message was delivered, so the analyzer does not automatically call current wall-clock expiration a delivery failure. Use the linked DKIM record checker to inspect the public key for a parsed d=/s= pair. The header analyzer does not query DNS. ## ARC inventory Authenticated Received Chain is standardized by RFC 8617. Each ARC set can contain: - ARC-Authentication-Results: authentication evidence observed by the intermediary - ARC-Message-Signature: a signature over the message - ARC-Seal: a seal over the ARC set and prior chain Sets are numbered with `i=`. The ARC-Seal includes `cv=`, which describes the sealer's evaluation of the prior chain: - `none` for the first set - `pass` when the prior chain validated - `fail` when it did not The analyzer counts sets, seals, signatures, and result fields, finds the highest instance, and displays the latest declared cv value. It does not cryptographically validate ARC. A matching count does not prove a valid chain, and a displayed cv=pass is a declaration inside a field until the seal is verified. ARC does not change a DMARC fail into a protocol pass. A final receiver can use validated ARC evidence in local handling policy, particularly when an intermediary modified a message. ## One-click unsubscribe review RFC 8058 defines an HTTPS POST mechanism for one-click unsubscribe. A message uses: ```text List-Unsubscribe: List-Unsubscribe-Post: List-Unsubscribe=One-Click ``` The analyzer checks: - Whether List-Unsubscribe exists - Which angle-bracketed URIs appear - Whether an HTTPS URI is present - Whether a mailto URI is present - Whether List-Unsubscribe-Post declares one-click - Whether at least one parsed DKIM signature lists both unsubscribe fields in `h=` RFC 8058 requires the one-click fields to be covered by a valid DKIM signature. Merely listing them in `h=` does not prove that the signature passed. The tool does not call the endpoint. It cannot verify: - POST behavior - Whether GET has side effects - Token validity - Authentication or expiry behavior - Response time - Suppression processing - Applicability of provider or legal requirements to the message An absent unsubscribe field is not automatically an error because transactional and person-to-person messages have different requirements from subscribed bulk mail. ## Required and useful message fields The analyzer flags missing or duplicate From and Date fields. It warns when Message-ID is absent and when duplicated Subject or Message-ID fields could create inconsistent downstream interpretation. Message-ID supports: - Threading - Deduplication - Provider-log lookup - Event correlation - Support investigation It is not a secret or proof of authenticity. Avoid encoding personal or sensitive data into generated identifiers. MIME-Version and Content-Type are displayed in the message summary. The analyzer does not parse MIME body parts. ## Recommended forensic workflow 1. Export the original source from the recipient mailbox. 2. Preserve an unmodified copy with access controls. 3. Identify the mailbox provider and receiving boundary. 4. Find Authentication-Results added by that trusted receiver. 5. Read DMARC, DKIM, and SPF method results and their evaluated identities. 6. Compare visible From, Return-Path, DKIM d=, and any Reply-To. 7. Reverse Received fields and locate delay or routing anomalies. 8. Inspect each DKIM signature's d=, s=, a=, h=, and l=. 9. Use the DKIM record checker on the exact selector when DNS evidence is needed. 10. Review ARC only when an intermediary or forwarding path is relevant. 11. Review one-click fields for subscribed bulk mail. 12. Correlate Message-ID and provider queue IDs with sender logs. 13. Export the analyzer JSON for the incident record. 14. Redact only the copy intended for a less-trusted audience. ## Common diagnostic patterns ### SPF pass, DKIM pass, DMARC fail The authenticated domains may not align with the visible From domain. Read smtp.mailfrom, header.d, and header.from rather than only the pass labels. ### SPF fail, DKIM pass, DMARC pass Aligned DKIM can independently satisfy DMARC. This pattern can be healthy when SPF is affected by forwarding or the MAIL FROM identity does not align. ### DKIM fail after forwarding An intermediary may have modified signed content or headers. Inspect body-hash results, mailing-list footers, subject changes, MIME rewriting, and ARC evidence. ### Authentication passes but inbox placement is poor Authentication is necessary infrastructure, not a reputation guarantee. Review complaints, engagement, sending history, content, list quality, domain and IP reputation, and mailbox-provider evidence. ### Long transport delay Locate the first large gap in the chronological timeline, then use adjacent hostnames and queue IDs to determine which operator held the message. ## Limitations The analyzer does not: - Verify DKIM cryptography - Query DNS - Calculate SPF from an IP and domain - Evaluate DMARC organizational-domain alignment with a public-suffix database - Validate ARC seals or signatures - Decide which Authentication-Results field belongs to your trust boundary - Prove Received fields are authentic - Decode MIME bodies or attachments - Decode every RFC 2047 display-name or subject encoding - Execute unsubscribe requests - Identify malware, phishing, or spoofing conclusively - Determine inbox-placement causes from one message - Replace provider logs or receiver-side telemetry Its date parser uses browser date support after removing a trailing parenthetical timezone comment. Obsolete or unusual date syntax may not parse consistently. Address extraction is intentionally conservative and may not fully interpret groups, comments, internationalized addresses, or obsolete syntax. The original unfolded value remains visible. ## Frequently asked questions ### Can I paste a complete message? Yes. Content after the first empty line is ignored. For sensitive messages, confirm that your copy actually contains an empty header/body boundary before pasting. ### Why are Authentication-Results fields different? Different systems can evaluate the message at different points. Forwarding, rewriting, DNS changes, local policy, or forged upstream fields can produce different evidence. Start from the trusted final receiver. ### Is the top Received field the sender? No. The top field is normally the newest trace added closest to final delivery. Read Received fields bottom to top for chronological order. ### Can the timeline locate a delay? It can locate a gap between parseable timestamps. Confirm with queue logs because clocks and upstream trace fields are not guaranteed trustworthy. ### Does a DKIM-Signature prove DKIM passed? No. It describes signing intent. Authentication-Results from a trusted verifier reports the outcome. ### Does ARC override DMARC? No. A receiver can consider a cryptographically valid ARC chain in local policy, but ARC does not redefine the DMARC authentication result. ### Why is Return-Path different from From? Sending providers commonly use a dedicated bounce domain. Read SPF and DMARC alignment evidence before deciding whether the difference is healthy. ## Primary sources - [RFC 5322: Internet Message Format](https://www.rfc-editor.org/rfc/rfc5322.html) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [RFC 8617: The Authenticated Received Chain Protocol](https://www.rfc-editor.org/rfc/rfc8617.html) - [RFC 8058: Signaling One-Click Functionality for List Email Headers](https://www.rfc-editor.org/rfc/rfc8058.html) - [RFC 6376: DomainKeys Identified Mail Signatures](https://www.rfc-editor.org/rfc/rfc6376.html) - [RFC 8301: DKIM Cryptographic Algorithm and Key Usage Update](https://www.rfc-editor.org/rfc/rfc8301.html) ## Related guidance - [DKIM record checker](https://emailbump.com/tools/dkim-record-checker.md) - [SPF lookup budget checker](https://emailbump.com/tools/spf-record-checker.md) - [DMARC record builder](https://emailbump.com/tools/dmarc-record-builder.md) - [SMTP bounce code decoder](https://emailbump.com/tools/bounce-code-decoder.md) - [Email authentication definition](https://emailbump.com/glossary/email-authentication.md) - [DKIM definition](https://emailbump.com/glossary/dkim.md) - [SPF definition](https://emailbump.com/glossary/spf.md) - [DMARC definition](https://emailbump.com/glossary/dmarc.md) - [One-click unsubscribe definition](https://emailbump.com/glossary/one-click-unsubscribe.md) - [Gmail via-label and DKIM alignment guide](https://emailbump.com/blog/gmail-via-label-dkim-alignment.md)