QA向けテストメールアカウントの選び方

QA用のテストメールアカウントとは?

テストメールアカウント、つまりQA用のテストメールアドレスとは、チームが自社アプリケーションから送信されるメールを受け取り、検査するために使うアドレスのことです。手動で機密性のないサインアップやOTPのチェックには、一時的な受信箱を使いましょう。メッセージの保存、返信、添付ファイルが必要な場合は会社のメールボックスを、自動テストで人の手を介さずにメールを検査する必要がある場合はSMTPサンドボックスやホスト型受信箱APIを選びましょう。

このブログはトイラーが運営しているので、ここに位置づけます。Tmailorは、ウェブ、Android、iOS、Telegramボットで利用できる無料で受信可能な一時郵便サービスです。これは最初のケースに当てはまります。受信箱を開き、登録を起動し、届いた内容を読むだけです。後者の場合、別の Tmailor Temp Mail API を使えば、自動テストが受信専用アドレスを作成し、コードからメッセージを読み取れます。メッセージは到着から約24時間保持され、添付ファイルは受信されず、そのアドレスから送信や返信はできません。使い捨てメールが初めてなら、まずは 一時郵便の仕組 から始めてみてください。

• メールが届く必要がない場合(フォーム検証、フィクスチャ、ユニットテスト)は、予約済みのサンプルドメインを使いましょう。
• 人がメールを読み、内容に機密情報が含まれない場合 は、一時的な受信箱が最速の選択肢です。
• 機密データ、返信、添付ファイル、または保管すべき証拠がある場合 は、承認された会社管理のメールボックスを使いましょう。プラスタグは、メールシステムとアプリケーションが対応している場合にのみ追加してください。
• 誰も見ていない場合 は、アプリの発信メール設定を管理できるならSMTPキャッチャーを、アプリが通常のプロバイダー経由で送信しなければならないならホスト型受信箱APIを使いましょう。

手動と自動のメールテスト:意思決定ツリー

テストメールアカウントをどれにするかは、4つの問いで決まります。メールがそもそも届く必要があるか、人とコードのどちらが読むか、機密データを含むか、そしてアプリケーションが発信メールをどこへ送るかを制御できるか、です。

1. テストでメールが届く必要がありますか? フォーマットチェック、UIの状態、フィクスチャ、ユニットテストでは通常は不要です。example.com、example.org、example.net のアドレスを使いましょう。これらのドメインはドキュメントや例示用に予約されているため、実在の人物には何も届きません。誰かが所有している可能性があるので、ランダムなドメインをでっち上げるのは避けてください。
2. テスト中に人がメッセージを読みますか? スモークテスト、手動UAT、デモ、探索的セッションには人が介在します。回帰テストスイートやCIジョブでは通常は介在しません。
3. も 人が読む場合、内容に機密情報は含まれますか? 実際の顧客記録、認証情報、規制対象データ、監査証拠として保管すべきメッセージは、一時的な受信箱に置くべきではありません。代わりに会社のメールボックスを使いましょう。答えが「いいえ」なら、一時的な受信箱で十分です。
4. コードが読む場合、テスト環境はメールをテスト用SMTPサーバーへ送信できますか? 可能なら、SMTPキャッチャーがすべてのメッセージを配信せずに捕捉します。不可能な場合、つまりアプリが通常のメールプロバイダー経由で送信しなければならない場合は、テストがAPI経由で読めるホスト型受信箱を使いましょう。

この表は5つの選択肢を並べて比較しています。

メールアドレス欄はどのアドレスを受け入れ、どれを拒否すべきか？

フォームのバリデーションはメッセージ配信とは切り離してテストします。有効に見えるが実際には配信されないケースには user@example.com のような予約済みアドレスを使い、プラスタグ付きのアドレスとサブドメイン付きのアドレスを含め、さらにローカル部の欠落やドメインの欠落といった不正なケースを加えます。期待する結果は、本番システムが実際に使っているバリデータと一致させてください。

一時受信箱で十分な場合

一時的な受信箱は、一度に一つのフローを確認し、メッセージに1日で失いたい内容が何も含まれていない場合に機能します。これがQAにおける使い捨てメールの典型的な使い方です。フォームを手作業でテストするにはメールアドレスが必要で、長期間使うアカウントではありません。典型的なケースは、事前のサインアップフォームのスモークテスト、新しいオンボーディングメールの手動UATパス、アカウント作成の営業デモ、または奇妙な入力を試してアプリの反応を見る探索セッションなどです。

魅力はスピードです。IT部門にアカウントを申請する必要も、共有メールボックスを片付ける必要もありません。その代わりに制御が犠牲になります。メッセージの閲覧期間は短く、添付ファイルはなく、受信箱はコードではなく人が読むことになります。

SMTPキャッチャーやホスト型受信箱APIが必要な場合

テストが無人で実行されると、受信箱はコードで読み取れるものでなければなりません。そのニーズを満たす2つのツールファミリーがそれぞれ異なる問題を解決します。

SMTPキャッチャーとサンドボックスは テスト環境でアプリの送信メールサーバーの代わりとなり、すべてのメッセージを配信せずに検査用として保持します。

• Mailpitは自分で運用できる無料のオープンソースツールです。デフォルトでメールをキャプチャし、Web UIと統合テスト用のREST APIを提供します。
• MailHogも同じ仕組みですが、より古いツールです。Mailpitのメンテナーはもはやメンテナンスされていないと述べているため、採用前に状況を確認してください。
• Mailtrap Email Sandboxは同じ発想のホスティング版で、SMTPとAPIアクセスを備えています。これはMailtrapの本番送信製品とは別のものです。
• Etherealは主にNodemailerで使われる無料の偽SMTPサービスです。メッセージはプレビュー用に受信されるだけで、実際に配信されることはありません。

ホスト型受信トレイAPIは、ベンダーのドメイン上の実際のアドレスをテストに提供するため、アプリは通常のプロバイダーを通じてメールを送信し、テストはAPIを通じて結果を読み取ります。Tmailor独自のTemp Mail APIもこの方式で動作し、Python、Node.js、PHP向けの公式SDKが用意されています。

• Mailosaurはテスト用メールアドレス、API、そしてCypress、Playwright、Seleniumなどのフレームワークで動作するクライアントライブラリを提供しています。SMSコードにも対応しています。
• MailSlurpはAPIとSDKを通じてオンデマンドで受信トレイを作成します。テストはメッセージを待ってから、コード、リンク、添付ファイルを取り出すことができます。

ベンダーの機能やプランは変わるため、テストスイートを特定のベンダーに固定する前に、各公式サイトで最新の情報を確認してください。

会社のメールボックスとプラスタグの組み合わせが適している場合

さらに、プラスタグを使えば、1つの会社のメールボックスで多数のアドレスバリエーションを受け付けられます。qa+signupやqa+resetにメールを送ると、会社のドメインのQAメールボックスに届き、タグでフィルタリングできます。Google Workspaceはこれに対応しており、Microsoft 365では管理者が無効にしない限り、Exchange Onlineのアドレス設定でプラスアドレス指定がデフォルトで有効になっています。

フローが実際の顧客データを含む場合、1日以上続く場合、返信や添付ファイルが必要な場合、または監査人が求める可能性のある証拠を生成する場合には、この方法を使ってください。ただし限界を念頭に置いてください。タグは1つのメールボックスのバリエーションであり、別々の受信トレイではないため、並行テストではお互いのメッセージを読み取ってしまいます。一部のサインアップフォームではプラス記号が拒否され、タグ付きのバリエーションも同じアカウントとして扱うアプリもあります。どちらの挙動も、それぞれテストケースにする価値があります。

使い捨てメールで手動サインアップテストを行う方法

使い捨てメールを使った手動サインアップテストには、3つのものが必要です。新しいアドレス、テスト対象のビルド、そして受信トレイの外に何が届いたかを記録できる場所です。自分が所有しているか、テスト権限を持つシステムに対してのみ実行してください。

1. 受信トレイを開きます。 ウェブ上で 無料の一時受信箱を作成する、またはTmailorアプリやTelegramボットを使ってアドレスをコピーします。デスクトップでは、Tmailorのブラウザ拡張機能 を使ってテストビルドのメール欄に入力することもできます。
2. テストビルドでサインアップします。 ステージング環境やQA環境でそのアドレスを使い、フォームを送信した時刻を記録します。
3. メールが届くのを確認します。 どのメッセージが届いたか、差出人名とFromアドレス、件名、そして届くまでにかかった時間を確認します。
4. この ステップを完了します。 リンクをクリックするか、コードを入力します。アカウントの状態が一度だけ変わること、そして同じリンクを再利用すると明確なメッセージとともに失敗することを確認します。
5. 証拠は別の場所に記録します。 リンク、コード、タイムスタンプ、スクリーンショットをテストケースにコピーします。メッセージは到着から約24時間しか保持されないため、受信トレイはテスト記録にはなりません。
6. 再テストする場合はアクセストークンを保存します。 トークンを使えば後で同じアドレスを再び開けます。たとえばパスワードリセットを再実行する場合などです。ただし、すでに期限切れになったメッセージは復元されず、紛失したトークンは復元できません。

無料ユーザー、トライアルユーザー、招待されたチームメイトなど、複数のペルソナが同時に必要なセッションでは、複数の受信トレイ表示 で最大5つのアドレスが1つのブラウザタブに並べて表示されます。各ペルソナには専用のアドレスが割り当てられているため、どのメールアドレスがどのアカウントに属しているかを確認できます。

この表示は依然として手動です。受信箱はコードでプロビジョニングされるのではなく、人がブラウザ上で作成するため、並行した無人実行のためのホスト型受信箱APIの代わりにはなりません。

1つの受信箱ですか、それとも1つのテストにつき1つの住所ですか?

共有の受信箱が1つあれば簡単なスモークチェックには十分ですが、すぐに煩雑になります。複数のテストが同時に実行されると、似た件名ではどのメールがどのスクリプトのものか判別しにくくなり、デバッグは当て推量になってしまいます。

1つのテストケースにつき1つのアドレスで解決します。ログ、スクリーンショット、メールが一致し、欠落しているメッセージはすべてではなく一つのシナリオを指し示しています。複数の一時メール受信箱を管理する では、そのワークフローについてより詳しく説明しています。

また、トライアルから有料へ転換するケースや、解約後に戻ってくるユーザーなど、数日後に同じアドレスを再び必要とするジャーニーもあります。再利用可能な一時郵便アドレス はアクセストークンを通じてアドレスを利用可能な状態に保ちますが、メール自体は保持しません。各ステップの実行時に必要なリンクやコードを保存し、古いメッセージに依存するステップは会社のメールボックスに移してください。テスターがペルソナ用アドレスを作成する前に 無料のTmailorアカウント にサインインすると、それぞれが「作成済みメール」に保存されるため、トークンを失ってもアドレスを失うことはなくなります。

サインアップおよびオンボーディングメールで確認すべきこと

まず、そのジャーニーで送信され得るすべてのメールを洗い出し、各テストで何を検証すべきかを決めます。チームは、テストの途中でメールが現れたり、グロース実験やセキュリティ変更によって誰も記録していなかったメールが追加されたりして初めて、追加のメールに気づくことがよくあります。

典型的なサインアップの流れで送られるメール

• 確認リンクまたはワンタイムコード
• ウェルカムメールとクイックスタートのシーケンス
• マジックリンクによるサインイン
• パスワードリセット
• メールアドレスの変更（旧アドレスと新アドレスの両方に送信）
• 新しいデバイスまたは新しい場所からのアクセスに対するセキュリティ通知
• 完了しなかったサインアップのリマインダー

それぞれについて、トリガー、想定されるタイミング、そしてそれを変える条件(プラン、地域、言語など)を書き留めます。普遍的な基準を仮定するのではなく、製品の文書化された要件に基づいて許容される配信時間帯を設定してください。即時の認証メッセージとスケジュールされたウェルカムシーケンスでは、期待すべきことが異なります。こうした期待値があれば、すべてのテストに具体的な確認対象が生まれます。

各テストメールで検証すべきこと

• 送信者と受信者: 名前と住所、返信先、そして正確な寄付先住所から。
• 件名と本文: HTML版とプレーンテキスト版の両方で、正しい名前、プランの詳細、言語が含まれているか。
• リンク: リンク先と、それが正しい環境を指しているかどうか。ステージング環境のメールが本番環境へリンクしているのは実際のバグです。
• コード: 形式、長さ、有効期限の表記、そして記載された有効期限がサーバー側で適用されるものと一致しているかどうか。
• タイミング: トリガーからメッセージが届くまでの時間。
• 添付ファイル: フローがPDFや請求書を送ってくる場合は、会社のメールボックスやテストツールでテストしてください。トイラーは添付ファイルを受け取っていません。

レンダリングについて一つ注意点があります。使い捨てメールの受信箱は、あるウェブビューアがあなたのHTMLをどう表示するかを示すだけです。同じメールがGmail、Outlook、Apple Mail、ダークモード、小さなスマートフォン画面でどう見えるかは分からないため、それらが重要なら別途レンダリングの確認を計画してください。

メールアドレス変更とアカウント復旧のフロー

復旧フローは、サインアップよりも気づきにくい形で壊れます。メールアドレス変更時に新しいアドレスへ確認メールが、古いアドレスへ通知が送られるか、使用済みのリセットリンクが再利用できないか、新しいリンクを送信した後に古いリセットリンクが無効になるか、別のデバイスでリンクを開いたときにユーザーが妥当な状態に導かれるかを確認してください。OTPフローは別途リスクレビューを行うべきです。QAおよびUAT向けのOTPリスクチェックリスト では、指標、再送信の時間枠、所有権について説明しています。

OTPと認証のエッジケースをテストする方法

OTPと認証のフローは、配信の遅延、再送信、期限切れや誤ったコード、別のデバイスで開かれたリンクに対してテストします。各ケースでは、サーバー側の結果とユーザーに表示されるメッセージの両方を確認すべきです。これらのテストは、所有しているか、テストを許可されているシステムでのみ実施してください。優れたOTPテストは意図的にフローを壊します:

• 到着の遅さ: 受信箱を確認する前に待ち、UIが状況を説明し、再送信の明確な方法を提供しているか確認してください。
• 再送信の動作: 2つ目のコードを要求し、最初のコードが無効になったか、それともまだ受け付けられるかを確認します。
• 有効期限: 表示された有効期間の経過後にコードを入力し、エラーメッセージが実際に起きたことと一致しているか確認してください。
• 誤ったコード: 試行回数の上限とクールダウン時の文言が、人にとって納得できるものか確認してください。
• デバイスをまたぐマジックリンク: ノートパソコンでリンクをリクエストし、スマートフォンで開いて、ユーザーが最終的にどこにたどり着くかを確認します。

どのコードが使い捨てメールの受信箱に届き、どれが届かないかをより広く知りたい場合は、次のガイドをご覧ください:OTPコードに関する一時メール のガイドをご覧ください。

製品が意図的に使い捨てメールのドメインを拒否する仕様なら、その経路を直接テストしてください。拒否メッセージが明確であること、そして実際のアドレスや会社管理のアドレスなら登録を完了できることを確認しましょう。自社製品でも他社製品でも、ブロックを突破するために別の一時ドメインを次々と切り替えてはいけません。ブロックが機能することを確認するのがテストであり、ブロックを打ち負かすことではありません。次の解説では、なぜウェブサイトが一時メールドメインをブロックする について、そうしたフィルターの背景にある理由を説明しています。

メールテストが無人で実行されると何が変わるか

誰も見ていない状況では、テストはコードから読み取れる受信箱を必要とします。つまり、SMTPキャッチャーのAPIかホスト型受信箱APIです。Tmailorのウェブ受信箱はそのツールではありませんが、Tmailor Temp Mail APIは該当します。テストは受信専用アドレスを作成し、メッセージを一覧表示・読み取り、APIが見つけたワンタイムコードや検証リンクを取得できます。MCPサーバーを使えば、Claude、Cursor、VS Code CopilotなどのAIエージェントが、自分が所有する、またはテストを許可されているサインアップフローに対して同じことを行えます。

どのツールを選んでも、無人メールテストを安定させるための習慣がいくつかあります:

• テスト実行ごとに専用のアドレスと相関IDを付与し、前回の実行からの遅れて届いたメールが誤ったアサーションを満たしてしまわないようにします。
• メール到着を待つ専用の処理を、テスト全体のタイムアウトとは別に、適切なバックオフを伴って用意し、各メッセージの所要時間を記録します。
• 「最新のメール」を読むのではなく、受信者と件名で正確にメッセージを特定します。
• CIログではコードやマジックリンクをマスクします。ログは受信箱より長く残ることが多いためです。

また、テストが合格したときに何が証明されるのかも明確にしましょう。「アプリがメールを生成して引き渡した」「ホストされたテストドメインが公開メール基盤を通じて受信した」「Gmailがスパムではなく受信箱に振り分けた」は、それぞれ異なる事実です。SMTPキャッチャーは1つ目を証明し、ホスト型受信箱APIは1つ目と2つ目を証明しますが、どちらも3つ目は証明しません。GitHub Actions、GitLab CI、CircleCIでのパイプライン設定については、次のガイドをご覧ください:CI/CDパイプラインにおけるメールテスト ガイドをご覧ください。

テストデータを安全に保ち、ルールを守る

使い捨てのテスト受信箱には合成の身元と機密性のないコンテンツを使い、サインアップテストは自分が所有する、または評価を許可されているシステムに対してのみ実行してください。QAアカウントは本番の分析から除外し、レート制限を守り、規制対象データ、認証情報、添付ファイル、保持する証拠は承認された会社管理のシステムへ移してください。

• 使い捨てメールの受信箱に実データを入れない。 実際の顧客記録、認証情報、APIキー、規制対象データを一時的な郵便アドレスに転送してはいけません。明らかに偽名の合成ユーザーを使いましょう。
• 検査は 許可されているものだけをテストする。 自分の製品や許可されたシステムに対してサインアップテストを行い、そのサービスの料金制限や条件を尊重してください。一時的なメールを使ってサードパーティサイトで一括アカウントを作成しないでください。ボリュームや負荷のテストは、SMTPキャッチャーやホストされた受信トレイAPIを使った独自のステージング環境で行うべきです。
• QAのトラフィックを本番の数値に含めない。 テストアカウントには明確なラベルを付け、分析や成長ダッシュボードから除外しましょう。本番送信ドメインから大量のテストメールを送るのは避けましょう。そうするとバウンスや苦情が評判を損なう可能性があります。
• ポリシーを文書化する。 どのフローが一時受信箱を使うか、どのフローが会社のメールボックスを必要とするか、テストデータがどのくらいの期間保持されるか、誰がアクセスできるかを明記してください。セキュリティやコンプライアンスの見直しは、境界線がすでに書面に明確にされているとより速く進みます。

セキュリティ担当者がプロバイダーのデータの扱い方を尋ねたときは、何を収集しているか、メッセージをどれだけ保持するか、アクセスがどのように機能するかを確認してください。次の概要では、時メールとオンラインプライバシー ユーザー側の視点からこうした疑問を扱っています。どのフローで使い捨てメールの受信箱を使ってよいかの判断は、依然として自社の法務、プライバシー、セキュリティの各チームに委ねられています。

計画しておくべき制限

Tmailorのウェブ受信箱は、機密性のない受信メールを短時間で手動チェックする用途に向いています(自動化にはTemp Mail APIを使用します)。選ぶ前に、そのワークフローに送信操作、添付ファイル、長期間保存する証拠、または永続的なアドレス復元のいずれかが必要かどうかを判断してください。これらの要件のいずれかがある場合は、会社管理のメールボックスか専門のテストツールが必要です。以下のチェックリストでその理由を説明します。

• Tmailorは受信専用です。受信したサインアップ、認証、OTPメールは確認できますが、返信フローやそのアドレスから送信するものは確認できません。
• Tmailorは添付ファイルを受信しないため、請求書、契約書、書類送付のメールには会社のメールボックスかテストツールが必要です。
• メッセージは到着から約24時間しか保持されません。より長い調査で必要になるリンク、コード、タイムスタンプはエクスポートしておいてください。
• アクセストークンで再び開けるのはアドレスであり、期限切れのメッセージではありません。また、失ったトークンは復元できません。
• ウェブ受信箱は人が読むものです。無人での受信箱の読み取りには、SMTPキャッチャーか、Tmailor Temp Mail APIのようなホスト型受信箱APIが必要です。
• 一部のサービスは使い捨てメールのドメインをブロックしています。テストするフローが意図的にそうしている場合は、実在のアドレスか会社管理のアドレスで検証してください。

適切なテスト受信箱の選び方

テストで何を証明する必要があるかに応じて受信箱を選びましょう。配信が不要な場合は予約済みのサンプルドメイン、機密性のない手動チェックには使い捨てメールの受信箱、保持や機密性が必要なフローには会社のメールボックス、送信設定を自分で管理できる場合はSMTPキャッチャー、無人でのエンドツーエンドテストにはホスト型受信箱APIを使用してください。

手動のケースでは、一時的な受信箱を開き、次にリリースするサインアップフローから始めてください。使い捨てメールには QA以外 も数多くあります。