Figma
Emailify以外で作成したFigmaのメールデザインには対応していません
本番用のHTMLをエクスポートする前に、Emailifyのデザインツールでメールのレイアウトを作成してください。これらのツールは、EmailifyがHTMLを生成するために必要なRow、Column、Buttonなどの構造化されたレイヤーを追加します。追加したあとで、コンテンツやスタイルをカスタマイズできます。
Emailifyプラグインを使わずにFigmaでデザインしたレイヤーやフレームを追加すると、リッチテキストやHTMLのコンテンツではなく、静止画像としてレンダリングされます。
画像形式の上書き設定
Emailifyは、レイヤーに完全に透明な領域が含まれているかを自動で検出し、含まれている場合はデフォルトのエクスポート形式をPNGに、それ以外の場合はJPGに設定します。独自のエクスポート設定を追加すれば、任意のレイヤーのエクスポート形式をJPGまたはPNGに上書きできます。
Figmaの「Scroll Wheel」や「Drag to Pan」の設定を有効にするとフリーズする問題
これらの設定（下のスクリーンショットを参照）を有効にしていると、プラグインやキャンバスがまれに不自然にフリーズすることがあります。
Figmaファイルでこの現象が起きている場合は、Figmaでこれらの設定を無効にすると解決できます。Main Figma MenuからPreferencesに進み、Use scroll wheel zoomとRight-click and drag to panの設定のチェックを外してください。
通常のFigmaテキストレイヤーの段落やコンテンツにリンクを追加する
Figmaのテキストレイヤーでリンクを設定したいテキストを選択し、FigmaのヘッダーツールバーにあるFigma標準の「Link」アイコンボタンをクリックすると、URLを貼り付けられます。貼り付けたリンクは、Emailifyが自動でレンダリングします。
この方法はコンテンツのテキストレイヤーにのみ使用してください（ボタンやナビゲーションリンクには使えません）。この方法が使えるのは通常のコンテンツのテキストレイヤーだけです。Emailifyが生成するボタン、ソーシャルアイコン、ナビゲーションリンクのレイヤーにリンクを設定する場合は、そのFigmaレイヤーをクリックし、EmailifyプラグインのヘッダーにあるSettingsボタンをクリックしてから、リンク欄にURLを貼り付けてください。
ボタンやリンクのラベルがFigmaでは見えるのに、プレビューやエクスポートで表示されない
Figmaではテキストが見えているのに、ボタンが空になったりナビゲーションリンクが消えたりする場合、可変フォントを含む混在したフォントデータによるエクスポートの問題が原因の可能性があります。リンクのURLが正しくても、そのラベルがエクスポートされているとは限りません。
ラベルは、元のEmailifyのButtonまたはナビゲーションコンポーネント内で、編集可能なテキストのままにしておいてください。Emailifyを閉じて開き直し、プレビューを更新してから、もう一度エクスポートします。メール配信プラットフォームにアップロードする前に、ダウンロードしたHTMLを確認してください。
それでもラベルが表示されない場合は、問題が起きているFigmaのメールフレームと、エクスポートしたHTMLまたはZIPを添えてサポートにお問い合わせください。テキストレイヤーを調べて問題を再現します。
上付き文字・下付き文字を追加する
Figmaのテキストレイヤーに上付き文字や下付き文字を追加すると、プラグインからのHTMLエクスポートで、自動的に上付き文字（例：sup）や下付き文字（例：sub）のタグとしてレンダリングされます。
HTMLテキストで見出しタグ（h1、h2、h3など）を使う
必要に応じて、デフォルトの段落タグ（p）を任意の見出しタグ（例：h1、h2）に置き換えられます。Figmaのテキストレイヤーのコンテンツを使いたい見出しタグで囲むと、Emailifyプラグインでエクスポートする際に、タグが自動で変更されます。
WindowsのFigmaデスクトップアプリでファイルの拡張子が空になる
Figmaデスクトップアプリ（Windowsのみ）には既知の問題があり、Figmaからの通常のファイルエクスポートでも同じ現象が起こります。ファイルを保存しようとすると、「all files」というラベルが表示されることがあります。これを気にせず「Save」をクリックして続ければ、通常は正しい拡張子でファイルが保存され、パソコンにダウンロードされたあとも問題なく開けます。それでも拡張子が空のまま保存される場合は、ファイル名を変更して、正しい拡張子を手動で付け加えてください。
デザインを最適化してHTMLエクスポートのサイズを減らす
エクスポートされるHTMLのサイズに最も大きく影響するのはRowコンポーネントの数です。Rowごとにテーブル要素が1セット追加されるためです。コンテンツが同じ構造に収まる場合は、Rowを使い回してください。
たとえば、見出し、小見出し、本文、ボタンは、1つのRow内の1つのColumnにまとめられます。Rowレイヤーを4つに分ける必要はありません。
Emailifyのレイヤーをクリックしても、Emailifyの設定パネルの項目が表示されない
FigmaのデザインでEmailifyのレイヤーをクリックし、プラグインのヘッダーにあるSettingsボタンをクリックしても設定が表示されない場合は、Emailifyのメインフレームがほかのフレームやグループなどの中にネストされている可能性があります。解決するには、Emailifyのフレームをネストされたフレームやレイヤーの外に出し、ほかのレイヤーの中に入らないよう「Page」のレベルに戻してください。
HTMLメールの送信時にUTMクエリパラメーターが削除される
HTMLメールを送信したときにUTMクエリ文字列パラメーターが削除される理由はいくつかあります。ここ1年ほどで、（プライバシー保護のために）これらを自動で削除するブラウザやデバイスが増えてきました。Emailifyのプレビューウィンドウからリンクを開いたときはクエリ文字列が機能するのに、メールマーケティングプラットフォームから送信したあとは機能しない場合、送信時にリンクの転送・短縮が追加で適用されていて、それがパラメーターを削除したり壊したりしている可能性が高いです。
「Please wait, loading Figma images...」の表示に時間がかかる
少し前のFigmaのアップデートにより、すべてのFigmaプラグインは、画像データをエクスポートする前に、現在のFigmaページにあるすべてのフル解像度画像の読み込み完了を待たなければならなくなりました（必要なのが1つのレイヤーや画像だけであっても同様です）。
現時点での唯一の解決策は、現在のFigmaページにあるフレームやレイヤーの数をできるだけ減らすことです。そうすれば、プラグインの初回実行時のこの処理がずっと速くなります。たとえば、現在のFigmaファイルに新しいページを作成し、作業やエクスポートをしたいEmailifyのフレームだけをその空のページに移動してから、そこでプラグインを再実行すると、読み込みがはるかに速くなります。
エクスポートした画像が粗くなる
Figma内の画像アセットがまだ段階的に読み込まれている途中でメールをエクスポートすると、エクスポート前に画像がFigmaファイルで完全に読み込まれていないため、粗い画像としてエクスポートされることがあります。解決するには、Emailifyプラグインでメールをエクスポートする前に、Figmaファイル内のすべての画像が100%読み込まれ、鮮明に表示されていることを確認してください。
さらに対策として、TinyImageの「Downsizer」機能を使い、画像塗りをレイヤーのサイズに合わせて縮小することもできます。これにより画像のファイルサイズが小さくなり、Figmaファイルでの読み込みがずっと速くなります。
Adobe AcrobatでPDFを編集すると点線が表示される
PDFの編集中に、Acrobatアプリのサイドバーにある「Show bounding boxes」のトグルをオフにすると解決できます。アプリでPDFを開いて「Edit」モードに入ると、点線のバウンディングボックスが表示されるのはAdobeのデフォルト設定ですが、「Show bounding boxes」のトグルをオフにすれば、ワンクリックで非表示にできます。
中国ではVPNが必要な場合がある
中国からご利用の場合、アカウントサーバーが「グレート・ファイアウォール」によってブロックされている可能性があります。有効なキーを使っているのに有効化エラーが表示される場合は、問題を解決するためにVPNの利用が必要になる可能性が高いです。
「An error occurred while loading the plugin environment」と表示される
この問題は、FigmaデスクトップアプリでUse Developer VMのデバッグ設定が誤って有効になっている場合に起こることがあります。オフになっているかを確認するには、Figmaキャンバス上の任意の場所を右クリックし、Plugins、Developmentの順にカーソルを合わせて、Use Developer VMのチェックが外れていることを確認します。チェックが外れた状態（横にチェックマークが付いていない状態）になれば、Figmaプラグインを再実行すると正常に動作するはずです。
ネットワークで画像のアップロードがブロックされる
Upload Hosted Image URLs機能を有効にした場合や、Emailifyに組み込まれたエクスポートオプションでHTMLメールをいずれかのメール配信プラットフォームにアップロードした場合、プラグインは画像を自動でオンラインにアップロードしてホスティングします。
プラグインに警告メッセージ（Images uploads may be blocked on your current network）が表示される場合は、画像をオンラインでホスティングするために必要なアップロードサービスに、プラグインがアクセスできていないことを意味します。
これは通常、接続しているネットワーク（たとえば、特定のURLをファイアウォールでブロックしている会社のネットワーク）やISP（インターネットサービスプロバイダー）が、URLを制限またはブロックしていることが原因です。トラブルシューティングの手順は次のとおりです。
- スマートフォンをWi-Fiホットスポットとしてパソコンにテザリング接続し、Emailify Figmaプラグインを再実行して、問題が解決するかを確認してください。解決した場合は、元のネットワークがリクエストをブロックしていたことになります。
- VPNを使ってみることもできます。VPNはネットワークリクエストをトンネリングするため、ネットワークによるブロックを回避できるはずです。
- すでにVPNを使っている場合は、VPNをオフにしてから、Emailify Figmaプラグインを再実行して、問題が解決するかを確認してください。
それでも問題が解決しない場合は、お気軽にメールでお問い合わせください。
メールクライアント
新しいOutlookでは、メールの読み込み後にスタイルが書き換えられることがある
Windows版の新しいOutlookには、メールが最初は正しく表示されるものの、読み込み後に表示が変わってしまうという後処理の問題が報告されています。Outlookはこの2回目のレンダリングの段階でメールのCSSの一部を書き換えているようで、デスクトップのカラムが予期せず縦に並んでしまうなどの問題が起こることがあります。
この挙動は一定ではありません。1人の受信者だけが影響を受け、ほかの全員には想定どおりのレイアウトが表示されることもあれば、同じメールボックスでも、同一のテスト送信の表示が異なることもあります。Customer.ioは、これらの症状と現時点での調査結果をNew Outlook, same headacheにまとめています。
Emailifyの新しいエクスポートには、既知のカラムが縦に並んでしまうケースに備えた防御的な互換レイヤーが含まれています。EmailifyはMJML本来のレスポンシブスタイルと従来のOutlook向けのテーブルによるフォールバックを維持したうえで、生成したデスクトップのカラム幅のルールだけを複製し、メール本文内に配置します。これにより、メールのheadからスタイルを削除するWeb版のOutlookに対応しつつ、ほかのクライアントではMJML本来のモバイルでの縦積みとブレークポイントの挙動を維持できます。
デザインを作り直す必要はありません。次のテストを送信する前に、Emailifyを更新してメールを再エクスポートし、生成されたHTMLにこのフォールバックが含まれるようにしてください。
この問題が起きた場合は、次の方法をお試しください。
- 問題のあるメールを、Outlookの閲覧ウィンドウやプレビューウィンドウではなく、別ウィンドウで開きます。報告されたケースでは、別ウィンドウだと正しく表示されることが多いです。
- エクスポートした同じHTMLを別の受信者やメールクライアントに送信し、問題が1人のOutlookユーザーだけに起きているかを確認します。
- 同一の送信で表示が異なる場合は、Emailifyのデザインやエクスポートを変更する前に、受信した両方のメッセージを
.emlファイルとしてダウンロードし、HTMLを比較します。
このフォールバックにより、報告されているデスクトップでカラムが縦に並んでしまう問題は軽減されますが、配信後に行われるすべてのスタイルの書き換えをEmailifyで制御することはできません。問題が続き、受信したHTMLに変化がない場合は、一貫しないOutlookのプレビュー1件のためだけに、デザインを大きく変更することは避けてください。
HTMLメールテンプレートを転送すると表示が崩れる
残念ながら、受信したカスタムHTMLメールを誰かが別の人に転送すると、転送先でメールの見た目が崩れてしまうことがよくあります。
これは、メールが転送される際に、メールクライアントによってHTMLコードの一部が変更（または削除）され、表示が崩れるためです。Litmusの記事When Forwarded Emails Breakでは、次のように説明されています。
メールの表示がメールクライアントごとに異なることはよく知られています。購読者がメールを転送すると、一部のメールクライアントは転送するメッセージのコードに変更を加えます。たとえば、特定のHTML要素を削除したり、メールをblockquoteで囲んだり、コードにクラスを追加したりします。これらはいずれもデザインを崩し、転送先の受信者にとってメールの使い勝手を損なう原因になります。
この影響を抑えるよくある方法の1つは、正しく表示されない場合にブラウザで開ける「Webリンク」版を用意することです。通常はメールの上部のどこかに追加します（MailChimpのこちらの例のように）。必要であれば、共有用のリンクとしてメール内のどこかに設置することもできます。
メールが迷惑メールに振り分けられる原因は？
メールが迷惑メールに振り分けられる主な原因には、次のようなものがあります。
- リンクが多すぎる：リンクはすべて到達率に影響します。不要なソーシャルメディアのリンクなど、必須ではないリンクを削除すると、受信トレイに届きやすくなります。
- 送信者の評価が低い：ドメインやIPに、エンゲージメントの低さ、バウンス、苦情の履歴があると、メールボックスプロバイダーにメールが迷惑メールと判定されることがあります。
- 迷惑メールらしいコンテンツ：宣伝的な言葉（例：「Free!」「Act now!」「Limited time offer」）の使いすぎや、画像が多くテキストが少なすぎるメールは、フィルターに引っかかることがあります。
- 認証の問題：送信ドメインにSPF、DKIM、DMARCが正しく設定されていることを確認してください。
- エンゲージメントが低い：購読者がメールを開かない、クリックしない状態が続くと、今後のメールが迷惑メールと判定されやすくなります。
- リストの質：古いリストや購入したリストに送信すると、バウンスや迷惑メールの報告が発生し、送信者スコアが下がることがあります。
まずはメールをシンプルにし、ドメイン認証を確認し、不要なリンクを減らすことから始めてください。それだけで到達率が改善することがよくあります。
ダークモードの上書き設定に対応しているのはiOS・MacのApple Mailアプリのみ
現時点では、メールクライアントにおけるダークモードの上書きスタイルへの対応はまだ比較的少ないため、この点に注意し、ダークモードの上書き設定を「プログレッシブエンハンスメント」として考えてメールをデザインしてください。
ほかのメールクライアント向けのフォールバックとして、ダークモードを考慮してメールを作成するためのほかの工夫されたデザイン手法を取り入れるのもおすすめです。
Gmailでボタンの白い文字を維持する回避策の目的はもっと限定的で、ボタンの純白のテキストを維持するためのものです。Gmailのダークモードで、淡い背景の上の黒いテキストをそのまま維持する方法ではありません。
モバイルで縦に並べた画像の間に細い白のサブピクセルの線が出る
これは、幅いっぱいのインライン画像を使っている場合に起こることがあります。デバイスの幅によっては、モバイルで画像が縮小されるときに画像の高さに「サブピクセル」が入り込み、画像同士の間にかすかな隙間ができて、背後の背景が透けて見えてしまうためです。
最も手早い回避策は、それらの画像を含む「Row」レイヤーの周りにWrapperレイヤーを追加し、そのWrapperの背景を、グラデーションの両端に背景色（例：グレー）を指定した「Linear Gradient」に設定することです。こうすると背景が画像としてレンダリングされるため、ダークモードでCSSの背景色が置き換えられたり黒に反転されたりするのを防げます。また、画像のRowの背後に一貫した背景ができるため、サブピクセルの隙間を覆い隠せます。
Googleフォント・カスタムフォントの埋め込みに対応しているのはiOS・macOSのApple Mailアプリのみ
現時点で、メールクライアントでのカスタムフォントは、iOS・macOS版のApple Mailでしか対応していません。そのため、FigmaのテキストレイヤーにはWebセーフフォントを使うことをおすすめします。Webセーフフォントは、Emailifyの「Preview」機能にあるConfigure Fontsパネルで設定できます。
また、一部のメール配信サービス（MailChimpなど）は、Webセーフフォントだけが使われるように、メールの送信前にカスタムフォントを積極的に削除します。
ただし、EmailifyはGoogleフォントの@importを引き続き含めており、リッチテキストでGoogleフォントを使っている場合は、Webセーフな代替フォント（例：「Arial」「Georgia」「Courier」）も設定します。これらのフォントは、メールでの@font-faceの使用に対応しているメールクライアントであれば表示されます。
画像内でカスタムフォントを使う。すべてのメールクライアントでカスタムフォントの見た目を統一する必要がある場合は、テキストレイヤーを「Image」フレームの中に入れるのもよい方法です。このテキストコンテンツは画像の一部としてエクスポートされるため、カスタムWebフォントへの対応に関係なく正しく表示されます。
メール内のフォーム要素には対応していません
HTMLメールでのform要素への対応はまだかなり少なく、フォームを含めるとメールが迷惑メールと判定されるなどの原因にもなるため、現時点ではHTMLメール内でネイティブのフォームを使うのは避けたほうがよいでしょう。
最善の回避策は、Emailifyのデザインで見栄えのよいコールトゥアクション（CTA）ボタンを作成し、Google FormsやTypeformなどの外部フォームのURLにリンクして、受信者からの情報はブラウザ上で収集することです。
一部のクライアントでの画像ブロックの仕組み
画像ブロックとは何か、どのメールクライアントがデフォルトで画像ブロックを有効にしているか（主にOutlook）を解説した、とても参考になる記事を以下に紹介します。一方、Gmail、Android、Apple・iOSなどのほかのクライアントは、すべてデフォルトで画像を表示します。
How Image Blocking Works in Email
Email Image Blocking: Answering the What, Why, Where, Who, and How
残念ながら、画像が安全（SSL）かどうかとは関係なく、メール内のすべての画像が一律にブロックされます。
良い点としては、前者のメールクライアントを使っている受信者は、通常この挙動に慣れていて「show images」ボタンをクリックするか、受信メールの画像をデフォルトで表示する設定をすでに有効にしていることが多いということです。
Gmailでテキストが紫色になる（同じ件名で複数回テスト送信した場合）
Gmailアカウントにメールのテストを複数回送信すると、一部のテキストが濃い紫色になっていることに気づくかもしれません。
これはHTMLコードの問題ではありません。同じ日に同じ件名で送信された複数のメールを、Gmailが互いへの返信だと判断した場合に起こります。この場合、Gmailはメールのスレッドを「スレッド表示（conversation view）」で表示します。
Gmailのスレッド表示について詳しくは、Googleのドキュメントをご覧ください。
紫色の表示は、それを見ている画面上にだけ存在する表示専用の機能です。メッセージと一緒に送信されることはなく、Gmailの「メッセージのソースを表示」機能で確認できます。ただし、HTMLコーディングについて少し知識が必要です。
色は、現在のスレッド内の以前のメッセージから繰り返されているテキストに適用されます。受信者にも見えるのは、受信者もGmailを使っていて、現在のスレッドの以前のメッセージのコピーを持っているためです。受信者のスレッドで色が付く部分は、あなたのスレッドで色が付く部分とはかなり異なる場合があります。
メールクライアントが日付、電話番号、住所に青いリンクを付ける
これは以前からある問題で、一部のメールクライアントは日付、電話番号、住所などに自動でリンクを付け、さらに独自の色のスタイルを適用します（通常は青いリンクです）。
Emailifyは、一部のメールクライアントでこの問題を軽減するために、推奨されているコードの修正をすべて自動で適用しています。ただし、クライアント側が頻繁に更新され、これらの修正が回避されたり、適用されなくなったりすることがあります。
メールクライアントが自動でリンクを追加するのを防ぐために試せる追加の方法が2つあります（どちらも上記の記事で紹介されています）。
方法1は、Figmaの該当するテキストレイヤーそれぞれに、あらかじめプレースホルダーのリンク（例：自社のWebサイト）を設定しておき、Figmaで下線のスタイルを外して、好きな色に設定する方法です（クリックできるようには見えなくなります）。これにより日付のテキストの周りにあらかじめリンクタグが付くため、メールクライアントが独自のスタイルなしのリンクを自動で付けようとしなくなります。
方法2は、日付、電話番号、住所の最初の1文字の直後に、特殊な不可視のHTMLエンティティ（‌）を追加する方法です（例：6‌75 Massachusetts Ave, Cambridge, MA 02139）。これにより、メールクライアントが日付ではないと判断し、日付のリンクを自動で付けなくなることが期待できます。
一部のVPNでは、アップロードした画像が表示されないことがある
Upload Hosted Image URLs機能を有効にした場合や、Emailifyに組み込まれたエクスポートオプションでHTMLメールをいずれかのメール配信プラットフォームにアップロードした場合、ごくまれに、一部のVPNが割り当てる特定のIPアドレスが画像ホストにブロックされ、画像が読み込まれないことがあります。
画像が読み込まれない問題が起きている場合は、これが原因の可能性が高いです（ご自身で確認するには、一時的にVPNをオフにしてください）。
メール署名ではカスタムフォントを使えません
通常のHTMLメールでは、カスタムフォントを埋め込むことができます（ただし、対応しているのはApple Mailのみで、GmailやOutlookなどのほかのクライアントは、どのような形のカスタムフォントの埋め込みにも対応していません）。一方、メール署名では、フォントの埋め込みコードを追加するためのstyleタグを使うこと自体ができないため、署名はWebセーフなシステムフォントを使ってデザインしてください。
GmailのiOSアプリでモバイル向けのレスポンシブスタイルが反映されない
主な原因は、@mediaクエリ内のCSSプロパティやスタイルにタイプミスがある場合（例：padding-bottomではなくpadding-bottm）や、スタイルプロパティの途中に改行がある場合（例：padd 改行 ing-top）です。この場合、Gmailアプリはほかのすべてのスタイルを無視し、モバイル向けのレスポンシブな上書き設定を一切反映しません。
プラグインから通常どおりエクスポートしたコードではこの問題は起こらないはずですが、EmailifyからエクスポートしたあとにHTMLコードを手動で編集した場合（またはメールマーケティングプラットフォームがコードを変更したり、行の長さの制限を追加したりしている場合）に起こることがあります。
HTMLメールの1行あたり500文字の制限
Emailifyは、エクスポートするHTMLを1行あたり500文字に制限しています。正式な制限は998文字ですが、行を短くすることで、Outlookや一部のメール配信サービスで見られるレンダリングや配信の問題を防げます。
VPNが原因で、一部のソーシャルメディアのリンクが正しく開かないことがある
まれなケースのようですが、一部のソーシャルネットワーク（例：Facebook、Instagram）へのリンクが正しく開かない場合は、これが原因の可能性が高く（ご自身で確認するには、一時的にVPNをオフにしてください）、HTMLメールやリンク自体の問題ではありません。
Outlook
Outlookで角丸（border-radius）が表示されない
残念ながら、Outlookはborder-radiusプロパティに対応していないため、常に通常の四角い角で表示されます。どのメールクライアントがこのCSSプロパティに対応しているかは、border-radiusの対応状況一覧をご覧ください。
Outlook.comでボタンの高さが縮む（実際のURLが設定されていないため）
ボタンコンポーネントの高さが中のテキストレイヤーのサイズまで縮んでしまう場合、これはhrefに実際のURLが設定されていない（例：実際のURL（https://google.com）ではなく[replaceLinkInHere]になっている）ときにOutlook.comが起こす現象です。Figmaでボタンレイヤーをクリックし、プラグインのSettingsボタンを使ってURLを貼り付け、ボタンコンポーネントに実際のURLを設定してください。
一部のOutlookのバージョンで、「逆順」のRowに1pxの白い線が出る
一部のバージョンのOutlookには、カラムの逆順設定を使うと、いずれかのカラムの横に1pxの白い線が表示されることがあるという既知のバグがあります。これはMicrosoft Wordのレンダリングエンジンに起因するOutlookのレンダリングの癖の1つで、逆順にしたRowにパディングも適用されている場合に起こることがあります。
最善の回避策は、逆順にしたRowレイヤーからパディングを削除し、そのRowをWrapperで囲んで、パディングを外側のWrapperに移すことです。こうすると見た目の余白は変わらず、逆順にしたRow自体で起こるOutlookのレンダリングのバグを回避できます。
この回避策は、関連するMJMLのGitHub issueで議論されている方法と同じです。
Outlookが日付や時刻を自動で青いカレンダーリンクにする
Outlookがテキストを日付や時刻として解析し、自動でリンクとしてレンダリングするのを防ぐには、曜日、日付、時刻の間に「ゼロ幅スペース」のHTMLエンティティ（​）を挿入して、Outlookのパターンマッチングを崩します。動作を確認済みの例は次のとおりです：Monday​ — Friday 8​am to 5​pm
アクセント記号（ダイアクリティカルマーク）付きの大文字が切れてしまう
「大文字」のテキストレイヤーで、一部の文字にダイアクリティカルマーク（例：Ä、Ö、Ü）が含まれていて、Outlookで上部のアクセント記号が表示されない場合、その原因はFigmaのテキストレイヤーの「行の高さ」の値が、テキストの「フォントサイズ」の値より小さいことです。Outlookは、行の高さの範囲に収まらないコンテンツを基本的に切り取ってしまいます（ほかのクライアントでは、通常どおりはみ出して表示されます）。
解決するには、行の高さの値をフォントサイズより少し大きくするだけです。たとえば、フォントサイズが「24px」のテキストレイヤーで行の高さが現在「23px」の場合は、Figmaで行の高さを「23px」から「28px」に増やします（24pxの大文字の高さより上に出るアクセント記号のために、十分な余裕を持たせるためです）。これで、行の高さが低いためにアクセント記号やダイアクリティカルマークが切れることなく、Outlookで想定どおりにレンダリングされます。
Outlookで不規則に発生する「1pxの線」のバグ
一部のバージョンのOutlookでは、Outlookの1pxの線のバグとして知られる、非常に厄介な問題が不規則に発生します。
Outlookはメールに余分な線を追加します。これらの線はbodyタグに設定した背景を引き継ぎます。さらに厄介なことに、このバグは不規則に発生するようですが、Windows 7よりもWindows 10のマシンでより頻繁に見られます。
上記の記事でも触れられているとおり、この問題は不規則に発生し、確実な修正方法はありません。ただし、線が表示される箇所の上にあるテキストコンテンツのフォントサイズを、試行錯誤しながら調整するとたいていは解決できます。たとえば（記事より）：
人によっては、フォントサイズを奇数から偶数に変えるだけで解決します。たとえば、フォントサイズが13pxや15pxの場合は、14pxに変えてみてください。
Fixing White Lines in Outlookという別のわかりやすい解説記事でも、さらに詳しい情報と考えられる修正方法が紹介されています。
さらに詳しく知りたい場合は、Outlook 2016 madness and the weird 1px thin horizontal linesの記事で根本的な問題がより詳しく解説されているほか、詳細なLitmusフォーラムでのディスカッションでも、考えられる原因やトラブルシューティングの方法が検討されています。
Gmail
Gmailでメールが途中で切れる
Gmailは、メッセージサイズが102KBを超えるメールを途中で切り、全文を「View entire message」リンクの後ろに隠します。これを避けるには、エクスポート前にPreviewボタンでHTMLファイルのサイズを確認し、できるだけコンテンツを減らしてファイルサイズを小さくしてください。
HTMLファイルのサイズが制限を下回っているのにメールが切れる場合は、メールのコンテンツにUTF-8文字が使われていることが最も考えられる原因です。UTF-8文字もGmailがメールを切る原因になります。最善の解決策は、UTF-8文字をHTMLエンコードした形に置き換えることで（例：©の代わりに©を使う）、プラグインはこれを自動で適用しています。
もう1つの原因は、同じ件名でメールを送信している場合です（例：自分宛てにテストを複数回送信する場合）。Gmailはメールを1つのスレッドにまとめ、2回目以降に送信したメールの内容を切ってしまうことがあります。これを回避するには、件名を毎回変えるようにしてください（例：「Test v1」「Test v2」など）。
Gmailモバイルアプリのダークモードで、ボタンの白い文字が黒くなる
Gmail（およびその他のアプリ）は、ユーザーのシステムテーマがダークモードに設定されていると、ボタンを含め、メールにダークモードのスタイルを自動で適用します。
ライトモードとダークモードのどちらでも白い文字にしたいボタンの場合：
- Figmaで、ボタンのテキストレイヤーを純白（
#FFFFFF）に設定します。 - Buttonコンポーネントを選択してSettingsを開き、ダークモードの上書き用テキストカラーも純白（
#FFFFFF）に設定します。 - メールを再エクスポートし、問題が起きたGmailモバイルアプリにテストを送信します。
両方の色を純白に設定すると、Emailifyはボタンの白い文字を維持するための互換コードを追加します。この回避策では、黒やその他の白以外の文字は維持されず、ボタンの背景色も固定されません。デザインで淡い背景の上に黒い文字が必要な場合は、意図した色のままにして、そのデザインを別途テストしてください。文字を白に変えると、その要件を満たすのではなく、デザイン自体が変わってしまいます。
それでもデザインどおりに表示されない場合は、エクスポートしたHTMLまたはZIP、スクリーンショット、メールアプリとデバイス、維持したい文字色と背景色を添えて、サポートにお問い合わせください。すでに試した設定もお知らせください。全体的なワークフローと制限事項については、ダークモードのデザインとテストをご覧ください。
Gmailのデスクトップ表示でカラムが縦に並んでしまう
一部のメール配信サービス（MailChimpなど）は、送信前にメールのHTMLを変更しようとします。その結果、Gmailをデスクトップで表示したときに、メール内の一部のカラムが横並びではなく縦に並んでしまうことがあります。
通常、これらのプラットフォームがHTMLを変更する目的は、HTML要素にスタイルを「インライン化」することです。しかし、EmailifyはすべてのCSSスタイルをあらかじめ自動でインライン化しているため、メールはそのまま本番で使えます。メール配信サービスのHTML・インポートのオプションに、このインライン化や変更を「無効」にする設定があれば、それで問題が解決するはずです。
原因がメール配信サービスなのかコード自体なのかわからない場合は、htmltest.emailのような無料サービス（HTMLを一切変更しません）を使って、自分宛てにテストメールを送信してください。htmltest.emailからのテストで問題がなければ、メール配信サービスが送信前にHTMLを変更していることになります。
iOS版Gmailでは最小の行の高さが強制される
line-heightを現在のfont-sizeより小さい値に設定すると、Gmailは自動的にline-height:normal;に変更します。そのため、line-height:1、line-height:1em、line-height:100%はすべて想定どおりに機能しますが、line-height:0.9、line-height:0.9em、line-height:99%はすべてline-height:normal;に変換されます。
px値でも同様で、font-size:20px; line-height:19pxは機能しませんが、font-size:19px; line-height:19pxは機能します。
この問題を解決するには、テキストレイヤーの行の高さをフォントサイズ以上にしてください。
GmailのiOSアプリでモバイル向けのレスポンシブスタイルが反映されない
主な原因は、@mediaクエリ内のCSSプロパティやスタイルにタイプミスがある場合（例：padding-bottomではなくpadding-bottm）や、スタイルプロパティの途中に改行がある場合（例：padd 改行 ing-top）です。この場合、Gmailアプリはほかのすべてのスタイルを無視し、モバイル向けのレスポンシブな上書き設定を一切反映しません。
プラグインから通常どおりエクスポートしたコードではこの問題は起こらないはずですが、EmailifyからエクスポートしたあとにHTMLコードを手動で編集した場合（またはメールマーケティングプラットフォームがコードを変更したり、行の長さの制限を追加したりしている場合）に起こることがあります。
Gmailが英語のみのメールを他言語として誤って翻訳する
メールの大半が画像ブロックでリッチテキストがない場合や、メールの下のほうにあるリッチテキストより前に画像ブロックが多くある場合、Emailifyによってhtmlタグとbodyタグにlang="en"属性が自動で追加されているにもかかわらず、Gmailがメールを別の言語だと判断し、英語に翻訳するよう促すことがあります。
Litmusフォーラムのこの問題に関するディスカッションでは、次のように述べられています。
（経験的に）実際のコンテンツより前に大量のCSSやHTMLを含むメールは、コンテンツが別の言語であっても英語に分類されることがわかりました。
私たちの回避策は、テキストとHTMLのマルチパートメールを送信し、HTMLパートの前にテキスト版を入れることです。もちろん、テキストは「Bonjour ...」だけでなく、ある程度の分量が必要です。そうでないと、HTMLタグやCSSのほうが依然として優勢になります。
翻訳アルゴリズムは、メール本文からHTMLやCSSを取り除こうとはしていないようです。あるいは取り除いているとしても、取り除く前にメッセージを切り詰めているため、判定に使えるコンテンツがほとんど残らないのかもしれません。（最近では、コンテンツが1行も始まらないうちに、ヘッダーとCSSだけで5000文字を超えることも珍しくありません。）
GIF
動画をメール用のアニメーションGIFに変換する
残念ながら、HTMLメールではネイティブのvideoタグに対応していないため、HTMLメールのデザインにアニメーション画像や動画コンテンツを追加するには、代わりにGIFを使うのが最善の方法です。インターネットからダウンロードしたGIFファイルでも、自分で作成したGIFでもかまいません。
GIFとして使いたい動画がすでにある場合は、Gifskiという無料アプリを使って、短い動画ファイルをメールデザイン用のアニメーションGIFファイルに変換できます。
また、EmailifyのデザインでGIFを使い、HTMLエクスポートに含めるさまざまな方法を解説したわかりやすい動画チュートリアルもあります。
GIFの色やグラデーションが少し粗く見える
GIFは通常のJPG・PNG画像とは少し異なり、最大256色までしか使えません。精細な画像や色の変化が多いグラデーションを使っている場合、GIF形式のこの制限により、GIFの元になった画像ほど鮮明に見えなかったり、色の再現性が劣ったりするのは避けられません。
GIFで透明部分が表示されない
GIFファイル形式は、不透明度0%か100%のどちらかにしか対応しておらず、その中間はありません。つまり、完全に不透明で表示される要素の背後に、完全に透明な背景を持つアニメーションGIFを作ることはできます。そのため、レイヤーは完全に透明か、そうでないかのどちらかである必要があります。不透明度が50%未満のレイヤーは透明になり、50%を超えるレイヤーは不透明になります。
Figmaで透過GIFとして指定する。Emailifyは、GIFに透明な背景が含まれているかを自動で検出しようとします。GIFに透明部分が必要なのに、プラグインが自動で検出できない場合は、Figmaのレイヤー名の任意の位置にTransparentという単語を追加してください（例：My Layer Name - Transparent）。これで、透明な背景を有効にした状態で強制的にエクスポートされます。
エクスポート時に元のGIFファイルを維持する（縦横比を保つ）
GIFをFigmaにドロップし、元の縦横比を保ったままレイヤーのサイズを変更すると、Emailifyはエクスポートで元のGIFファイルを自動で使用します。
逆に、Figmaのレイヤーの縦横比を元のGIFと異なる比率に変更すると、Emailifyは切り取られた画像領域に合わせてGIFを作り直す必要があります。その結果、GIFのファイルサイズが大きくなったり、エクスポートに時間がかかったりすることがあります。
GmailでGIF画像が表示されない（ファイルサイズの制限）
デザインにGIFを使っているのに、Gmailの受信トレイにテスト送信しても表示されない場合は、Gmailの画像キャッシュの制限に達していて、レンダリングされていない可能性が高いです。
EmailifyはHTMLへのエクスポート時に、サイズの大きいGIFをGmailのファイルサイズ制限以下になるよう圧縮しようとします。これにより、ほとんどの場合はこの問題が解決するはずです（ただし、GIFが極端に長い場合、サイズが極端に大きい場合、元のフレームレートが非常に高い場合を除きます）。
Klaviyo
メールデザインでGIFを使うと、Klaviyoのテンプレートエディターが（ときどき）クラッシュする
Klaviyoには不規則に発生するバグがあり、Error 500（内部サーバーエラー）が発生して、Something is amiss. We're on it. と書かれたページが表示されます。これは主に、テンプレートが「Editable」の場合に起こるようです。
Klaviyoはこのバグを把握していますが、近いうちに修正される予定はないようです。
回避策の1つは、Klaviyo用にHTMLをエクスポートする前にFigmaのデザインからGIFを削除し、上記のエラーが出ずにテンプレートエディターが読み込まれたあとで、GIF画像をKlaviyoに別途アップロードすることです。
編集可能なKlaviyoテンプレートで、テキストブロックの周りに余分なパディングが入る
Klaviyoがエディターを更新し、2023年6月6日以降すべてのテンプレートで新しいエディターの使用が必須になったため、残念ながら、EmailifyでEditable Contentトグルを有効にしてHTMLメールをエクスポートすると、Klaviyoはデフォルトで各テキスト要素の周りに約18pxのパディングを自動で追加します。これは、編集可能なテンプレートの場合にKlaviyoがHTMLに挿入する新しいtd要素に、インラインのstyle属性として追加されます。
EmailifyでForce the padding added by Klaviyo's new editor to be 0pxトグルを有効にすると、すべてのモバイルクライアントと、GmailなどのOutlook以外のデスクトップクライアントでこのパディングを取り除くCSSが自動で追加されます。ただしOutlookでは、Klaviyoエディターでキャンペーン用のメールを編集する際に、テンプレート内の編集可能なテキストブロックの「Padding」の値をすべて手動で「0」に変更しない限り、パディングが表示されたままになります。
Klaviyoのプレビューテキストが重複したり、余分な本文が表示されたりする
プレビューテキストは1か所だけで設定してください。EmailifyですでにPreheader Textを入力している場合は、Klaviyo側のプレビューテキスト欄を空のままにします。Klaviyoでプレビューテキストを管理したい場合は、そのエクスポートではEmailifyのプリヘッダーを空欄にしてください。
意図したプレビューテキストのあとに、Klaviyoで余分な本文が表示され続ける場合は、EmailifyのエクスポートオプションでAdd Whitespace to Preview Textをオンにして、メールを再エクスポートしてください。空でないプリヘッダーのあとに非表示の互換用スペーサーが追加されますが、受信トレイでの扱いはKlaviyoやメールクライアントによって異なる場合があります。
プリヘッダーの全体的なワークフローについては、HTMLメールの件名とプリヘッダーテキストを設定するをご覧ください。
MailChimp
編集可能な画像を有効にすると、（@2xのRetina画像ではなく）ぼやけた@1x画像が使われる
Editable Imagesトグルで、テンプレート内の画像をMailChimpで編集可能にすることもできます。ただし残念ながら、MailChimpは編集可能な@2xのRetina画像に対応していないため、画像は@1xになります。
編集できなくても@2xのRetina画像を使いたい場合は、このオプションをオフのままにしてください。
Typekitフォントの<link>タグを埋め込むと、MailChimpがハイパーリンクのスタイルを削除する
メールにカスタムのTypekitスタイルシートを追加すると、MailChimpはリンクのスタイルを削除します。具体的には、次のようなタグを含めた場合です：<link rel="stylesheet" href="https://use.typekit.net/lml7iwl.css">
このタグを<head>に含めると、MailChimpは <a> タグからすべての style 属性を取り除きます。このタグを削除すると問題が解決し、リンクのスタイルが元に戻ります。
それでもTypekitフォントを使いたい場合は、プラグインに組み込まれたWeb Fonts機能を使えます。スタイルシートをリンクする代わりに、TypekitのCSSファイルに記載されている .woff2 フォントファイルの直接URLが必要です（例：https://use.typekit.net/...）。このURLをプラグインのConfigure Fontsパネルに貼り付けると、HTML内のFigmaのフォント名に合わせた正しい@font-faceスタイルが自動で生成されます。詳しくはステップごとの動画チュートリアルをご覧ください。
なお、カスタムWebフォントが機能するのはApple Mailだけです。ほかのメールクライアント（OutlookやGmailなど）は対応していないため、表示されるフォントを制御できるよう、プラグインでWebセーフな代替フォントを設定することをおすすめします。Figmaでは最初からWebセーフフォントでデザインするのが最も簡単だと感じるユーザーが多いですが、カスタムWebフォントを追加することは、Apple Mailのユーザー向けのプログレッシブエンハンスメントとして今でも有効です。