MyIP.dogChecking…
Email header analyzer
Read mail routes, timestamps and authentication claims with private, local analysis.
Checking…
Read mail routes, timestamps and authentication claims with private, local analysis.
Checking…
Checking…
Analyze headers locally in this tab. Pasted content is not sent to a lookup service.
Ready for local analysis.
An email header analyzer helps you inspect the routing and identity claims attached to a message. The useful question is usually specific: which relay recorded a transfer, where do the reported clocks disagree, or which domain appears in an authentication assertion? Begin with that question instead of treating every unfamiliar field as evidence of abuse.
This email header analyzer runs in your browser. It organizes pasted fields, extracts supported IP literals, interprets supported dates and exposes the original evidence. It does not contact the sender, open message links, query DNS or verify signatures. The email header analyzer therefore reports observations about text you supplied, with clear limits on what those observations establish.
Open the original message in your mail application and locate its full headers or message source. Copy the header section into the email header analyzer, preserving line breaks and indentation. Select Analyze headers to see the result. Forwarding the message as ordinary text may give you the forwarding message's headers instead of the original delivery record.
For Gmail on a computer, open the message, choose the message's More menu and select Show original. Google's full-header instructions describe the current flow. Outlook offers message-details or Internet-headers views depending on the version; follow Microsoft's Outlook header instructions. The email header analyzer needs the source text, not a screenshot of the sender's display name.
Try Load example before using a personal message. The email header analyzer example is fictional and uses reserved domains and documentation addresses. Its two relay records are eight seconds apart after timezone conversion. A reported pass in that sample is illustrative text, so it does not demonstrate a successful authentication check.
The email header analyzer accepts at most 65,536 characters, 2,048 lines, 512 fields and 100 Received records. Larger input produces an error rather than a silently shortened result. A blank line separates headers from body content; anything after the first empty line is excluded from analysis and the copied report. Remove the message body before pasting whenever possible.
The result begins with field, transfer-record and address counts. These are inventory counts, not quality or safety scores. The email header analyzer also shows parser notes and a message-field summary. A duplicate Subject or From field remains visible rather than being silently replaced by one preferred value. Expand All original fields when you need to compare the summary against the source.
Receiving SMTP servers normally prepend their Received records. Reading the stack from the bottom upward therefore follows the listed transfer sequence. The SMTP trace specification describes these records. The email header analyzer reverses their position in the header section; it does not reorder records according to their timestamps.
Each email header analyzer transfer card links its interpretation to a numbered source field. Common from, by and with clauses identify the reported sending host, receiving host and transfer protocol. They are extracted as readable hints. Parenthesized comments and quoted strings can contain confusing words or semicolons, so the parser considers those boundaries before interpreting a clause.
An email header analyzer cannot establish who inserted a pasted record. The most recently listed receiving system may be familiar, but its name alone does not prove authenticity. Compare the original message with records held by your own mail provider when the trust boundary matters. Earlier records can contain claims introduced outside that provider's control.
The email header analyzer displays the supplied timestamp alongside an interpreted UTC value when supported. Numeric offsets are applied explicitly. For example, 11:00:00 +0100 and 10:00:00 +0000 represent the same instant. This avoids mistaking a timezone change for an hour spent in a queue.
The difference shown by the email header analyzer compares adjacent interpreted records. It is not a measured round-trip time or a precise breakdown of processing and transport. A negative value is retained and flagged. It can reflect clock disagreement, altered fields or an unusual record sequence; changing it to zero would conceal evidence.
Missing dates, impossible calendar dates, mismatched weekdays and ambiguous timezone names do not receive guessed timestamps. This email header analyzer retains leap-second notation without calculating a difference from it. It supports four-digit years, numeric offsets and a defined set of legacy RFC timezone names. A -0000 offset represents UTC while withholding the original local timezone. The message date grammar supplies the reference conventions.
The email header analyzer separates Authentication-Results and ARC-Authentication-Results from other fields. It displays the claimed authentication service and result clauses such as spf=pass, dkim=fail or dmarc=none. Every result is explicitly unverified. A pasted success word is not converted into a green message-safety verdict.
Authentication-Results is designed to carry results produced by a receiving system within a known trust arrangement. The Authentication-Results specification explains why receivers must handle untrusted copies carefully. This email header analyzer has only the text you provide, so it cannot decide whether that system actually generated a particular field.
SPF concerns authorization of the connecting mail server for an SMTP identity, including the envelope MAIL FROM or HELO identity. It does not, by itself, authenticate the name displayed in your inbox. The email header analyzer preserves relevant assertion details so you can see which identity was reported. The SPF specification describes the underlying check; this tool does not repeat it using today's DNS.
DKIM verification involves a signature, selected headers, message-body processing and a signing-domain key. Merely finding a DKIM-Signature field does not verify any of those inputs. The email header analyzer retains that field in the complete field list, while reported DKIM outcomes remain claims. Consult the DKIM specification when investigating a signature with appropriate mail-server evidence.
DMARC relates authentication to the author domain and domain alignment. Its result is not a general endorsement of the message's content or requests. The email header analyzer presents the pasted DMARC assertion without recalculating alignment or policy. The current DMARC specification provides the protocol context. ARC-related text is also retained without claiming that an ARC chain was validated.
The email header analyzer extracts supported IPv4 and IPv6 literals from Received, Received-SPF and X-Originating-IP fields. Each normalized address has references to the source fields and supplied notation. Repeated mentions of the same address are grouped. Addresses appearing only in a Subject or unrelated custom field are not treated as routing evidence.
A private address can describe an internal transfer. A public address can belong to a relay, gateway or hosting provider. Documentation addresses identify examples. None of these categories proves who wrote the message. The email header analyzer performs no geolocation lookup and makes no claim to locate a person or their device.
IPv4-mapped IPv6 literals are normalized to their embedded IPv4 address for classification, while the supplied literal remains visible. Other supported IPv6 literals retain their address family. The email header analyzer rejects ambiguous legacy IPv4 notation and zone identifiers instead of guessing their meaning. You can separately use IP lookup for registered-network context after deciding that sending an address to an external data source is appropriate.
The email header analyzer shows From, Sender, To, Cc, Reply-To, Return-Path, Subject, Date and Message-ID fields when present. Those fields serve different purposes. A different reply address deserves context, but a difference alone does not establish fraud. Mailing lists, support systems and delivery services can produce legitimate variation.
An email header analyzer should also preserve what it cannot interpret. This tool decodes supported MIME B and Q encoded words in Subject fields for a readable preview. The original encoding remains in the expandable field list. Unsupported character sets, malformed encodings and decoded control characters retain their original encoded representation with a parser note. The encoded-word specification explains the format.
The email header analyzer does not perform full mailbox-address parsing, translate display names or render HTML. Suspicious-looking markup is shown as text. Directional control characters are displayed as visible escape sequences in results to help reveal text that could otherwise change visual reading order. Keep the original message when reporting an issue to your provider.
Pasted headers can contain recipient lists, internal hostnames, unique message identifiers and addresses. The email header analyzer stores its working input and result in the current component's memory. It does not put those values into the page URL, browser storage, an application API request or a tool analytics event. Normal site assets and site analytics still make their ordinary network requests.
Choose Clear to empty the input and result. Editing invalidates the previous analysis, and leaving the page discards the working state. The email header analyzer also clears its form when the page is hidden for navigation, including the browser's page-cache lifecycle. These actions are application cleanup, not a promise of forensic erasure from browser memory, extensions or the operating system.
Copy report exports a JSON report containing the parsed evidence and original header fields, excluding body content after the separator. The email header analyzer does not redact that report automatically. Review names, addresses and identifiers before sharing it. Copying is an explicit action, and clearing the tool does not erase a report already placed on your system clipboard.
This email header analyzer is an evidence reader, not a complete email standards validator or a phishing verdict service. It cannot inspect a mail provider's private logs, reconstruct missing transfers, establish the original SMTP connection or verify cryptographic signatures from a header-only paste. Hostnames and IP addresses remain unqueried until you independently choose another tool.
An email header analyzer can identify address literals in supported routing fields. It cannot prove that one belongs to the human sender. Webmail may expose provider infrastructure, relays may hide earlier hops, and untrusted fields may be fabricated. Use the source-field references to understand where an address appeared, then ask the relevant provider for evidence if identity is important.
Your copied text may be incomplete, may begin with an empty line, or may contain only a message summary. The email header analyzer does not invent missing records. Return to the original-message view and copy the actual headers. If the records truly are absent, that absence is the result; it does not establish a direct delivery path.
The email header analyzer did not run the asserted check. Even a correctly formatted Authentication-Results field needs a trusted origin before its claims can be relied upon. Keep the authentication-service identifier and original message with any support request. Do not interpret a displayed success as proof that attachments, links or payment instructions are safe.
Paste its header section into the email header analyzer, within the stated limits. A full message body is ignored after the first blank line, but nested messages and attachments are not recursively inspected. A forwarded conversation's outer headers describe that forwarding event. Obtain the original message as a separate source when you need its own delivery history.
Use the email header analyzer to prepare a focused question: identify the numbered field, preserve its original value, and state what conflicts with your expectation. If you administer the receiving domain, compare the message with delivery logs and authentication results from your own systems. If you are a recipient, contact your mail provider through its usual support channel rather than replying to an untrusted address in the message.
The email header analyzer was developed against the linked standards and synthetic examples covering folding, duplicate fields, comments, date boundaries, encoded subjects and deceptive authentication text. Those checks validate parsing behavior; they do not certify arbitrary email as authentic. Source review date: September 28, 2026.