Email Header Analyzer

The tool fetches the sender domain's live SPF record and renders each mechanism as a color-coded token. The exact mechanism that matched the sending IP address — whether a direct ip4:, an a: record, or a nested include: — is highlighted in the record so you can see at a glance why SPF passed or which rule caused it to fail.

When the matching mechanism is an include: directive the tool follows the chain recursively, resolving each referenced domain's SPF record in turn until it reaches the leaf mechanism that matched. The full include path is displayed (e.g. include:spf.protection.outlook.com → ip4:40.92.0.0/15), so you can confirm exactly which IP range authorized the sender.

When DMARC fails, the tool shows an alignment table: the From: header domain is compared against the DKIM signing domain (d=) and the SPF envelope-from domain. Each pair is labelled aligned or not aligned, so you can see immediately whether the failure is a DKIM alignment issue, an SPF alignment issue, or both. Remediation hints (e.g. configure a custom Return-Path CNAME) are shown inline.

For each DKIM-Signature: header the tool resolves selector._domainkey.domain in real time to check whether the public key still exists in DNS, has been revoked (empty p=), or was never published. If the current DNS state differs from the delivery-time result the tool flags the discrepancy — useful for diagnosing whether DKIM failed because of a signing error or a key rotation that happened after delivery.

ARC (Authenticated Received Chain) allows intermediate mail handlers — mailing lists, forwarding services — to preserve the original authentication results after they modify a message. The tool displays the full ARC chain as a visual sequence of nodes (i=1, i=2, …), each showing the chain-validation value (cv=none/pass/fail) and the independent SPF/DKIM/DMARC results recorded at that hop — separate from the final delivery authentication.

Microsoft 365 adds several proprietary headers that most analyzers ignore. This tool decodes X-Forefront-Antispam-Report, X-Microsoft-Antispam, and X-MS-Exchange-Organization-* to show: whether Exchange classified the message as internal or external (AuthAs), the Spam Confidence Level (SCL) and Bulk Complaint Level (BCL) with their meanings, the spam filter verdict (SFV), and the message category (CAT). It also detects hybrid on-premises scenarios from the FromEntityHeader value.

The delivery path is rendered as an interactive diagram showing each hop: the sending and receiving hostnames, IP addresses, timestamps, and delay between hops. IP addresses are classified as internal (RFC 1918 / link-local), Microsoft 365 infrastructure, or external. DNS resolution fills in missing IP addresses for hostnames that appear without one.

When a message arrives from an on-premises Exchange server through a Microsoft 365 hybrid connector, Exchange Online can misclassify it as anonymous (external) even though it originates internally. The tool detects this pattern — AuthAs=Anonymous combined with FromEntityHeader=HybridOnPrem — and shows a warning with the likely causes and the impact on mail flow policies.

Every Received: header names the protocol and often the TLS version and cipher of that transfer (Postfix, Exim, sendmail, Google and Microsoft formats, plus the RFC 3848 keywords ESMTPS and ESMTPSA). The tool shows a padlock per hop in the flow diagram and the routing timeline, sums up the encryption in one line and warns about unencrypted transfers between organizations and about TLS 1.0/1.1, which RFC 8996 deprecates. Hops that hand the message back to a server already shown (a gateway re-injecting via localhost) appear as a badge on that server.

Mailbox forwarding and inbox rules in Microsoft 365, Gmail forwarding filters, Resent-* headers, Delivered-To chains and SRS-rewritten Return-Paths (standard SRS0= and the Microsoft 365 +SRS= format) are recognized and the original sender is decoded. The validation explains why SPF fails on forwarded mail while DKIM and ARC still carry the original authentication, and it stops treating the From/Return-Path mismatch as a warning when SRS explains it.

X-Microsoft-Antispam-Mailbox-Delivery is stamped when Exchange Online files the message into a mailbox. The Exchange section shows the destination folder code (Inbox, Junk or a custom folder, meaning derived from observation), the override reason and the Network Message ID that Microsoft Defender for Office 365 uses in Explorer and Advanced Hunting.

The card at the top condenses authentication, transport and the validation findings into one state and offers a plain-text summary for tickets and chats. Findings come in three severities: failures, warnings and informational notes. Checks include lookalike and homograph domains (including Punycode), freemail Reply-To addresses on corporate senders, Date headers that deviate from the first Received timestamp, headers that belong to an inline-forwarded copy rather than the original message, and SPF failures on an intermediate hop that are healed again by the time the message is delivered (relaying and forwarding). That note keeps the overall verdict from reading “No findings” while the report further down shows a failed SPF hop.

Beyond matching the sending IP, the SPF record is audited: DNS lookups across all includes and redirects against the limit of 10 (RFC 7208 §4.6.4), includes without a record (void lookups), +all and ?all, the discouraged ptr mechanism, multiple records and the record length. The summary line sits under the record header, details open with the record.

For list and newsletter mail the tool checks the requirements that Google and Yahoo publish for bulk senders: SPF and DKIM, a published DMARC record and an aligned From domain, one-click unsubscribe per RFC 8058, reverse DNS that resolves back to the sending IP, TLS on delivery and a Message-ID.

Mail security products leave their verdicts in the headers. The tool reads SpamAssassin (X-Spam-Status, X-Spam-Report with per-rule scores), Rspamd (X-Spamd-Result symbols and the action), Proofpoint spam details and anti-virus, Mimecast spam score and impersonation protection checks, Barracuda status and report, and the Cisco Secure Email (IronPort) anti-virus and ThreatScanner verdict. Vendors without a documented format, such as Hornetsecurity, NoSpamProxy, Retarus, Trend Micro, Sophos, Kaspersky, ESET and Amavis, are listed with their raw headers.

Load a second message next to the first one and the tool shows the facts side by side: authentication results, hops and transit time, TLS, Exchange verdicts (SCL, CAT, SFV), delivery folder, forwarding and gateway verdicts, with differences highlighted and the findings that exist in only one message. Typical use: a delivered versus a quarantined copy, or a message before and after a connector or rule change. Either message can be shown in full detail below.

"Share link" in the summary heading builds a URL that carries the message text itself, compressed, in the fragment after the # sign (#share=z.<base64url of deflate-compressed UTF-8>). Browsers never send the fragment to the server and the tool stores nothing, so the privacy promise holds: whoever has the link can open the analysis, nobody else. By default only the headers are included, which keeps the link short enough for chats and tickets; the body can be added when needed. Other tools can build such links themselves, for example a shortcut that shares the clipboard.