キャンペーンの前に毎回行うチェックと、Brew のメール診断のしきい値。102KBでの切り詰め、リンク切れ、代替テキスト、対応クライアント、コピーの長さを解説します。
送信前のQAチェックリストとは、すべてのメールについて、配信する前に行う短いチェックの一覧です。不具合のあるキャンペーンは、たいてい、# を指したままのボタンや、夕方6時に4MBのPNGに差し替えられたヒーロー画像、従来の Outlook が無視する2カラムのレイアウトを抱えたまま送られています。どれも送信前なら1分で見つけられますが、送信後には直せません。
私たちは今月、こうしたチェックを軸に Brew のメール診断を作り直し、チェックごとに正確なしきい値を決めました。Brew を使う場合も使わない場合も、手作業で実行できます。
重要度別にまとめられた診断結果と、送信準備についての1つの判定。
リンク切れがあると、その配信は無駄になります。次の点を確認しましょう：
# や example.com、未入力の {{url}} ではなく、実際のリンク先が設定されているhttps を使っているbrew.new/pricing と表示されているのに別の場所に飛ぶリンクは、フィッシングに見えますリンクは、エディターではなく、実際に届いたテストメールでクリックしましょう。ESPは送信時にクリックトラッキングのためにリンクを書き換えるため、リダイレクトの連鎖や壊れたトラッキングパラメーターは、届いたメールでしか確認できません。
配信停止リンクや配信設定のリンクには、自動チェックツールから絶対にリクエストを送らないでください。そのURLへのリクエストを、すべて配信停止として扱うプロバイダーもあります。また、チェックツールにボット対策の画面が返されたからといって、リンクが切れているとは限りません。自分でクリックして確かめましょう。
Gmail は、HTMLが約102KBを超えるメッセージを途中で切り詰め、残りを「メッセージ全体を表示」リンクの先に隠します。フッター、配信停止リンク、住所が見えなくなるため、切り詰められたマーケティングメールは、知らないうちにコンプライアンス上の問題になってしまいます。
Brew のしきい値は次のとおりです：
80KBで警告するのは、クリックトラッキングによって短いリンクが長いリダイレクトURLに置き換えられたり、ESPによってはマークアップが追加されたりするからです。エディターでは98KBでも、届いたときには105KBになっていることがあります。
サイズが膨らむよくある原因は、要素ごとに繰り返されたインラインスタイル、メールビルダーが残したコメント、非表示になっているモバイル用とデスクトップ用の重複したセクション、埋め込まれたbase64画像です。
すべての画像について、次の点を確認します：
alt テキストがある（純粋な装飾なら alt=""）width と height が指定されている（画像の読み込み中やブロックされたときにも、レイアウトが崩れないように）1行のテキストの上に大きな画像が1枚だけ載ったメールは、画像をオフにすると読めず、スクリーンリーダーにも内容が伝わらず、一部のフィルターではスパムの兆候とみなされます。見出しとオファーは、画像ではなく本物のテキストで入れましょう。
Flexbox、Grid、position、背景画像、インラインSVGは、いずれも少なくとも1つの主要なメールクライアントで崩れます。Can I email は、機能ごと・クライアントごとの対応状況をまとめており、ひとつだけ参照するならこれが最適です。
最も注意すべきは Outlook です。Gmail や Apple Mail は、たいてい目立たない形で表示が劣化するだけです。Windows版の従来の Outlook は Word のレイアウトエンジンでレンダリングするため、多くのCSSの幅指定を無視し、背景画像を表示せず、スタイルを当てたリンクで作ったボタンからパディングを取り除いてしまいます。
Brew が Gmail や Outlook といったクライアントのファミリー単位で機能を指摘するのは、そのファミリーの2つ以上のクライアントがその機能に対応していない場合だけです。「警告」になるのは、Outlook で代替手段のないまま崩れる場合だけで、それ以外はすべて「情報」です。そうしないと、どのメールにもクライアント関連の警告が20件も並び、誰も目を向けなくなってしまいます。
手軽にできるチェック：
<html> に lang がある（スクリーンリーダーが正しく読み上げられるように）<title> があるh1 から h4 に飛んでいない基準となるのはWCAG 2.2です。メールの問題の多くは、代替テキスト、コントラスト、ページの言語、見出しに関する達成基準に対応しています。
件名は約60文字かつ9語未満に収めましょう。そうしないと、スマートフォンで途中が切れてしまいます。すべて大文字の表記、返信や転送ではないメールへの「RE:」や「FWD:」、感嘆符の連続も避けます。
プレビューテキストは約90文字未満にし、件名を繰り返さないようにします。空のままにすると、多くのメールクライアントでは、代わりに「ブラウザで表示」のような文言が表示されてしまいます。
代替値のない差し込みタグがあると、名が登録されていない全員に、「Hi ,」のように名前の抜けたあいさつが届きます。読み手は、それを覚えているものです。
すべての数字には、示せる出典が必要です。とくにAIが書いた最初の下書きは、もっともらしい数字を簡単に作り出すので注意しましょう。言葉選びについては、マーケティングメールの書き方と件名のガイドで詳しく解説しています。
CAN-SPAM法では、商用メールに、機能する配信停止リンクと有効な住所が必要です。Gmail と Yahoo 宛てにメールを送る一括送信者には、ワンクリック配信停止のヘッダーも必要です。詳しくは、エージェントがメールを送る場合にも変わらないことで説明しています。
トランザクションメールには、マーケティングメールのルールの一部が適用されませんが、このチェックリストは省けません。リンク切れのある領収書は、やはりサポートへの問い合わせにつながります。
メールクライアントが削除またはブロックするものは、取り除いておきましょう：
<script>、<form>、<iframe> の要素data: URIbackground-color の代替指定がない背景画像（画像を読み込めなかったときにも、テキストが読めるように）冒頭にはDOCTYPE宣言を入れましょう。ないと、一部のクライアントは互換モード（quirks mode）でレンダリングし、余白がずれてしまいます。
Brew のメール診断は、次の場所からこのチェックリストを実行します：
POST /v1/emails/audit または audit_email ツール）すべてのフィールドについては、診断のドキュメントとAPIリファレンスをご覧ください。
HTMLだけで判定できるルールについては、無料の即時チェックが自動で実行されます。対象は、プレースホルダー、サイズ、代替テキストと画像サイズの指定漏れ、見出しの順序、lang と <title>、件名とプレビューテキストの長さ、代替値のない差し込みタグ、ブロックされるマークアップです。
診断を実行を選ぶと、ネットワークへのアクセスや判断が必要なチェックが加わります：
AIによる各判定は、私たちが保有するメールで、指摘した内容が95%以上の確率で正しくなるよう調整しています。オオカミ少年のようなAIレビュアーなら、ないほうがましです。
完全な診断には5クレジットかかります。必須のチェックを実行できなかった場合は、スコアなしの部分的な診断が無料で返されます。チェックを飛ばしたスコアでは、誤解を招くからです。
すべての診断で、0〜100のスコアと状態（ready、needs review、not ready のいずれか）が返されます。アプリでは、それぞれ「送信準備完了」「要確認」「問題あり」と表示されます。各診断結果には、「重大」「エラー」「警告」「情報」のいずれかの重要度と、リンク切れのHTTPステータスなどの根拠が含まれます。
スコアは100点から始まります。「重大」1件につき20点、「エラー」1件につき10点、「警告」1件につき3点が引かれ、「情報」は減点されません。カウントされるのは、ルールごとに最初の3件までです。
例として、リンク先が # のボタン、404を返すフッターのリンク、代替テキストのない画像2枚、68文字の件名、Yahoo の2つのクライアントが無視する Flexbox がある場合を考えてみます。
| 診断結果 | 重要度 | 点数 |
|---|---|---|
| ボタンのリンクがプレースホルダーのまま | 重大 | −20 |
| フッターのリンクが404を返す | エラー | −10 |
| 代替テキストのない画像（×2） | 警告 | −6 |
| 件名が60文字を超えている | 警告 | −3 |
| Yahoo の2つのクライアントが Flexbox に非対応 | 情報 | 0 |
| スコア | 61 |
「重大」か「エラー」が1件でもあれば「問題あり」、「警告」だけなら「要確認」です。この例で2つのリンクを直せば、スコアは91で「要確認」になります。正直なところ、このまま送っても問題はありませんが、残りの指摘にも1分かける価値はあります。
チャットで修正を選ぶと、「警告」以上の診断結果が Brew のエージェントに渡され、修正後には無料の即時チェックがもう一度実行されます。
診断は、送信をブロックしません。「重大」の診断結果がある場合、送信ダイアログではこのまま送信を選ぶ必要があり、その判断は記録に残ります。API、MCP、オートメーションからの送信では、診断結果が報告されたうえで、そのまま送信されます。これが正しいデフォルトです。診断が良しとしないメールでも送るべきものはありますし、送信を人質に取るようなQAツールは、いずれオフにされてしまいます。
HTMLを書き換えることもありません。修正は、あなたが始める別のステップです。
受信トレイへの到達のテスト、レンダリングのスクリーンショットの作成、ダークモードのチェックも行いません。ダークモードについては、スマートフォンでダークモードをオンにして、テストメールを開いてみましょう。黒い背景で消えてしまうロゴに気づけます。
送信ダイアログでは15分です。それを過ぎるか、メールが変更されると、パネルに診断の再実行を求めるメッセージが表示されます。MCP経由なら、保存されたレポートを7日間、無料で読み直せます。
いいえ。診断がチェックするのは、メールそのものです。受信トレイに届くかどうかは、ドメインのレピュテーション、認証、迷惑メール報告率にも左右されます。これらについては、到達率ガイドで説明しています。
はい、APIかMCPを使えば診断できます。Brew のメールIDの代わりに emailHtml か emailJsx を送れば、ESPに取り込む前に同じレポートを受け取れます。ギャラリーのテンプレートをリミックスしてESPにエクスポートする場合も、エクスポートの前に Brew で診断しておきましょう。
ブランドにアクセスできる人なら、誰でも実行できます。つまり、組織の管理者と、そのブランドに追加されたメンバーです。Brew には閲覧のみの役割はありません。
