Mail Message Structure
The original Internet mail format, RFC 822, was designed with 7-bit ASCII in mind since it was predominately used by North American companies and institutions. The message format is pretty straight forward and other protocols, like HTTP, use a similar format. Essentially the message is broken into two parts: message headers and message body ie. content.
The message body is pretty straight forward and contains the ASCII text of the sender's message. The message headers contain a variety of information related to sender, recipients, reply address, date, subject, and routing trace information.
Return-Path: <firstname.lastname@example.org> Received: from [192.0.2.1] by mx.bagend.com (8.15.2/8.15.2) with ESMTPSA id u21CagYV023636 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <email@example.com>; Wed, 9 Mar 2016 12:24:41 -0500 Received: from [192.168.1.69] by smtp.shire.org with ESMTPSA id tBGD9cVK001040; Wed, 9 Mar 2016 12:24:41 -0500 Date: Wed, 9 Mar 2016 12:24:37 -0500 From: "Alice Wheaks" <firstname.lastname@example.org> To: "Bilbo Baggins" <email@example.com> Subject: State of your lawn. Message-ID: <56D58CD8.firstname.lastname@example.org> Dear Mr. Baggins, Its been over a week since you last cut your lawn and its length has become unacceptable with respect to the Shire Council Publicly Seen Green Space Guidelines. We ask that you address this issue by end of day tomorrow. We have also been made aware of little Gnome statues hiding in partial view of the road. In particular those Gnome statues doing unseemly things to Lady Bug statues. These statues are an affront to Gnomes and Lady Bugs of standing everywhere and politically incorrect for public display along Shire paths. Please see to their removal. -- Alice Wheaks Shire Council & Gardens Committee
The above message is an example of a basic Internet mail message. The top few lines up to and including the first empty line are the message headers. Following the first empty line is the message body. In the above example only a handful of the most common headers are illustrated. RFC 5322 details many more.
The Received headers are prepended by each MTA that handles the message in transit. They typically detail the machine sending the message (from X), the machine receiving the message (by Y), the MTA transaction id (id Z) and timestamp. Other field pairs are possible and vary depending on the MTA software.
After the Received headers, the remaining headers can appear in any order, typically the From represents the author and sender, however its possible to have a From header for the author and a separate Sender header if the message was sent by a third party. Replies are directed to the author indicated in the From header or if present the address given in a Reply-To header.
The Date header should always be present and reflects the date & time when the message was composed. If a Date header is missing the outbound MTA will add one.
The To and optional Cc headers provide a list of recipients to whom the message was sent. This list might be incomplete, particularly in the case of blind carbon copy (Bcc) recipients.
Finally every message must have a Message-ID, typically created by the MUA when the message is composed. This header is intended as a unique identifier for the message on the system it was composed. It used by other headers, like the References header, to thread a conversation of messages together and other house keeping tasks.
In mail message headers, parenthesised expressions are human readable comments.