Email Message Headers

If you don't know how to view the complete email message headers in your mail program, see the following document:
How to view complete email message headers

Sample Message Headers

Detailed descriptions of all headers are displayed in the Email message header descriptions below the headers.

Delivered-To: example@nettally.com
Received: by 10.217.48.4
          with SMTP id g4csp130137wew;
          Wed, 7 Nov 2012 10:44:08 -0800 (PST)
Received: by 10.236.118.16
          with SMTP id k16mr5689492yhh.66.1352313848104;
          Wed, 07 Nov 2012 10:44:08 -0800 (PST)
Return-Path: <message@inbound.efax.com>
Received: from mx2.nettally.com (mx2.nettally.com. [199.44.194.15])
          by mx.google.com
          with ESMTP id v8si23213479yhm.117.2012.11.07.10.44.07;
          Wed, 07 Nov 2012 10:44:08 -0800 (PST)
Received-SPF: fail (google.com: domain of message@inbound.efax.com does not designate
          178.150.193.215 as permitted sender) client-ip=178.150.193.215;
Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of message@inbound.efax.com
          does not designate 178.150.193.215 as permitted sender) smtp.mail=message@inbound.efax.com
Received: from 215.193.150.178.triolan.net [178.150.193.215]
          by mx2.nettally.com (Alligate(TM) SMTP Gateway v3.12.10.5)
          with ESMPT id <887F5F324179C900.B39C2127C7AAA54A@mx2.nettally.com>
          for <example@nettally.com>;
          Wed, 07 Nov 2012 13:44:03 -0500
Received: from welcome.aexp.com
          by [12.10.219.64];
          Wed, 7 Nov 2012 21:44:04 +0300
Date: Wed, 7 Nov 2012 21:44:04 +0300
From: "Incoming Fax" <message@inbound.efax.com>
Reply-To: "American Express" <DoNotReplyUS@service.americanexpress.com>
To: <example@nettally.com>
Cc: <someoneelse@example.com>
Subject: INCOMING FAX REPORT : Remote ID: 0049386853
Return-Path: AGNEUWEM0002002.AMEX.EML@welcome.aexp.com
Message-ID: <IUWEM030OTH20120402789039896967.AGNEUWEM0002002.ENG-ALERTS@welcome.aexp.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------05090400901090203020808"
X-Mailer: Microsoft Windows Live Mail 14.0.8117.416
X-MXRate-Prob: 0
X-MXRate-Country: UA
X-MXRate-Action: NONE
X-Alligate-ReceivingIP: [199.44.194.15]
X-Alligate-Country-Chain: United States->Ukraine->Destination
X-Alligate-Tarpit: ADDRSPACE;COUNTRY;GREY (50secs)
X-Alligate-Grey: Passed
X-Alligate-AddrSpace: Failed (1)
X-Alligate-REVDNS: TIMEOUT
X-Alligate-HELO: 215.193.150.178.triolan.net
X-Alligate-Spam: ADDRSPACE;TARPIT;
X-Alligate-MsgScan: (69) (semicolon-separated list of various failed tests and penalty points)
X-Alligate-ID: 14056965
X-Originating-IP: 178.150.193.215
X-Alligate-RcptTo: <example@nettally.com>
X-Alligate-MailFrom: <message@inbound.efax.com>
Return-Path: message@inbound.efax.com
X-Alligate-In: Passed - Adult: 0 (Req: 1) Spam: 3 (Req: 10) Tot: 3 (Req: 12)
X-Alligate-QueueFile: 242001184.dta
X-Alligate-XFrom: <message@inbound.efax.com> [178.150.193.215] Ukraine (UA)
X-Alligate-XTo: <example@nettally.com> (example@nettally.com)

Email message header descriptions

See also: Permanent Message Header Fields and Provisional Message Header Fields

Delivered-To

The mailbox the message was delivered to.

Received

These provide information about each mail server involved during the message delivery process. The bottom-most Received header is the first mail server involved (closest to the actual sender) and may be forged by some spammers/virus distributors; the top-most Received header is the last mail server involved (closest to the recipient). The server names that appear next to the IP addresses are frequently invalid/forged. The IP addresses contained in [] or () are what's important in determining the identity of these servers. The timestamps are the dates/times according to that particular mail server. If the server doesn't have the correct date/time and/or timezone, the timestamp you see will not be accurate.
See the Date/Time formats section at the end of this document.
Standard: RFC 5321: Simple Mail Transfer Protocol - § 4.4. Trace Information

Return-Path

The primary purpose of the Return-path is to designate the address to which messages indicating non-delivery or other mail system failures are to be sent.^q.v.
Standard: RFC 5321: Simple Mail Transfer Protocol - § 4.4. Trace Information

Received-SPF

Reference: Sender Policy Framework
Reference: SPF Received Header
Reference: RFC 4408: Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 - § 7. The Received-SPF Header Field.

Authentication-Results

Presents the results of a message authentication effort in a machine-readable format. The intent is to create a place to collect such data when message authentication mechanisms are in use so that a Mail User Agent (MUA) and downstream filters can make filtering decisions and/or provide a recommendation to the user as to the validity of the message's origin and possibly the integrity of its content.
End users are not expected to be direct consumers of this header field. This header field is intended for consumption by programs that will then use or render such data in a human-usable form.^q.v.
Standard: RFC 5451: Message Header Field for Indicating Message Authentication Status.

Date

The origination date specifies the date and time at which the creator of the message indicated that the message was complete and ready to enter the mail delivery system. For instance, this might be the time that a user pushes the "send" or "submit" button in an application program. In any case, it is specifically not intended to convey the time that the message is actually transported, but rather the time at which the human or other creator of the message has put the message into its final form, ready for transport. (For example, a portable computer user who is not connected to a network might queue a message for delivery. The origination date is intended to contain the date and time that the user queued the message, not the time when the user connected to the network to send the message.)^q.v.
See the Date/Time formats section at the end of this document.
Standard: RFC 5322: Internet Message Format - § 3.6.1. The Origination Date Field

From

Specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message.^q.v.
This value is entered by the sender and can be any name and email address--including yours. Spammers frequently make use of this freedom by entering any email address they want to, so long as it doesn't trace back to the spammer. Think of this as the name/address one would include in the upper-left corner of a regular envelope before sending it. Replies to the message are sent to this address unless there is a Reply-To header/address that overrides it.
Standard: RFC 5322: Internet Message Format - § 3.6.2. Originator Fields

Reply-To

When the Reply-To field is present, it indicates the address(es) to which the author of the message suggests that replies be sent. In the absence of the Reply-To field, replies SHOULD by default be sent to the mailbox(es) specified in the From field unless otherwise specified by the person composing the reply.^q.v.
Standard: RFC 5322: Internet Message Format - § 3.6.2. Originator Fields

To

Address(es) of the primary recipient(s) of the message.
Standard: RFC 5322: Internet Message Format - § 3.6.3. Destination Address Fields

Cc

(Carbon copy) contains the addresses of others who are to receive the message, though the content of the message may not be directed at them.
Standard: RFC 5322: Internet Message Format - § 3.6.3. Destination Address Fields

Bcc

(Blind carbon copy) contains addresses of recipients of the message whose addresses are not to be revealed to other recipients of the message.
Standard: RFC 5322: Internet Message Format - § 3.6.3. Destination Address Fields

Subject

Contains a short string identifying the topic of the message.
Standard: RFC 5322: Internet Message Format - § 3.6.5. Informational Fields

Message-ID

Unique message identifier that refers to a particular version of a particular message. The server name after the @ symbol is often invalid/forged in spam messages.
Standard: RFC 5322: Internet Message Format - § 3.6.4. Identification Fields

User-Agent

Information about what mail software was used to send the message. This information is usually found in the X-Mailer header.
Reference: RFC 4229: HTTP Header Field Registrations - § 2.1.110. Header field: User-Agent
Standard: RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1 - § 14.43. User-Agent
Standard: RFC 5536: Netnews Article Format - § 3.2.13. User-Agent

X-Mailer

Information about what mail software was used to create the message.
Reference: RFC 2076: Common Internet Message Headers - § 3.4. Sender and recipient indication

MIME-Version

Version of the Internet message body format standard in use by the sender's mail program.
RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies - § 4. MIME-Version Header Field

Content-Type

allows mail reading programs to automatically identify the type of a structured message body and to process it for display accordingly.
Reference: RFC 1049: A Content-Type Header Field for Internet Messages.

Content-Transfer-Encoding

Many media types which could be usefully transported via email are represented, in their "natural" format, as 8bit character or binary data. Such data cannot be transmitted over some transfer protocols. For example, SMTP restricts mail messages to 7bit US-ASCII data with lines no longer than 1000 characters including any trailing CRLF line separator. The Content-Transfer-Encoding header defines a standard mechanism for encoding such data into a 7bit short line format.^q.v.
Standard: RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies - § 6. Content-Transfer-Encoding Header Field

X-MXRate-Prob

Probability of the message being spam based on historical data associated with the mail server that sent the message to our network.

X-MXRate-Country

ISO-3166 alpha-2 country code associated with the IP address of the mail server that sent the message to our network. This is not related to the name of the server. You can block mail based on this header by editing your blacklist.

X-MXRate-Action

What action was performed based on historical data associated with the mail server that sent the message to our network.

X-Alligate-ReceivingIP

IP address of the Alligate server that received and processed the message.

X-Alligate-Country-Chain

The series of countries the message passed through based on the IP addresses of each message transfer agent (MTA) in the Received headers.

X-Alligate-Tarpit

Shows the test failures that triggered the message to be tarpitted. The absence of this header indicates the message was not tarpitted.

X-Alligate-Grey

When present, the value is "Passed" or "Skipped". If a sending mail server fails greylisting while attempting to hand off mail to our mail system, the message is not processed.

X-Alligate-RecipsValid

The number of valid recipients (so far) in our network this message has been sent to during this transaction.

X-Alligate-MailFromXA

X-Alligate-RSETs

The number of times the sending mail server issued the RSET command while communicating with our mail server.
Standard: RFC 5321: Simple Mail Transfer Protocol - § 4.1.1.5. RESET (RSET)

X-Alligate-AddrSpace

If present, the number of times the sending mail server issued improperly formatted "MAIL FROM" and/or "RCPT TO" commands while handing off the message to our mail system.
Standard: RFC 5321: Simple Mail Transfer Protocol - § 4.1.1.2. MAIL (MAIL)
Standard: RFC 5321: Simple Mail Transfer Protocol - § 4.1.1.3. RECIPIENT (RCPT)

X-Alligate-REVDNS

The name, according to DNS, corresponding to the X-Originating-IP header. A value of TIMEOUT indicates the DNS query timed-out.

X-Alligate-HELO

The HELO or EHLO identification announced by the mail server that handed off the message to the Alligate server.
Standard: RFC 5321: Simple Mail Transfer Protocol - § 3.2. Client Intitiation
Standard: RFC 5321: Simple Mail Transfer Protocol - § 4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO)

X-Alligate-Spam

Semicolon-separated list of test failures that contributed to the message being held in the spam digest.

X-Alligate-MsgScan

Semicolon-separated list of test failures prior to the message reaching the user-level filtering.

X-Alligate-ID

Unique identifier associated with the message while it was being processed by the Alligate spam filtering system.

X-Originating-IP

Apparent IP address of the mail server that sent the message to our network.

X-Alligate-RcptTo

The actual recipient email address as stated in the message envelope. The value of this field corresponds to the "RCPT TO" value issued by the sending mail client and/or SMTP server. This address may not be visible in the To, Cc, and Bcc basic message headers.
Standard: RFC 5321: Simple Mail Transfer Protocol - § 4.1.1.3. RECIPIENT (RCPT)

X-Alligate-MailFrom

The email address the sender claims to be as stated in the message envelope. The value of this field corresponds to the "MAIL FROM" value issued by the sending mail client and/or SMTP server. This is almost always falsified and typically reprents a random email address previously harvested by spyware/adware, websites that distribute their form data, etc.
Standard: RFC 5321: Simple Mail Transfer Protocol - § 4.1.1.2. MAIL (MAIL)

X-Alligate-MXRateIP

IP address of the mail server that sent the message to our network.

X-Alligate-In

Details about why the message was delivered without being held in the Spam Digest or deleted.
IGNORED:

Whitelisted: The message was whitelisted for the reason specified.

Known good address: The message was delivered because the mail server that sent it to our network is normally not known for sending spam.

Passed: The message was not whitelisted, but was still delivered.

The Adult, Spam, and Tot(al) values are the penalty points that were applied to the message during the filtering process. The Req(uired) values are the hold scores you've configured. If the message's penalty points reached any of the hold score values, the message would have been held in your Spam Digest instead of being delivered. You can use the information in this header to get an idea of how you can adjust your existing scores to better suit your needs.

X-Alligate-QueueFile

Name of the file corresponding to the message while it was being processed by the spam filtering system.

X-Alligate-XFrom

Originator's apparent email address (based on the Reply-to header, Fron header, or the MAIL FROM message envelope data (X-Alligate-MailFrom), in that order), the country name and ISO-3166 alpha-2 country code associated with the IP address of the mail server that sent the message to our network (see the X-MXRate-Country header)

X-Alligate-XTo

X-Alligate-Out

This header is present and the value is Delivery request when the message was previously held in a Spam Digest and a delivery request was made, releasing the message.

X-RCPT-TO

Final recipient email address after any alias forwarding takes place on our POP3/IMAP server.

Status

Used by some mail delivery systems to indicate the status of delivery for this message when stored.
Reference: RFC 2076: Common Internet Message Headers - § 3.16. Miscellaneous

X-UIDL

Unique identifier used by the POP3 protocol for retrieving mail from a POP3 server. It is normally added between the POP3 server and the recipient's mail software during message retrieval.

X-IMail-ThreadID

Unique ID for the message that corresponds to log entries and processing files on an IMail server during processing.

Date/Time formats (contained in Received and Date headers)