HTML電子メール（エイチティーエムエルでんしメール）は、プレーンテキストでは実現できない機能である「書式の指定」や「データの意味の指定」を行った電子メールである。マークアップにはしばしばHTMLの部分集合が使われているが、必ずしも明確に部分集合を定義したものばかりではない。殆どの電子メールクライアントは、HTML電子メールに対応し、大半は既定されている。これらのクライアントの多くは、HTML電子メールを作成するためのGUIエディタと、受け取ったHTML電子メールを表示するためのレンダリングエンジンの両方を含む。送り手は、HTML電子メールを使って、適確にブロック引用、見出し、ビュレット、太字、添え字及び上付き文字を表現し、その他のビジュアル、タイプグラフの可読性及び文字の美しさを改善することができる。同じように、セマンティック・ウェブの情報をメッセージ中にエンコードすることも、元の文章、メッセージIDの引用もできる。長いURLを複数に分割しないでリンクすることができ、一行につき78文字で統一する（古いテキスト端末に必要なRFC 5322に定義がある）代わりに、文章をユーザのビューポートの幅に合わせることもできる。その概念の登場以来、多くの人々が口頭で全てのHTML電子メールに対して、様々な理由で反対した。（英語）というインターネット現象は、「電子メールは、人間に読みやすいASCII形式で送られ続けるべきである」と主張している。多くのニュースグループとメーリングリストにおいては、未だに不適切であると考えられている一方で、個人及び広告メールのための採用は、増加し続けている。HTML電子メールはほとんど無害であると見る向きもあるが、セキュリティ上のリスクを理由に反対する主張も多い。RFC 2822に準拠する電子メールソフトは、HTML形式の文書ではなく、プレーンテキストに対応することのみを要求されている。HTML形式の電子メールを送ることには、受信者の電子メールクライアントがそれに対応しているかどうかという問題がある。最悪の場合は、受信者がメッセージではなく、HTML文書を読むことになる。これらのHTML形式のものに対応していない電子メールクライアントの中には、W3Cとともに、一貫してレンダリングしない者もいる。そして、多くのHTML電子メールは、レンダリング又は送信の問題を引き起こす可能性がある特にMSN、Hotmailのどちらにも準拠していない。特に、全部のHTMLドキュメントのためにCSS形式で用いられるタグは、十分に対応しておらず、時々、全体が削除される、'慣習'上の標準であるインライン形式の宣言を引き起こす。しかしながら、ニュースレターの開発者の要求に対する不足を引き起こさない回避策が開発された。互換性の問題に対処するために、The Web Standards Projectにおいて、The Email Standards Projectが発足した。この計画では、電子メールリーダアプリケーション開発者やデザインコミュニティの関係者が協同して電子メールにおけるWeb標準の策定を目指す。そこでは、電子メールクライアントをレンダリングで格付けるacid testが行われる。また、Googleを説得するために、Gmailのレンダリングを改善した。例えば、従業員の注目の結果、彼らはウェブ開発者にビデオモンタージュを公開した。一部の送信者は、大きく、カラフルで、邪魔なフォントに過度に依存する可能性があるが、作成したメッセージはより読み難い。これらの形式による特別の心配により、幾つかのユーザーエージェントは、読み手が部分的に形式を無視することができるようにしている。例えば、Mozilla Thunderbirdは、いつでも利用できるのではないが、フォントのサイズを指定することができる。更に、送り手と読み手との間の外観の違いに依り、セクションごとの筆者を区別することができ、読み易さを改善することができる。多くの電子メールサーバは、電子メールクライアントがHTML電子メールの文書のみを読めることを確認するために、RFC 1521で指定されたcodice_1を用いて、自動的にプレーンテキストのメッセージを生成するように設定され、HTMLバージョンとともに送られている。文書自体は、オルターナティブマルチタイプのもので、クライアントがテキストのみを読むプレーンテキストタイプ、HTML形式のものを受けられるクライアントに読まれるHTMLテキストタイプの二つがある。しかしながら、プレーンテキストバージョンは、欠落した重要な書式情報だろう。例えば、方程式は上付き文字を失い、全く新しい意味を取る。多くのメーリングリストは、故意にプレーンテキストの部分が残るようにHTMLの部分を取り除き、又は文書全体を拒否してHTML電子メールをブロックする。HTML電子メールは、プレーンテキストよりも長い。特別な書式が使われていなくても、最小のHTMLドキュメントで使われるタグのからのオーバーヘッドがあるだろう。そして、書式が多用されれば重くなる。同じ内容を違う書式に複写したマルチパートメッセージは、更にサイズを増加させる。マルチパートメッセージのプレーンテキスト部分は、プレーンテキストそれのみで取得出来るにもかかわらず、IMAPFETCHコマンドを使用している。プレーンテキストと十以上の因子が混合したメールの間には、ダウンロード時間の違いは、殆どのユーザが遅いモデムから電子メールにアクセスしていた1990年代から懸念されたのであるが、今日の接続では、取り分け、画像、音声ファイルその他の一般的な添付データを比較して殆ど人にとって速度の差は僅かなものである。HTMLにより、リンクのテキストとは異なるリンクを対象に出来る。これは、フィッシングに使われる可能性がある。ユーザは、これに騙されて、リンクされたウェブサイトを正式なもの（例えば、銀行）と信じてアクセスして、意図せず、詐欺師に銀行の口座番号などの個人情報を提供することになってしまう可能性がある。もし、電子メールがウェブバグ（外部のサーバからのインラインコンテンツ。例えば画像）を含めば、サーバは、サードパーティに対して、電子メールが開かれていることを警告することが出来る。これは、潜在的なE-mail privacyのリスクである。電子メールアドレスが本物であり、メッセージが読まれたときに明らかにされることである。こういった理由で、一部の電子メールクライアントは、ユーザに要求されるまで、外部からの画像を読み込まないようにしている。ネットワークの脅威が増加していた期間において、アメリカ国防総省は、全てのHTML電子メールをテキスト電子メールに変換した。マルチパートタイプは、異なる方法でコンテンツを表示するためのものであるが、これは時々、スパマーが、メッセージを正規のものと信じさせ、スパムフィルターを回避するために悪用される。この方法は、スパマーが、メッセージのテキスト部分に差し障りのないコンテンツを含ませ、ユーザに表示されるHTML部分にスパムの内容を置くことによって実現される。

出典:wikipedia