MIME Structure — Multipart, Plaintext Part and Content-Type

How an email is assembled

A modern message is almost never a single block of text. It is a tree of parts, and the Content-Type header says by what rule to read it. Three types cover everyday use:

• multipart/alternative — the same message in several formats. The client picks one.
• multipart/related — HTML plus the images it embeds via cid:. The parts belong together.
• multipart/mixed — the message plus genuine attachments. The parts are independent.

A well-built message with an attachment and an inline image nests all three: mixed on the outside, related inside it, alternative inside that. The order within alternative is not arbitrary — under RFC 2046 §5.1.4 the least preferred version comes first. Plaintext therefore belongs at the top, HTML at the bottom. Reverse the order and a share of your recipients will be shown the plain text.

What AnalyzeMy.Email checks

• Content type of the message and the structure of the parts it contains
• Presence of a plaintext part — reported separately from the HTML part
• Size of both parts and their ratio to each other
• Number of images and the image-to-text ratio
• Attachments with their file types

Why filters weigh this

The missing plaintext part is the most common finding. HTML alone with no text alternative has counted as a spam indicator for years, because legitimate bulk senders practically always include one while automated spam tooling often omits it. SpamAssassin and similar systems award points for it.

The plaintext must not be a decoy. A text part reading "This message requires an HTML-capable client" is worse than none: it satisfies the form while delivering no content, and that exact pattern is easy to spot. The text part should carry the same message as the HTML.

A very high image share with little text is the classic image-spam pattern: text rendered as graphics so content filters find nothing to read. Since many clients only load images on request, such messages also arrive largely empty for the recipient.

Recommendations

• Always send multipart/alternative with a real text part carrying the same content.
• Keep the order: plaintext first, HTML last.
• Declare the character set per part — charset=utf-8 and a suitable encoding (quoted-printable or base64). Missing declarations produce mangled accented characters.
• Do not use images as a substitute for text. Anything that matters belongs in the message as text.
• Do not over-nest the structure: more levels than necessary confuse older clients and gain nothing.