今週は「実際にメールを受け取るか」から決めます
RFC 2606は、example.com、example.net、example.orgの3つを例示用ドメインとして予約しています。これらはテストデータには使えますが、実在する受信箱ではありません。 RFC 2606の予約ドメイン一覧
今週の作業では、まずテスト対象を「形式やフォームの確認」と「メールを受け取って行う確認」に分けます。前者には予約済みドメイン、後者には実際に読める受信箱を選び、加号アドレスか一時受信箱かは、隔離性と再テストの要件で決めてください。
登録、認証コード、パスワード再設定のメールを確認するQAエンジニアには、各アドレスでできることとできないことを整理します。
テスト環境とアカウントデータを扱う開発者には、実在する個人・チームの受信箱をテストに流用するリスクを減らす方法を示します。
自社製品の公開前チェックを行う独立開発者には、テスト目的に合わせた選び方を案内します。
まず区別したいのは形式・送信・受信後の確認です
「形式が正しい」「メールが送信された」「受信後の操作まで完了できた」は、別々の確認項目です。フォームの入力制御だけを見るなら、実際にメールを受け取れないアドレスでも役立つ場合があります。しかし、送信されたことや認証リンクの動作まで確かめるには、受信箱を開いて内容を確認できなければなりません。
| テスト目的 | 予約済みドメイン | 加号アドレス | 一時受信箱 |
|---|---|---|---|
| 形式やフォームの入力確認 | 適しています。実在のメール受信はできません | 実際に使うメール基盤とフォームの対応次第です | アドレス形式の確認には使えますが、受信要件とは分けて考えます |
| 実際のメール受信 | 受信先としては使えません | 元の受信箱に届く設定なら確認できます | 受信箱にアクセスできる場合に確認できます |
| テストごとの切り分け | テストデータとして区別できます | ラベルは付けられますが、受信箱自体は通常共通です | 個別アドレスや受信の分離に対応するか、実際の機能を確認します |
| 長期の再テスト・アカウント復旧 | 受信できないため不向きです | 元の受信箱を管理できれば使えます | 有効期間や保存条件を確認し、長期復旧が必要な用途は避けます |
RFC 2606にある例示用ドメインは、実際の受信先として予約されたものではありません。そのため、example.comを使う場面は、フォームの入力処理やテストデータの確認など、受信を伴わない検証に限ります。
テストフォームのメール形式確認にexample.comを使えますか？
受信が不要で、入力形式やエラー表示だけを確認するなら使えます。ただし、実メールの到着、認証コードの取得、リンクのクリックまで確認できたことにはなりません。テスト仕様には「形式確認のみ」と記録し、送信後の動作確認と混同しないようにします。
受信・隔離・プライバシーをどう見比べるか
| 判断軸 | チームや個人の受信箱 | 加号アドレス | 一時受信箱 |
|---|---|---|---|
| メールを読めるか | 受信設定とアクセス権があれば読めます | 対応するメール基盤なら元の受信箱で読めます | 利用するサービスの受信機能とアクセス条件によります |
| アカウントの切り分け | 受信箱を分けないと、テスト通知が混ざります | +以降のラベルで識別できますが、独立した受信箱にはなりません |
個別に利用できるかを機能とテストで確かめます |
| 内容の露出 | 個人・チームの受信箱にテストメールが残ります | 元の受信箱を閲覧できる人に内容が見える可能性があります | 受信箱の公開範囲と保存条件を事前に確認します |
| 継続的な再テスト | 管理権限を確保しやすい方法です | 元のアドレスとラベルの扱いが維持されるか確認が必要です | アドレスの有効期間や受信内容の保持を確認しないと、復旧用途には向きません |
RFC 5233は、アドレスのローカル部に付加情報を持たせるサブアドレスの考え方を説明しています。区切り文字や処理方法はメールシステムの実装に左右されるため、加号アドレスがすべてのメール基盤や登録フォームで同じように扱われるわけではありません。RFC 5233のサブアドレス仕様
特定のメール基盤については、加号アドレスの公式説明で対応方法を確認できます。ただし、個別の仕様を他のサービスや自社アプリにも当てはまる一般ルールとして扱わず、対象環境で試してください。ラベルを変えても、同じ受信箱を共有するなら、メールの閲覧権限やテストデータの隔離まで分かれるわけではありません。
認証コード、パスワード再設定リンク、個人情報を含む通知は、公開範囲が分からない受信箱に送らないでください。検証対象は自社製品、またはテスト許可を得た環境に限定します。
互換性と再テストは、自社環境で確かめます
登録フォームが加号記号を拒否する、入力値を正規化する、重複判定で異なるアドレスを同一視する、といった処理を行う可能性があります。仕様書だけで判断せず、対象のフォームで入力・登録・メール受信までを試し、アプリが保存したアドレスと受信先が一致するか確認してください。
また、SMTPでは受信側サーバーがメールを受け入れた後の配送責任が定められていますが、受け入れられたことだけで、利用者が受信箱を開けることや、認証操作が完了することまでは保証されません。SMTPの受信と配送責任に関する仕様を踏まえ、テストでは送信記録だけでなく受信後の動作も確認します。
加号アドレスは登録メールのテストに向いていますか？
受信基盤が加号アドレスを処理し、対象アプリもその形式を受け入れるなら、既存の受信箱でテストメールを確認できます。テストごとのラベル付けには便利ですが、同じ受信箱を使う以上、独立したアカウントや閲覧権限が自動で用意されるわけではありません。
一時メールと加号アドレスのどちらで認証コードを確認しますか？
既に管理できる受信箱があり、アプリが加号アドレスを受け付けるなら、加号アドレスで十分な場合があります。短期の受信先を分けたい場合は一時受信箱を候補にできますが、アドレスの継続利用やメールの保存条件を確認してください。どちらも、実際に届いた認証コードを読める状態であることが前提です。
テスト目的から選ぶ条件分岐
第一段階：テスト環境で順番に確認します
- 期待する結果を明記します。 フォームの形式確認、メール送信、受信後の認証のどこまでを検証するか決めます。
- 受信が不要なら予約済みドメインを使います。 受信できないことを前提に、入力エラーやテストデータの処理を確認します。
- 受信が必要なら管理できる受信箱を選びます。 加号アドレスを使う場合は、メール基盤と自社アプリの両方で受け入れられるか確認します。
- 分離したい対象を決めます。 アドレスのラベル付けだけで足りるのか、受信箱や閲覧権限まで分ける必要があるのかを整理します。
- メールを開いて最終操作まで実行します。 認証コードの入力やリンクの遷移を確認し、送信ログだけで合格にしません。
- 再テストと復旧の条件を記録します。 受信先の管理者、アドレスの再利用可否、メールの保存条件を確認し、長期運用ではチーム管理のテスト用受信箱を検討します。
条件に合う方法を選びます
- メールを送らず、入力形式だけを調べる場合は、予約済みドメインを選びます。実際の受信が必要になったら、受信可能な方法に切り替えます。
- 本物のメールを読み、管理済みの受信箱を使える場合は、対象アプリとメール基盤で確認したうえで加号アドレスを選びます。加号が拒否されたり、アドレスの正規化で問題が出たりする場合は、受け入れられる別のテスト用受信先に切り替えます。
- 短期の受信先を分けたい場合は、一時受信箱を検討します。受信機能、アクセス範囲、保存条件を確認できない場合は、チームが管理する長期のテスト用受信箱を使います。
- 機密性の高いメールや安定したアカウント復旧が必要な場合は、継続管理できる専用のテスト環境と受信箱を使います。一時受信先に重要なアカウントを結び付けないでください。
自社製品の登録や再設定を公開前に確認する場合は、QAチェック項目も使い、テストの目的と受信後の確認を分けて記録できます。加号アドレスと一時受信箱の違いをさらに整理したい場合は、一時メールとエイリアスの比較を参照してください。
実際にメールを受け取る必要があり、テスト環境で受け入れ可能なことも確認できたら、TWININBOXの一時受信箱も短期テストの選択肢になります。利用前に、対象アプリのアドレス検証ルールと、受信後のメールをどの範囲で扱えるかを確認してください。長期の回帰テストやアカウント復旧には、チームが管理する受信先を残しておくのが安全です。