認証コードからレシートまで：
2通のメールでテンプレートをチェック

受信できても合格とは限らない：3つの結果を区別する

「送信APIが成功した」「受信箱にメールが届いた」「ユーザーがメールを正しく利用できた」は、それぞれ異なる結果です。送信サービスがリクエストを受け付けても、メールが届いたとは限りません。届いたとしても、テンプレートが完全で、すべてのメールアプリで同じように表示されるとは限りません。

そのため、記録には「メールテスト合格」とだけ書くより、「ウェブプレビューでコードをすべて読み取れる」と書くほうが役立ちます。メール自体が届かない場合は、まず認証コードの受信トラブル診断を参考に、アドレス、有効期限、送信制限を確認しましょう。配信の問題を表示の問題と取り違えないでください。

実際のユーザー情報は使わず、自分で用意した2種類のサンプルでテスト

1通目には、たとえば次のような6桁のテストコードを使います。 418752有効期限、安全上の注意、操作の背景も明記しましょう。2通目には注文番号、長い商品名、金額、支払い方法を含め、表の崩れや項目の欠落を確認します。どちらも自分のテスト環境から送信し、架空の注文を使って実際の請求が発生しないようにしてください。

ホームページにあるPayPalとSteamのデモメールは、2種類の情報の読み方を示すだけで、各ブランドとは無関係です。また、あなたの送信システムから配信された証拠でもありません。これらのブランドを装って他人にメールを送ったり、デモの表示だけを根拠に各サイトが使い捨てアドレスを受け付けると判断したりしないでください。

条件を固定してからテンプレートを変更する

• テンプレートのバージョンを記録し、テスト言語、送信設定、サンプル項目を固定します。
• テストに使ったアドレスと送信時刻を記録し、受信箱へのアクセス情報はチケットに書き込まないでください。
• 短い商品名と長い商品名のように、通常の項目と極端な項目のデータを用意します。
• 受信結果と比較できるよう、送信側で生成したHTML版とテキスト版を保存します。

使い捨てアドレスの有効期間は標準で3時間です。延長するたびに3時間追加されます。実際の期限は受信箱のカウントダウンで確認してください。長期間にわたる回帰テストでは、事前にアドレスの有効期間を計画し、期限切れになってからメールが消えたと判断しないようにしましょう。

1通目は操作案内を確認：ユーザーがすぐに認証コードを見つけられるか

認証コードメールの目的はブランドを印象づけることではなく、メールを開いてから認証画面に戻るまでの手間を減らすことです。まず一覧で件名を確認しましょう。ログイン、登録、重要な操作を見分けられますか。差出人名は、ユーザーが直前に行った操作と一致していますか。件名に宣伝文句を詰め込みすぎて、肝心な操作が省略表示されないようにしましょう。

コードは見やすく、コピーしやすく

6桁の数字は画像に埋め込まず、実際のテキストとして表示します。選択してコピーしたあと、スペースや改行、ほかの文字が混じっていないか確認してください。見た目の文字間隔を変えても、コードの実際の文字列が変わってはいけません。先頭にゼロがあるサンプル、たとえば 048193も使い、テンプレートが数値として処理して先頭のゼロを削除しないことを確認しましょう。

有効期限はコードのすぐそばに表示し、実際のバックエンドのルールと一致させます。「10分間有効」が発行時からの計算なら、メールの到着が遅れたユーザーに、そこからさらに10分あると誤解させてはいけません。操作の背景には、実際に把握している情報だけを表示し、端末や場所、リスク判断を作り上げないでください。

最後に安全上の注意を確認します。認証コードを他人に教えないこと、心当たりのない操作があった場合の対応を明記してください。テスト用のスクリーンショットを共有するときは、コードの有効期限が切れていても必ず隠しましょう。認証コードメールの説明は、短く明確なほど、ユーザーが大切な情報を見落としにくくなります。

2通目は構成を確認：長い項目でも内容の対応が崩れないか

レシートメールのテストは、請求書の照合に似ています。架空の注文番号 STM-6093-2741-58、商品名 Hollow Lantern: Deluxe Edition、金額 $14.99 、支払い方法「ウォレット残高」を使い、ラベルと値が常に隣り合って表示されるか確認します。さらに注文番号を長くして、金額の列が画面外に押し出されないかも見てください。

まず内容を照合し、そのあと装飾を確認

通貨を明記し、小数点以下の桁数を決済ルールと一致させます。税金、割引、返金がある場合は、合計金額の計算も説明できるようにしてください。支払い方法の表示に、カード番号全体や決済情報を含めてはいけません。任意項目がない場合は、その項目を省略するか状態を明示し、「undefined」や空のラベルを残さないようにします。

テンプレートに「注文を見る」リンクがある場合は、自分のテストシステムでリンク先、注文の所有者、ログイン要件を確認します。デモメールの偽ボタンは遷移しないため、リンクのテストにはなりません。メールに取引成功と表示されても、決済システム上の注文状態を確認したことにはなりません。実際の業務では、サーバー側の記録を基準にしてください。

狭い画面で確認：縮小するのではなく、読み直す

まず幅約390pxのビューポートで確認し、そのあと実機のスマートフォンでもチェックします。差出人、何が起きたか、コードや金額の場所、次の操作の順に、一般的なユーザーの目線で読みましょう。最初の画面のスクリーンショットだけで済ませず、本文の最後までスクロールしてください。

• 長い注文番号は項目内で折り返してもかまいませんが、ラベルに重なったり、隣の金額を隠したりしてはいけません。
• 商品名は複数行に折り返せるようにし、購入したバージョンを見分けるための後半部分を、見た目を整える目的で切り捨てないでください。
• ボタンの文言が長い場合は自然に折り返し、テキストがクリック可能な範囲内に収まるようにします。
• 文字を拡大しても、表、説明、操作リンクが適切な順序で表示されることを確認します。

ウェブ受信箱にも一覧画面と閲覧画面があります。そのため、問題がメール本文のはみ出しなのか、表示に使っているページ側の問題なのかを区別してください。デスクトップブラウザーの幅を狭めるだけでは、スマートフォン向けメールアプリで起こるフォントの置き換え、自動拡大、ダークモードは再現できません。

画像を非表示にしても、必要な情報は残るか

画像の読み込みに失敗しても、ロゴは消えることがありますが、コード、金額、操作案内まで消えてはいけません。情報を伝える画像には簡潔な代替テキストを付け、装飾だけの画像では空の代替テキストを設定します。スクリーンリーダーが意味のないファイル名を何度も読み上げないようにしてください。重要な内容を背景画像だけに載せるのも避けましょう。

画像を非表示にするだけでは、テキスト版のテストにならない

HTMLメールのテキスト版とは、メールに同梱されている text/plain 形式の内容です。ブラウザーがHTMLタグを取り除いた結果ではありません。送信側で両方のバージョンを確認してください。MIME構造を確認する必要がある場合は、自分の送信記録、またはメールのソースを表示できるメールアプリを参照しましょう。

テキスト版には、操作の目的、完全なコード、有効期限、または注文番号、商品、金額、支払い方法を最低限記載します。リンクが必要な場合は、内容がわかる文脈を添えてください。「HTML版を確認してください」とだけ書いたり、HTML版で変更した古い金額や期限をテキスト版に残したりしないでください。

ウェブプレビューに画像を非表示にする機能やテキスト版へ切り替える機能がない場合は、その項目を「未検証」として別のテスト環境で確認してください。画面が正常に見えるだけで、両方を合格にしてはいけません。

「少し窮屈」ではなく、再検証できる記録を残す

よい記録があれば、その場にいなかった人も同じ問題を再現できます。最低限、テンプレートのバージョン、テスト条件、サンプルの特徴、期待値、実際の結果、個人情報を隠した証拠を含めましょう。環境の説明がないスクリーンショットだけを貼るのは避けてください。

結論は「合格」「不合格」「未検証」のいずれかで記録し、確認範囲も明記します。内容の欠落、金額の誤り、使えないコードは、余白の不一致より優先して対応してください。修正後はメールを再送信して確認します。ブラウザーの開発者ツールで見た目だけ整えて、問題をクローズしてはいけません。

ウェブプレビュー以外では、どこで確認するか

ウェブプレビューはブラウザーの描画機能を使います。一方、Gmail、Outlook、Apple Mailなどのメールアプリは、HTML、スタイル、フォント、画像の扱いがそれぞれ異なります。セキュリティ上の処理でスクリプト、フォームなどの危険なコンテンツが削除されることもあります。プレビューに表示されないからといって、メールアプリとの互換性が保証されるわけではありません。

実際のユーザー構成をもとに、必要最小限のメールアプリ一覧を作ります。たとえば、Gmailのウェブ版とモバイルアプリ、対象とするWindows環境の具体的なOutlookのバージョン、iPhoneのApple Mailなどです。OSとアプリのバージョンを明記し、「Outlookでテスト済み」だけで済ませないでください。

各環境でライトモードとダークモード、画像が制限された状態、文字の拡大、リンクの操作を確認します。アクセシビリティの検証が必要な場合は、実際のスクリーンリーダーで読み上げ順序もテストしてください。使い捨てメールで受信できても、ほかのメールサービスの迷惑メール判定、ドメインの評価、認証結果が通過したことにはなりません。配信と送信ドメイン認証は別の確認項目にしてください。

テストを終了する：サンプルの扱いまで確認する

必要な情報を個人が特定できない形で記録したら、不要になったテストメールを削除します。1通のメールを削除しても、アドレス全体がすぐに無効になるとは限らず、送信側のログ、チケットの添付ファイル、ローカルのスクリーンショットも消えるわけではありません。こうしたコピーは、それぞれの保管ルールに従って処理してください。

使い捨てメールアドレスを、本番環境のアラート、請求書、パスワード再設定、長期的な回帰テストのスクリプトに使わないでください。継続して受信する必要がある場合は、長期転送エイリアスを検討し、自分の運用に適しているか確認してください。重要なアカウントには、長期にわたって管理できるメールアドレスを登録しましょう。

最後に残すのは、見栄えのよいスクリーンショット2枚ではなく、再テストできる条件です。操作案内は明確か、取引情報はそろっているか、どのメールアプリを確認済みで、どれが未検証か。ブラウザーの認証情報とデータの取り扱いについては、プライバシーポリシーをご覧ください。