Email Header Analyzer

This Email Header Analyzer inspects email header fields and displays important information about the email massage including the details related to the source, destination, and forwarding email servers. The tool also shows all header fields present in the message in an easy to read table that can be sorted by the header name column.

The information displayed by this Analyser is based strictly on the data obtained from email header fields and/or DNS (Domain Name System). This tool does not attempt to detect forged email headers or any information inconsistency.

An email message contains a header section and an optional body. The header section is comprised of a number of header fields with specific syntax. The body is separated from the header section by an empty line.

Each header field consists of two parts, a field name and a field body, divided by a colon (":"). The maximum header field length is 998 characters, excluding the end of the line characters. For convenience, the body portion of a header field can be split into multiple lines by inserting the end of the line characters before any space or horizontal tab characters.

The RFC5322 standard defines a set of basic header fields and allows for any other syntax compliant optional fields to appear in a message. Some of the standard header fields are:

• the originator fields - "From:", "Sender:", "Reply-To:";
• the originator date field - "Date:";
• the destination address fields - "To:", "Cc:", "Bcc:";
• the message identification and informational fields - "Subject:", "Message-ID:", "In-Reply-To:", "References:"
• the trace fields - "Return-Path:", "Received:".

Many other IETF standards extend the list of header fields. For example, RFC7208 outlines the usage of the additional trace field "Received-SPF:", RFC8601 - the "Authentication-Results:" field.

Furthermore, non-standard "X-headers", i.e., header fields with "X-" in the beginning of the name, can be added to a message at the discretion of email systems or providers. Some examples of X-headers are: "X-Mailer:", "X-Origin-Country:", "X-Received:", "X-Sender-IP:".

As email message travels from the sender to the destination email system all receiving servers on the path are expected to prepend to the message a new "Received:" field with the details of the transfer operation. All "Received:" fields must be groupped together with the most recent record added at the top of the group.

The format of the "Received:" field is illustrated by the following examples:

The body of the "Received:" field may consist of up to 4 sections. The first section, starting with the word "from", provides information about the sending server. The second section, starting with "by", describes the receiving server. The third section may list additional details about the transmission protocol, transport, recipient, and message identifier, indicated by "with", "via", "for", and "id", respectively. The last section, separated from the rest by a semicolon (";"), shows the date and time the message was received. More information about the "Received:" fields can be found in RFC5321, Section 4.4.

Here are the main message header fields related to email authentication:

The Authentication-Results header provides the results of various authentication checks performed on the email (RFC8601).

Example Header:

Header Format and Fields:

• mx.example.com - Mail server performing the checks.
• The header may contain results for one or more of the following authentication methods:
  • none - The presence of "none" (and the absence of any method or result tokens) indicates that no message authentication was done.
  • arc - [RFC8617, Section 6].
  • auth - SMTP Service Extension for Authentication [RFC8601].
  • dkim - DomainKeys Identified Mail Signatures [RFC8601].
  • dmarc - Domain-based Message Authentication, Reporting, and Conformance [RFC7489].
  • spf - Sender Policy Framework [RFC8601].
  • iprev - Reverse IP address name validation [RFC8601].
  • rrvs - Require-Recipient-Valid-Since Header Field and SMTP Service Extension [RFC7293].
  • smime - S/MIME Signature Verification [RFC7281].
  • vbr - Vouch By Reference [RFC6212].
  • dnswl - DNSWL [RFC8904].
• Presented information details vary by the authentication method (see IANA - Email Authentication Parameters). Possible result values are:
  • arc - fail, none, pass.
  • auth - fail, none, pass, permerror, temperror.
  • dkim - fail, neutral, none, pass, permerror, policy, temperror.
  • dmarc - fail, none, pass, permerror, temperror.
  • iprev - fail, pass, permerror, temperror.
  • rrvs - fail, none, pass, permerror, temperror, unknown.
  • smime - fail, neutral, none, pass, permerror, policy, temperror.
  • spf - fail, neutral, none, pass, permerror, policy, softfail, temperror.
  • vbr - fail, none, pass, permerror, temperror.
  • dnswl - none, pass, permerror, temperror.

The Received-SPF header indicates the result of the Sender Policy Framework (SPF) check which helps detect email spoofing by verifying the sender's IP address against the domain's allowed sending IPs (RFC7208).

Example Header:

Header Format and Fields:

• fail / neutral / none / pass / permerror / policy / softfail / temperror - Result of the SPF check.
• example.com - Domain of the sender.
• sender@example.com - Email address of the sender.
• 192.0.2.1 - IP address of the sender.
• permitted sender - Indicates if the IP address is allowed to send emails for the domain.

The DKIM-Signature header contains the DomainKeys Identified Mail (DKIM) signature which provides a way to evaluate the integrity and authenticity of the message content (RFC6376).

Example Header:

Header Format and Fields (see also IANA - DomainKeys Identified Mail (DKIM) Parameters):

• v=1 - DKIM version (REQUIRED).
• a=rsa-sha256 - Algorithm used for signing (REQUIRED).
• d=example.com - Domain of the sender (REQUIRED).
• i=@example.com - User or sender identifier (OPTIONAL). Default is an empty local-part followed by an "@" followed by the domain from the "d=" tag.
• s=selector1 - Selector for the DKIM public key for the domain from the "d=" tag (REQUIRED).
• q=dns/txt - Query method for public key retrieval (OPTIONAL). Currently, the only valid value is "dns/txt", which defines the DNS TXT resource record (RR) lookup algorithm.
• c=relaxed/relaxed - Canonicalization methods for the header and body, respectively (OPTIONAL). Available options - "relaxed" and "simple". If no canonicalization algorithm is specified, the "simple" algorithm defaults for both header and body.
• l - Body length count (OPTIONAL).
• h=from:to:subject:date - Signed header fields - a colon-separated (":") list of header field names that identify the header fields presented to the signing algorithm (REQUIRED).
• bh=abc123... - Base64-encoded hash of the canonicalized body part of the message (REQUIRED).
• b=def456... - Base64-encoded digital signature (REQUIRED).
• t - Signature timestamp (RECOMMENDED).
• x - Signature expiration (RECOMMENDED).
• z - Copied header fields (OPTIONAL).

The Authenticated Received Chain header fields (ARC-Seal, ARC-Message-Signature, and ARC-Authentication-Results) allow intermediary mail systems to sign messages during transit, preserving the authentication results for downstream recipients (RFC8617). Together, these three header fields compose a single ARC record set. A single email message may contain multiple ARC record sets.

Example Headers:

Header Format and Fields:

The ARC-Seal header field contains a seal that permits to verify the integrity the corresponding ARC record set. The header field is similar in syntax and semantics to DKIM-Signature header fields, with the following differences:

• the only supported tags are:
  • i=1 - Identifies the ARC record set (instance) that the fields belongs to.
  • a=rsa-sha256 - Algorithm used for sealing.
  • d=example.com - Domain of the sealing entity.
  • s=selector1 - Selector for the public key.
  • t=1625247603 - Timestamp of the seal.
  • cv=none - Chain validation status with possible values of none, fail, and pass.
  • b=abc123... - Digital seal.
• the signature of the ARC-Seal field only covers the given ARC set header field values and does not cover the body of the message; therefore, there is no "bh" tag.

The ARC-Message-Signature header field contains the signature of the message processed at the given mail transfer hop. It has the same syntax and semantics as the DKIM-Signature field, with the following differences:

• no version tag ("v") is defined for the ARC-Message-Signature header field.
• the "i" tag identifies the ARC record set that the fields belongs to.

The ARC-Authentication-Results header field contains the results of authentication checks at the given mail transfer hop. It is similar in syntax and semantics to an Authentication-Results field with the addition of on the ARC record set instance tag ("i").