Email Header Forensics & Authentication Inspector

An email header is a structured block of metadata preceding the email body that records the sender, recipient, subject, date, intermediate routing servers (Received headers), and cryptographic authentication assessments (SPF, DKIM, DMARC).

A Received header is a trace field added by each Mail Transfer Agent (MTA) that handles a message in transit. The newest receiving server prepends its header to the very top, while the bottom-most Received header reflects the originating server.

Open the email in Gmail on a desktop browser, click the three vertical dots (More) next to the Reply button, and select 'Show original'. The full raw header will appear in a new tab.

In desktop Outlook, open the email in its own window, click File > Properties, and view the 'Internet headers' box at the bottom. In Outlook on the web, click the '...' menu in the message header, select View > View message details.

Return-Path represents the envelope sender (MAIL FROM) address where delivery failure and bounce notifications are dispatched. It frequently differs from the From address when using third-party email service providers (ESPs).

Reply-To specifies where email client software should address responses when the recipient clicks 'Reply'. If Reply-To differs from the From domain, replies are directed to an alternate destination, common in support ticketing and transactional notifications.

Message-ID is a globally unique identifier assigned to a specific message by the originating mail system, formatted as '<unique-string@origin-host>'.

SPF (RFC 7208) allows a domain owner to publish authorized sending IP addresses in their DNS records. Receiving mail servers check SPF to verify if the connecting sending IP was authorized by the envelope sender domain.

DKIM (RFC 6376) attaches a cryptographic signature to the email header. The receiving server uses the public key published in the sender's DNS record to verify message authenticity and ensure headers/body were not tampered with in transit.

DMARC verifies that the author's visible From domain is aligned with SPF or DKIM identities and publishes disposition policy (none, quarantine, reject). In 2026, DMARC is governed by RFC 9989 (core spec), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting), superseding the obsolete RFC 7489.

ARC (RFC 8617) preserves authentication assessments across intermediate handlers (like mailing lists or forwarding services) that alter message content and would otherwise break SPF or DKIM validation.

Authentication-Results (RFC 8601) is a structured header added by receiving boundary MTAs or security gateways recording their local evaluations of SPF, DKIM, DMARC, and ARC.

SPF PASS indicates that the IP address of the connecting server was explicitly permitted by the envelope sender domain's SPF DNS record.

DKIM PASS indicates that the cryptographic signature in the DKIM-Signature header was successfully verified using the signer's public key without detecting body or header tampering.

DMARC PASS indicates that the domain shown in the Header From address is aligned with either a passing SPF identity or a passing DKIM signature domain.

Domain alignment is the DMARC requirement that the domain displayed to the end-user in the From header must match (either strictly or as a subdomain) the domain authenticated by SPF or DKIM.

Received headers are read chronologically from bottom to top. The bottom header is the originating hop where the sender submitted the email, and each higher header represents an onward transmission until the message reaches your provider.

Emails travel through multiple intermediate servers (client workstation, internal relay, cloud spam scanner, corporate gateway, destination mailbox server). Each server records the IP of the machine that handed off the message.

No. Header forensics provides objective evidence about routing, authentication reports, and domain alignment. It cannot verify the ultimate intent or psychological deception of text in the email body, which requires holistic human evaluation.

No. Solasu executes 100% client-side in your browser's JavaScript environment. No header text, email addresses, or IPs are uploaded to any server or persisted in cookies or storage.

No. To preserve privacy and guarantee zero outbound network leaks, this tool inspects only the reported data already present in the supplied email headers without performing live external DNS queries.

Privacy redaction irreversibly masks sensitive PII such as email addresses, IP addresses, and unique Message-IDs (e.g. converting 'john@example.com' to 'j***n@example.com') so headers can be safely attached to public tickets or incident reports.