Internet Guide Logo

Email format: header and body

Last Edit: 10/01/12

The current format for an email message is laid down in the Request for Comments document 'RFC 5322', and is referred to as the Internet Message Format (IMF). This document was edited by P. Resnick and was published: October, 2008. This RFC document updates previous document, such as RFC 4021 - Registration of Mail and MIME Header Fields - that was edited by G. Klyne (University of Oxford) and J. Palme (Stockholm University): March, 2005. There are numerous older RFC documents edited by a range of Internet pioneers: the most important of which is probably RFC 561 - Standardizing Network Mail Headers - that was edited by the inventor of email (Ray Tomlinson) and the inventor of FTP (Abhay Bhushan). Email messages originally relied on the File Transfer Protocol to transport messages; before email specific transport protocols were developed.

However, the format of an email message has largely remained the same since the first email was sent by Ray Tomlinson in 1971. The format of email messages has two components:

  1. Header
  2. Body

MIME is an important supplement to this format 'RFC 5322' that enables the body of the email messages to be encoded with non-ASCII elements. SMTP - the protocol used transport modern email messages - does not require MIME to transfer an email, nor POP - modern email retrieval protocol - to receive an email. In essence, many email's now come MIME formatted, due to the extensive non-textural features it provides, but some mail servers will only handle plain text email messages.


The header summerises the sender and receiver of the e-mail and contains transport/routing instructions. Each email message will only contain one header. Email headers can contain multiple field identifiers. Some of the 'core' header identifiers are listed below:

Primary fields

Secondary fields

Content fields

For a full list of fields.


After the content encoding and type are specified, the message body is where the content is provided. The body section of an email message is less complex than the header, as it only contains the content of the email and not the routing information. Historical email bodies were even less complex, as they only contained plain text (7-bit ASCII) data. When email was commercialized in the early 1990's, commercial email services - ect - needed to provide customers with a superior email service than plain text. This led to the development of the Multipurpose Internet Mail Extensions (MIME), which was outlined in:

  1. RFC 1521: MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies
  2. RFC 1522: MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text
  3. RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
  4. RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Format of Internet Message Bodies
  5. RFC 2047: MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text
  6. RFC 2049: Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples
  7. RFC 4288: Media Type Specifications and Registration Procedures
  8. RFC 4289: Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures

MIME was designed to be used with the SMTP protocol - which is the protocol to transport email messages - and enables email bodies to be encoded with non-ASCII data (usually HTML elements). This meant that hyperlinks and images could be embedded into the body of email messages. Therefore, email messages, services, and servers, are usually categorised as either: plain text or html. Email messages are formatted with MIME content through the insertion of a MIME identifier in the header: such as MIME-Version: 1.0.