HTMLメールのクライアント互換性:どこで何が動くか、日本語メールで何を確かめるか

執筆:Mara Levin ・ 2026年10月7日更新 ・ caniemailのデータと各社ドキュメントを同日に確認

結論

HTMLメールはブラウザと同じ感覚では書けません。クライアントは「Outlook(Windows)」「Gmail」「それ以外」の三つに分けて考えると整理できます。レイアウトはテーブルで組み、文字色やサイズなど読みやすさを左右するスタイルはインラインで書き、<style> は改善用に限ります。日本語メールでは、縦書き、圏点、折り返し、行間といった組版まわりが、caniemailでも対応にばらつきのある項目です。数値は caniemail.com の公開データに基づき、各項目に該当ページへのリンクを付けています。

三つのグループに分けて考える

一つ目は Outlook(Windows) です。caniemailのデータでは2007から2019までのデスクトップ版が対象で、表の中で「非対応」が最も多い列になります。display:flex、float、border-radius、background-image、@media などがここで引っかかります。二つ目は Gmail です。styleタグの項目によると、Gmailは body 内の style を認めず、タグの大きさを16 KBまでに制限し、iOSとAndroidのアプリでは、Googleアカウント以外のメールボックスで style タグそのものを解釈しません。Maizzleのドキュメントも、IMAPアドレスでGmail Androidを使う場合に <style> が無視されることを、GANGAという呼び名とともに説明しています。三つ目は Apple Mail、Outlook.com、Samsung Email、Yahoo! などで、多くの機能が使えますが、細かな例外があります。

日本の配信では、もう一つ考慮が必要です。caniemailの一覧に載っているのは、Gmail、Outlook、Yahoo! Mail、Apple Mailなどの国際的なクライアントで、日本のキャリアメールやYahoo!メール(日本)を個別に測った項目は見当たりません。「Yahoo! Mail」の列を日本のサービスの結果として読むのではなく、配信リストに多いアドレスにテストメールを送って、自分の目で確かめることをお勧めします。

レイアウトの基本プロパティの対応状況

プロパティ Gmail(ウェブ) Gmail(iOS) Outlook(Windows) Outlook.com Apple Mail Yahoo!
padding 対応 対応 部分(セルのみ) 対応 対応 対応
margin 部分 部分 部分 部分 対応 部分
max-width 対応 対応 部分(tableのみ) 対応 対応 対応
border-radius 対応 対応 非対応 対応 対応 部分
background-image 対応 対応 非対応(VMLで代替) 対応 対応 部分
display:flex 対応 部分 非対応 対応 対応 対応
display:grid 対応 部分 非対応 対応 対応 対応
position 非対応 非対応 非対応 部分 部分 部分
float 対応 部分 非対応 対応 対応 部分
@media 部分 部分 非対応 部分 対応 部分
@font-face 非対応 非対応 部分 非対応 対応 非対応
box-shadow 非対応 部分 非対応 対応 対応 非対応

出典:caniemail.comのデータ(2026年9月16日更新)。各クライアントの最新の記録を採用しています。「部分」は条件付きの対応で、詳しい条件は各ページの注記にあります。例えばGmailアプリ(iOS)の「部分」の多くは、Googleアカウント以外では使えないという注記です。

表から読み取れること

Outlook(Windows)の列は、角丸、背景画像、Flexbox、Grid、float、メディアクエリのすべてが「非対応」で、padding も「セルのみ」という条件が付きます。caniemailのpaddingのページには、同じ行のセルでは縦のpaddingが最も大きい値に揃ってしまう不具合の注記もあります。そのため、余白は td のpaddingで取り、レイアウトの骨格は role="presentation" を付けたテーブルで作ります。Apple Mailの列は「対応」が多く並びますが、ここだけを基準に作ると、ほかのクライアントで崩れます。「部分」と書かれた項目は、使えないという意味ではなく、条件を読んでからテストする項目です。

角丸のボタンは、Outlook(Windows)ではVMLの roundrect を使う方法がborder-radiusのページに紹介されています。背景画像も同様で、background-imageのページがVMLでの代替方法を案内しています。条件付きコメントとVMLを組み合わせた典型例は次のとおりです。bgcolor の指定は、画像が読み込まれなかったときでも文字が読めるようにするための保険です。

<td background="https://example.co.jp/img/hero.jpg" bgcolor="#2b3a55" width="600" valign="top"
    style="background-image:url('https://example.co.jp/img/hero.jpg'); background-color:#2b3a55;">
  <!--[if gte mso 9]>
  <v:rect xmlns:v="urn:schemas-microsoft-com:vml" fill="true" stroke="false" style="width:600px;height:300px;">
    <v:fill type="tile" src="https://example.co.jp/img/hero.jpg" color="#2b3a55" />
    <v:textbox inset="0,0,0,0">
  <![endif]-->
  <div style="padding:40px 30px; color:#ffffff;">新生活応援フェア 10月21日まで</div>
  <!--[if gte mso 9]>
    </v:textbox>
  </v:rect>
  <![endif]-->
</td>

サイズ、色、関数まわりの項目

ここまでの表に載せていない、よく使うプロパティを続けます。Outlook(Windows)の「非対応」が目立つ一方で、Apple Mailは関数や変数まで対応しており、同じ書き方でもクライアントによって結果がまったく変わる領域です。

プロパティ Gmail(ウェブ) Gmail(iOS) Outlook(Windows) Outlook.com Apple Mail Yahoo!
width 対応 対応 部分(div、p、imgでは不可) 対応 対応 対応
height 対応 対応 部分(div、pでは不可) 対応 対応 非対応(min-heightに置換)
min-width 対応 対応 非対応 対応 対応 対応
box-sizing 対応 対応 非対応 対応 対応 非対応
opacity 対応 対応 非対応 対応 対応 対応
border-spacing 対応 対応 非対応 対応 対応 対応
rgba() 部分 部分 非対応 対応 対応 部分
linear-gradient() 対応 対応 非対応(VMLで代替) 非対応 対応 非対応
calc() 対応 部分 非対応 非対応 対応 非対応
CSS変数 var() 非対応 非対応 非対応 非対応 対応 非対応
rem 対応 対応 非対応 対応 対応 非対応

出典と更新日は上の表と同じです。rgb(0 128 0 / 1) のような空白区切りの書き方は、caniemailによると、Gmailでstyle属性全体が取り除かれる原因になります。色は6桁の16進数で書くのが安全です。

HTML要素の対応状況

CSSだけでなく、HTMLの要素にも差があります。caniemailの記録では、table と見出しはどこでも使えますが、HTML5で追加された構造用の要素は、GmailとOutlook(Windows)、Yahoo!で扱いが分かれます。

要素 Gmail(ウェブ) Gmail(iOS) Outlook(Windows) Outlook.com Apple Mail Yahoo! メモ
<table> 対応 対応 対応 対応 対応 対応 レイアウトの土台。全クライアントで使える。
<h1>〜<h6> 対応 対応 対応 対応 対応 対応 見出し。サイズや余白はインラインで指定する。
<ul>、<ol>、<dl> 部分 部分 部分 部分 対応 部分 ol の reversed 属性は使えない。通常のリストは問題ない。
main、nav、section などのHTML5要素 部分 部分 非対応 部分(timeのみ) 対応 非対応 Gmailは main と nav を扱わず、タグを u に置き換える。構造は見出しで作る。
<picture> 非対応 非対応 非対応 非対応 部分 非対応 Gmailでは picture と source が u に置き換わる。
<video> 非対応 非対応 非対応 非対応 macOSは対応、iOSは部分 非対応 動画は静止画のサムネイルにリンクを付けて外部に置く。

出典と更新日は上の表と同じです。メモの列は編集部のまとめで、caniemailの注記を言い換えたものです。

caniemailの記号の読み方

caniemailは、各機能を「対応」「部分対応」「非対応」「不明」「混在」の五つに分類しています。ここの表はそれを日本語に直したもので、「不具合あり」だけは、caniemailが注記で「Buggy」と書いている項目をまとめた独自の区分です。

表記 意味 そのときの動き方
対応 そのクライアントで、記録された条件で動作する。 使ってよい。ただし他のクライアントの列も確認する。
部分 一部の書き方、要素、アカウントでだけ動作する。 注記を読み、使う書き方が対象に入っているか確認する。
非対応 動作しない。無視される、または別の値に置き換わる。 その機能に頼らない。フォールバックを用意する。
不具合あり 解釈はされるが、結果が標準と異なる。 実機で見て、表記のゆれ(空白、大文字小文字)も確認する。
不明 caniemailにテスト結果がない。 実機で確認するまで「使える」と仮定しない。

幅を固定しないレイアウトの書き方

メディアクエリに頼らず、狭い画面でも読めるレイアウトにする典型例が次のコードです。外側のテーブルは width:100% と max-width:600px で広がりを抑え、Outlook(Windows)には条件付きコメントで幅600pxのテーブルを見せます。max-width はOutlook(Windows)でtableにのみ効くため、この形が使いやすくなります。画像は属性で寸法を書いたうえで、CSSで流動的にします。

<table role="presentation" width="100%" cellspacing="0" cellpadding="0" border="0">
  <tr>
    <td align="center">
      <!--[if mso]>
      <table role="presentation" width="600" align="center" cellspacing="0" cellpadding="0" border="0"><tr><td>
      <![endif]-->
      <table role="presentation" width="100%" style="max-width:600px;" cellspacing="0" cellpadding="0" border="0">
        <tr>
          <td style="padding:24px; font-family:Arial, sans-serif; font-size:16px; line-height:28px; color:#333333;">
            10月分のご利用明細を公開しました。
          </td>
        </tr>
      </table>
      <!--[if mso]>
      </td></tr></table>
      <![endif]-->
    </td>
  </tr>
</table>
<img src="https://example.co.jp/img/hero.jpg" width="600" height="300"
     alt="秋の新商品フェア 10月21日まで"
     style="display:block; width:100%; max-width:600px; height:auto; border:0;">

CSSをどこに書くか

書く場所によって、届く範囲が変わります。使い分けを表にしました。

書く場所 向くもの 注意
インライン(style属性) 色、文字サイズ、行間、padding、幅など、読みやすさを左右する指定 記述が増える。インライン化ツールを使うと管理しやすい。
headのstyleブロック メディアクエリ、ホバー、ダークモード用の上書き Gmailは16 KBまで。Googleアカウント以外のGmailアプリでは無効。
MJMLのmj-style(inline指定) クラスで書いた規則を、書き出し時にインライン化 inline="inline"を付けないとheadに置かれる。
Maizzleのインライン化 Tailwindのクラスをstyle属性にまとめる 既定でオン。embed属性のstyleは対象外になる。
React EmailのTailwindコンポーネント classNameで書いたクラスを変換する remを避けるためpixelBasedPresetを指定する。prose と space-* は未対応。
Juice(単体のインライナー) 既存のHTMLのstyleを、style属性にコピーする :hoverなどの疑似クラスはインライン化できず、addImportantToPseudoClassesの設定が用意されている。

クライアント別に見た症状と対策

同じ崩れでも、原因がクライアントごとに違います。症状から逆引きできるように、表にまとめました。「確認」の列は、その対策が効いたかどうかを見るための方法です。

クライアント 起こること 対策 確認
Outlook(Windows) 角丸、背景画像、Flexbox、float、メディアクエリが効かない。paddingはセルのみ。 テーブルでレイアウトし、bgcolor属性を併記。角丸ボタンと背景画像が必要な箇所だけVMLを使う。 Outlook(Windows)の実機またはプレビュー
Gmail(ウェブ) body内のstyleは無効。styleタグは16 KBまで。 styleはheadに小さくまとめ、読みやすさに関わる指定はインラインで書く。 送信後の受信メールのHTMLを開いて確認
Gmailアプリ(Google以外のアカウント) styleブロック全体、class指定、メディアクエリが無効になる。 主要な指定はすべてインライン。メディアクエリなしでも1列で読める作りにする。 Googleアカウントと、IMAPで追加したアカウントの両方で受信
Apple Mail/iPhoneのメール ほとんど何でも動く。 ここでの見た目を基準にしない。最後に確認するクライアントにする。 ダークモードも切り替えて確認
Outlook.com 入れ子のメディアクエリは削除される。ダークモードではdata-og属性が付く。 メディアクエリは入れ子にしない。ダーク用はdata-ogscとdata-ogsbの複製も用意。 ブラウザで受信し、ダークモードも確認
Samsung Email Hotmail/Outlookのアカウントでは、@mediaが無効になる(caniemailの注記)。 メディアクエリなしでも読めるレイアウトを既定にする。 Androidの実機で、Gmail以外のアカウントを追加して確認
Yahoo! @mediaはscreenと幅・高さ条件のみ。heightはmin-heightに置換される。 固定の高さに頼らず、内容に合わせて伸びるレイアウトにする。 配信リストにYahoo!のアドレスが多いときだけ重点的に確認

日本語メールで確かめたい組版まわりの項目

日本語は、欧文と違って単語の区切りがなく、行間を広く取り、縦書きや圏点といった独自の表現も使えます。caniemailは日本語専用のデータではありませんが、組版に関わるプロパティの対応は測っています。次の表は、日本語メールで関係しそうなものを抜き出したものです。

項目 Gmail(ウェブ) Gmail(iOS) Outlook(Windows) Outlook.com Apple Mail Yahoo! 使い方の目安
writing-mode(縦書き) 対応 部分 非対応 対応 対応 非対応 見出しや日付の装飾。非対応でも横書きで読める作りにする。
text-emphasis(圏点) 対応 対応 非対応 対応 対応 非対応 強調はfont-weightを基本にし、圏点は補助にとどめる。
word-break 対応(注記あり) 部分 対応 部分 部分 非対応 長いURLや英数字の折り返し。挙動が揺れるので実機で確認。
line-height 対応 対応 不具合あり 対応 対応 対応 日本語は行間を広めに取る。Outlookには mso-line-height-rule:exactly。
font-size(rem) 対応 対応 部分(remは不可) 対応 対応 部分(remは不可) 単位はpxで指定する。
font-family: system-ui 対応 対応 非対応 対応 対応 対応 先頭に置くとOS標準のUIフォントを使う。Outlook(Windows)では次の候補へ。
text-align-last 対応 対応 非対応 非対応 対応 非対応 最終行の揃えを変える用途。必須の見た目には使わない。

出典と更新日は上の表と同じです。word-breakの「注記あり」は、Gmail(ウェブ)で30文字ごとに <wbr> が挿入されるという記録です。目安の列は編集部の判断で、caniemailの結論ではありません。

この表から言えるのは、どの組版機能も「あれば効果が出る補助」であって、「なければ崩れる土台」にしてはいけない、ということです。縦書きは、使えるクライアントでは縦に、使えないクライアントでは横に表示されるだけなので、見出し一行の装飾に向いています。圏点も、使えないクライアントではただ点が付かないだけです。反対に、本文の折り返しと行間は全員に影響するので、基本の指定をインラインで確実に書いてください。

<p style="margin:0; font-size:20px; line-height:32px; writing-mode:vertical-rl; -webkit-writing-mode:vertical-rl; height:160px;">
  秋の特別セール
</p>

フォントについては、caniemailの@font-faceのページが示すとおり、Webフォントを読み込めるのはApple Mailなど一部です。GmailとOutlook.comは非対応で、Outlook(Windows)は宣言だけ受け付けて外部フォントを無視します。日本語のWebフォントはファイルも大きいため、メールではシステムフォントのスタックを書くのが現実的です。次のスタックは一例で、フォント名が各環境に入っているかは保証されないため、末尾に総称の sans-serif を置き、サイズはpx、行間は mso-line-height-rule:exactly 付きで指定します。

font-family: system-ui, "Hiragino Sans", "Hiragino Kaku Gothic ProN", Meiryo, "Yu Gothic", sans-serif;
font-size: 16px;
line-height: 28px;
mso-line-height-rule: exactly;

W3CはHTMLでの言語宣言について、html 要素に言語属性を付けることを勧めています。メールでは、クライアントがラッパーを取り除くことがあるため、body にも同じ指定を重ねておくと安全です。ja か ja-JP かについては、言語タグの選び方のページが、日本語に地域サブタグを付けても区別の役に立たないと説明しています。

<html lang="ja" dir="ltr">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>10月分のご利用明細のお知らせ</title>
</head>
<body lang="ja">

画像とメディアクエリ

画像の形式は、PNGとJPEGが全クライアントで対応です。GIFは、Outlook(Windows)でアニメーションが動かないため、最初のコマだけで意味が通じるように作ります。WebPはOutlook(Windows)が非対応で、Gmailは部分対応です。SVGは、Gmailが表示するもののPNGに変換されます。画像の中に日付や金額を書き込むと、画像オフのときに情報が失われるため、必要な情報は本文のテキストにも置いてください。

メディアクエリは、Gmailが高さ基準の条件を受け付けず、Yahoo!が screen、min-width、max-width とそれぞれの高さ版に限られ、Outlook(Windows)は一切解釈しません。スマートフォンで読める細い幅を既定にして、メディアクエリは「広い画面でさらに整える」ために使うのが基本です。詳しい書き方はメールのCSSガイドにまとめています。

確認の進め方

  1. 配信リストの上位クライアントを調べる。配信サービスの管理画面にあるクライアント別の開封データを見て、上位三つから確認します。
  2. グループごとに一つずつ実機で見る。Outlook(Windows)、Gmailアプリ(Googleアカウントとそれ以外のアカウントの両方)、iPhoneのメールの三つを最低限そろえます。
  3. 画像オフで読む。日付、金額、ボタンのラベルが本文のテキストでも読めるか確認します。
  4. 配信サービス経由で確認する。Litmusの解説によると、配信サービスはトラッキングピクセルの追加やリンクの書き換えを行い、コードの一部を取り除くことがあるので、本番と同じ経路で送ったメールを確認します。
  5. ダークモードも見る。配色の扱いはダークモード対応のガイドを参照してください。

最低限そろえる確認環境と、それぞれで見るポイントを表にまとめます。

環境 見るポイント 理由
Outlook(Windows) 角丸のボタン、背景画像、2列レイアウト、行間 非対応の列が最も多い
Gmail(ウェブ、Googleアカウント) styleの16 KB上限、head内にstyleがあること body内のstyleは無効
Gmailアプリ(Google以外のアカウント) インラインだけで1列に読めるか styleブロックとメディアクエリが無効になる
iPhoneのメール メディアクエリでの2列から1列への切り替え、ダークモード ほとんどの機能が効く基準環境
Outlook.com(ブラウザ) 入れ子のメディアクエリ、ダークモードの属性 入れ子は削除、ダークではdata-og属性が付く
Yahoo!(配信リストに多い場合) 固定の高さ、@media の条件 heightはmin-heightに置換、@mediaは条件が限られる

テンプレートの確認リスト

ここまでの内容を、テンプレートを受け入れるときの確認リストにまとめます。項目ごとに、書き方と理由が対応しています。

項目 書き方 理由
言語の宣言 html と body に lang="ja" を書く W3Cは html 要素への指定を勧める。クライアントがラッパーを外す場合に備えて body にも書く。
レイアウト table に role="presentation"、cellspacing="0" cellpadding="0" border="0" レイアウト用のテーブルを読み上げ時にデータ表と区別させる。
幅 width="100%" と max-width:600px。Outlook(Windows)向けに条件付きコメントの固定幅テーブル max-width はOutlook(Windows)で table にだけ効く。
余白 padding は td に書く。段落の margin は 0 を明示 paddingはOutlook(Windows)ではセルのみ。marginは多くのクライアントで部分対応。
文字 font-size は px、line-height は px、mso-line-height-rule:exactly remはOutlook(Windows)とYahoo!で使えない。
色 6桁の16進数。rgb( / ) の空白区切りと oklch() は使わない Gmailでstyle属性やstyleブロックが取り除かれるため。
背景画像 bgcolor を併記し、必要な箇所だけVML 画像が読まれなくても文字が読める。Outlook(Windows)は background-image 非対応。
画像 width と height の属性、display:block、alt を必ず書く Outlook(Windows)はCSSの width を img で無視する。画像オフでも alt が残る。
style ブロック head に置き、16 KB未満にする。メディアクエリとホバーだけを入れる Gmailは body 内の style と16 KB超を扱わない。
リンク href は絶対URL。トラッキングで書き換えられても飛び先が正しいか確認 Litmusによると、配信サービスはリンクを書き換えることがある。
配信停止リンク 本文のテキストリンクとして置く。画像だけのリンクにしない 画像オフでも見つけられ、スクリーンリーダーでも読み上げられる。
テキスト版 HTMLと同じ内容のテキスト版を用意する(React Emailは toPlainText で生成) HTMLを表示しない設定の受信者にも届く。
最小の確認 Outlook(Windows)、Gmailアプリ、iPhoneのメール、画像オフ、ダークモード 三つのグループと、読めなくなる二つの状態を一度に見る。

ツールの選び方

互換性の課題をツールに任せる方法は三つあります。MJMLは、mj-section や mj-column のようなタグで書くと、表組みのHTMLにコンパイルします。ドキュメントには、mj-style に inline="inline" を付けるとスタイルをインライン化できること、lang と dir を mjml タグに指定できることが書かれています。React Emailは、Reactのコンポーネントで書いたメールをHTMLの文字列に変換し、Html コンポーネントで lang を指定します。Maizzleは、書き出し時にCSSのインライン化を既定で行います。どれも、すべてのクライアントでの同一表示を約束するものではなく、書き出し後の確認は残ります。ドキュメントが互換性について述べていることを表にまとめます。

ツール ドキュメントの記載 参照先
MJML section と column で書くと表組みのHTMLにコンパイル。mj-style の inline="inline" でインライン化。lang と dir を mjml タグに指定。 https://documentation.mjml.io/
React Email Html コンポーネントで lang と dir を指定。Tailwind コンポーネントは rem を避けるため pixelBasedPreset の利用を案内。 https://react.email/docs/components/html
Maizzle CSSのインライン化が既定でオン。「GmailとWindowsのOutlookはstyleタグの対応が限られる」ためと説明。embed 属性のstyleは対象外。 https://maizzle.com/docs/transformers/inline-css

2つのコードベースのフレームワークの比較はMJMLとReact Emailの比較、視覚的に作るビルダーを探す場合はHTMLメールビルダーのガイドが出発点になります。

よくある質問

日本のユーザーが多い場合、何から確認すればよいですか。

まず配信リストの上位クライアントを確認してください。caniemailは世界共通のデータで、日本のキャリアメールやYahoo!メール(日本)を個別の項目として測っているわけではありません。そのため、Outlook(Windows)、Gmailのウェブとアプリ(Googleアカウントと、それ以外のアカウントの両方)、iPhoneのメールを基準に作り、リストに多いドメインのアドレスには実機でテストメールを送るのが確実です。

縦書きは使ってよいのでしょうか。

caniemailのwriting-modeのページでは、Gmail(ウェブ)、Outlook.com、Apple Mailで対応、Outlook(Windows)とYahoo!で非対応、GmailアプリはGoogle以外のアカウントで非対応と記録されています。非対応のクライアントでは単に横書きで表示されるので、読めなくなるわけではありません。ただし、縦書き前提でレイアウトを組むと崩れるため、見出し一行などの装飾にとどめてください。

lang="ja" と lang="ja-JP" のどちらを書くべきですか。

W3Cの言語タグの選び方では、言語タグはできるだけ短くし、地域などのサブタグは区別に必要なときだけ加えるとされています。同じ文書の中で、日本語を日本以外の地域の日本語と区別する場面はまずないので、lang="ja" で足ります。caniemailのlang属性のページでは、Yahoo!とAOLで td 要素には効かないという注記があるため、html、body、p、span などに付けてください。

メールビルダーを使えば互換性は気にしなくてよいですか。

いいえ。ビルダーやフレームワークは書き出すHTMLの質を上げますが、配信するクライアントごとの差は残ります。Litmusも、配信サービスがメールのコードを書き換えることがある(トラッキングピクセルの追加、リンクの書き換え、一部のコードの削除)と指摘しています。ツールを選んだあとも、書き出したHTMLを実際のクライアントで確認する作業は省けません。