Email Header Analyzer
Free email header analyzer that runs in your browser. See every hop in UTC, SPF, DKIM and DMARC results, From alignment, ARC and Microsoft spam fields.
Updated
The whole header or the full message source. Reading stops at the first empty line; up to 256 KB.
Read on this device. Reset clears it.
Paste a message header, or pick an .eml file, to see its hops and authentication results.
What Is an Email Header Analyzer?
The email header analyzer reads the header of an email message and lays it out for review: the decoded subject and addresses, each server the message passed through with its time converted to UTC and the delay between hops, the SPF, DKIM and DMARC results the receiving system recorded, whether the authenticated domains align with the From domain, the structure of the ARC chain, DKIM signature details, and Microsoft 365 anti-spam fields. The header is parsed in your browser and never uploaded.
How to Use the Email Header Analyzer
- Open the message in your mail client and copy its full header: in Gmail, More and then Show original; in classic Outlook, File and then Properties.
- Paste the header into the box, or pick a saved .eml file.
- Read the authentication summary, then the hops, the Authentication-Results added by your own mail system, and the alignment table.
- Copy the analysis as text, or the hops as CSV, for a ticket or report.
How It Works
A message header ends at the first empty line. A line that starts with a space or tab continues the field above it, and the analyzer joins such lines by removing the line breaks, as RFC 5322 describes. Encoded words such as =?UTF-8?B?...?= in the subject and display names are decoded as RFC 2047 defines, and white space between two encoded words is not shown.
Every mail server adds its Received field at the top of the header and must not reorder the ones below, so the bottom field is the oldest hop. The time after the last semicolon of each field is converted to UTC with its offset. RFC 5322 maps old zone names such as EST to -0500, and treats -0000 and single-letter military zones as carrying no zone information. Delays are computed in UTC, so a negative delay means the clocks of two servers disagree.
Authentication-Results lists the checks a receiving system ran, each with a method, a result, and properties such as smtp.mailfrom or header.d. Any sender can write this field, so mail systems must remove copies that claim their own name but did not come from them, and only the field your own system added should be trusted. That is normally the topmost one. Fields added by other systems along the way are shown for context.
DMARC relies on SPF only for the MAIL FROM domain, and on DKIM for the signing domain in d=. A message passes DMARC when one of those authenticated domains aligns with the From domain: identical for strict alignment, or with the same Organizational Domain for relaxed alignment. The analyzer shows the alignment of each domain next to the receiver's own dmarc= result.
ARC lets each intermediary, such as a mailing list, add a numbered set of three fields: ARC-Seal, ARC-Message-Signature and ARC-Authentication-Results. The analyzer checks the structure RFC 8617 requires: sets numbered from 1 with no gaps or repeats, one field of each kind per set, cv=none on set 1 and cv=pass on later sets, and at most 50 sets.
Authentication Result Codes
| Method | Result | Meaning |
|---|---|---|
| spf | pass | The server is authorized to send for the MAIL FROM domain. |
| fail | The domain says the server is not authorized. | |
| softfail | The domain says the server is probably not authorized. | |
| neutral | The domain states nothing about the server. | |
| none | No SPF record was found, or no domain could be checked. | |
| temperror | A temporary error, usually DNS, stopped the check. | |
| permerror | The domain's SPF record could not be interpreted. | |
| policy | SPF allowed the server, but local policy did not accept the result. | |
| dkim | pass | The message was signed, and the signature passed verification. |
| fail | The message was signed, but the signature failed verification. | |
| none | The message was not signed. | |
| policy | The message was signed, but the signature was not acceptable to the receiver's policy. | |
| neutral | The signature had syntax errors or could not be processed. | |
| temperror | A temporary error, such as a failed key lookup, stopped verification. | |
| permerror | A permanent error, such as a missing header field, stopped verification. | |
| dmarc | pass | The domain has a DMARC record, and an authenticated domain aligns with the From domain. |
| fail | The domain has a DMARC record, but no authenticated domain aligns with the From domain. | |
| none | The From domain has no DMARC record. | |
| temperror | A temporary error, usually DNS, stopped the check. | |
| permerror | A permanent error, such as a badly formed DMARC record, stopped the check. | |
| arc | none | The message arrived without an ARC chain. |
| pass | The message has an ARC chain that validated. | |
| fail | The message has an ARC chain that failed validation. | |
| iprev | pass | The sending IP address's reverse and forward DNS lookups agree. |
| fail | The reverse and forward DNS lookups of the sending IP address do not agree. | |
| temperror | A temporary DNS error stopped the check. | |
| permerror | No reverse DNS (PTR) data is published for the sending IP address. |
Microsoft anti-spam fields (13)
- CIP
- The connecting IP address.
- CTRY
- The source country or region, found from the connecting IP address, which might not be the original sending IP address.
- LANG
- The language the message was written in, as a country code.
- SCL
- The spam confidence level. In cloud organizations it does not decide whether the message is spam; use CAT and DIR to see how it was filtered.
- SFV
- The spam filtering verdict.
- BLK: Filtering was skipped and the message was blocked: the sender is on a user's Blocked Senders list.
- NSPM: Spam filtering marked the message as nonspam and sent it to the intended recipients.
- SFE: Filtering was skipped and the message was allowed: the sender is on a user's Safe Senders list.
- SKA: Spam filtering was skipped and the message went to the inbox: the sender is on an allowed senders or allowed domains list in an anti-spam policy.
- SKB: Marked as spam: the sender matched a blocked senders or blocked domains list in an anti-spam policy.
- SKI: Spam filtering was skipped: the source IP address is on the IP Allow List in the connection filter policy.
- SKN: Spam filtering was bypassed by an Exchange mail flow rule.
- SKQ: The message was released from quarantine and sent to the intended recipients.
- SKS: Marked as spam before spam filtering, by a mail flow rule or an on-premises Exchange decision.
- SPM: Spam filtering marked the message as spam.
- CAT
- The category of threat policy applied to the message.
- AMP: Anti-malware.
- BIMP: Brand impersonation.
- BULK: Bulk.
- DIMP: Domain impersonation.
- FTBP: Anti-malware common attachments filter.
- GIMP: Mailbox intelligence impersonation.
- HPHSH: High confidence phishing.
- HPHISH: High confidence phishing.
- HSPM: High confidence spam.
- INTOS: Intra-organization phishing.
- MALW: Malware.
- OSPM: Outbound spam.
- PHSH: Phishing.
- SAP: Safe Attachments.
- SPM: Spam.
- SPOOF: Spoofing.
- UIMP: User impersonation.
- IPV
- Whether the source IP address was on the IP Allow List or an IP reputation list.
- CAL: Spam filtering was skipped: the source IP address is on the IP Allow List.
- NLI: The IP address was not found on any IP reputation list.
- PTR
- The PTR record (reverse DNS name) of the source IP address.
- H
- The HELO or EHLO string of the connecting server.
- DIR
- The direction of the message.
- INB: Inbound message.
- OUT: Outbound message.
- INT: Internal message.
- SRV
- Bulk mail marker.
- BULK: Spam filtering identified the message as bulk email, using the bulk complaint level (BCL) threshold.
- SFTY
- The message was identified as phishing and marked with a safety tip value.
- 9.19: Domain impersonation: the sending domain is attempting to impersonate a protected domain.
- 9.20: User impersonation: the sender is attempting to impersonate a user in the recipient's organization or a protected user.
- 9.25: First contact safety tip, which might indicate a suspicious or phishing message.
- BCL
- The bulk complaint level. A higher BCL means a bulk message is more likely to generate complaints, and so more likely to be spam.
- Any other field
- Microsoft does not describe this field; its anti-spam team uses undocumented fields for diagnostics. Shown as Undocumented in the result.
Standards
Scope
What It Checks
- +Reads a full message or a header alone, with CRLF, LF or CR line endings, and stops at the first empty line.
- +Decodes RFC 2047 encoded words in the subject and display names.
- +Lists every Received hop oldest first, with the time as written, the time in UTC, the delay from the previous hop, and the total transit time.
- +Flags negative delays, delays over an hour, timestamps without zone information, and private or reserved IP addresses.
- +Splits each Authentication-Results field into its SPF, DKIM, DMARC, ARC and other results, grouped by the system that added it, and marks the topmost one.
- +Shows whether the SPF and DKIM domains align with the From domain, next to the receiver's own DMARC result.
- +Checks the structure of an ARC chain and lists DKIM-Signature tags, flagging rsa-sha1 and body length limits.
- +Decodes Microsoft X-Forefront-Antispam-Report and X-Microsoft-Antispam fields with Microsoft's documented meanings.
- +Flags several From fields or domains, a display name that holds another address, and Reply-To and bounce domains that differ from the sender's.
What It Does Not Check
- -It does not verify DKIM or ARC signatures, because that needs the signer's public key from DNS and the unmodified message body.
- -It does not look up IP addresses, domains or blocklists, and gives no reputation or location data.
- -It does not give a phishing score or say whether a message is safe.
- -It does not decode X- fields from providers other than Microsoft, which it lists without interpretation.
Defensive Use
The Authentication-Results field records the receiving system's SPF, DKIM and DMARC verdicts for a message, and the Received fields record each server it passed through. RFC 8601 warns that anyone can forge an Authentication-Results field that names a receiving domain, so only the one added inside your own mail system counts. Microsoft adds its anti-spam scan results to the X-Forefront-Antispam-Report field and documents its values, so administrators can see how a message was filtered.
Frequently Asked Questions
What is an Email Header Analyzer?→
The email header analyzer reads the header of an email message and lays it out for review: the decoded subject and addresses, each server the message passed through with its time converted to UTC and the delay between hops, the SPF, DKIM and DMARC results the receiving system recorded, whether the authenticated domains align with the From domain, the structure of the ARC chain, DKIM signature details, and Microsoft 365 anti-spam fields. The header is parsed in your browser and never uploaded.
What is the Email Header Analyzer used for?→
Triaging a reported phishing email, finding out why a legitimate message landed in spam or failed DMARC, tracing where a delivery delay happened, and checking which servers and authentication results a message carries.
Is my data sent anywhere?→
No. The Email Header Analyzer runs in your browser. What you enter stays on this page and is not sent to ImmunitySec or anyone else.
How is the Email Header Analyzer used defensively?→
The Authentication-Results field records the receiving system's SPF, DKIM and DMARC verdicts for a message, and the Received fields record each server it passed through. RFC 8601 warns that anyone can forge an Authentication-Results field that names a receiving domain, so only the one added inside your own mail system counts. Microsoft adds its anti-spam scan results to the X-Forefront-Antispam-Report field and documents its values, so administrators can see how a message was filtered.
How do I see the full header of an email in Gmail?→
Open the message, click More next to Reply, then Show original. The full header opens in a new window, with a Copy to clipboard button.
How do I see the header of an email in Outlook?→
In classic Outlook for Windows, double-click the message to open it, then click File and Properties. The header appears in the Internet headers box.
Which Authentication-Results field should I trust?→
The one added by your own mail system, normally the topmost. RFC 8601 says anyone can forge the field with a receiving domain's name, which is why mail systems must delete copies that claim to come from inside their trust boundary but did not.
Why does a hop show a negative delay?→
Each server writes the time from its own clock. RFC 5321 asks servers to write explicit offsets such as -0800, which the analyzer uses to convert every time to UTC, but a server whose clock is wrong still stamps a wrong time. A negative delay means the later server's clock is behind the earlier one's.
Does a DMARC pass mean the email is safe?→
No. DMARC pass means a domain that passed SPF or DKIM aligns with the From domain. It says nothing about the content, and RFC 9989 leaves display name attacks, where the name shown to the reader holds a different address, outside DMARC's scope.
Why are the Received fields in reverse order?→
RFC 5321 requires each server to add its Received field at the top and never reorder the fields below it, so the bottom field is the oldest. The analyzer lists hops oldest first.
Field formats come from RFC 5322, RFC 5321, RFC 2047, RFC 8601, RFC 6376, RFC 8617 and RFC 9989. Microsoft field meanings come from Microsoft's anti-spam message header documentation. Private and reserved address ranges come from the IANA special-purpose address registries.