使ったアドレスは正しく、有効ですか？
ホームに戻り、アドレス全体と残りの有効時間を確認します。古いスクリーンショット、前回のクリップボード、ブラウザーの自動入力によって、別のケース宛てにメールが送られている可能性があります。
- フォームから実際に送信されたアドレスと、現在の受信箱のアドレスを1文字ずつ照合します。
- リクエスト時にアドレスが有効だったか、その後変更していないか確認します。
- 前後の空白や文字抜け、テスト環境による宛先の書き換えに注意します。
認証コードの配信診断
認証コードが届かないときは、
送信ログと受信結果を照合
登録フォームを送信したのに、受信箱に新着メールがありません。再送を続ける前に、このケースのアドレス、送信リクエスト、配信イベントをつなげて、確認箇所を絞り込みましょう。
ページの確認
自動更新 ≠ メールの配信
ホームの受信箱は約7秒ごとに新着メールを確認します。更新は「新着メールがあるか」を確認するだけで、送信システムにメール送信を促すものではありません。
実際の配信
一連の処理にかかる時間次第
サービス側のキュー、送信サービス、受信側の処理が所要時間に影響します。通常は数秒で届いても、一定時間内の到着を保証するものではありません。
状況を判断してから、次の確認へ
認証コードが届かないときに確認する3つの証拠
「送信成功」という画面表示だけで判断しないでください。各段階で、現在のアドレスと操作時刻に対応する記録を確認しましょう。
サービス側で送信タスクは本当に作成されましたか？
「登録APIが成功した」ことと「認証コードのメールが送信された」ことは別です。画面に結果を返してから、非同期でメールタスクを作成するシステムもあります。
- ボタンのスクリーンショットだけでなく、操作時刻、HTTPレスポンス、リクエストIDを記録します。
- サービスのログで送信タスクが作成されたか、宛先が正しいかを確認します。
- 再送の待機時間、送信頻度の制限、テスト用設定、メールドメインの制限を確認します。
配信ログはどのイベントで止まっていますか？
送信サービスが依頼を受け付けても、受信箱にメールが表示されたとは限りません。新しいメールを何度も送るより、メッセージIDで一連のイベントを追うほうが有効です。
- キューへの登録、遅延、受理、バウンスのイベントを確認し、発生時刻を記録します。
- SMTPレスポンスがある場合は、受信ドメイン、応答コード、バウンス理由を確認します。
- 送信サービスがリクエストを受け付けた場合と、受信サーバーがメールを受理した場合を区別します。
証拠を一か所にまとめる
このケースで、次に確認するのは？
分かっている事実を選んでください。「不明」も有効な情報です。ログがないことだけでは、送信障害の証拠になりません。
手元で確認するためのガイド
このパネルは送信システムに接続せず、メールも自動確認しません。選択内容はこのページ内だけで処理され、アップロードも保存もされません。
分かっている事実を選んでから、ガイドを表示
3項目すべてが不明でも始められます。優先して集めるべき証拠を案内し、「記録がない」ことを「送信失敗」とは判断しません。
待機中にも、いくつかの状態があります
「送信済み」だけでは情報が足りません
受信箱でメールの有無は確認できますが、送信タスクが実行されなかった理由や、キューに残っている理由までは分かりません。
まだ送信されていない
サービス側で送信タスクが作成されていないか、待機時間、頻度制限、環境設定などに阻まれています。この段階で受信箱を何度更新しても、タスクは実行されません。
- 受信箱で確認できること
- 該当する新着メールはありませんが、未送信の理由は判断できません。
- 確認が必要な項目
- サービス側のレスポンス、タスク作成ログ、宛先、送信制限の記録。
送信サービスのキュー内
送信サービスにはタスクが登録されていますが、配信はまだ完了していません。一時的な遅延、再試行の仕組み、サービス側のキューが影響することがあります。
- 受信箱で確認できること
- まだメールは届いていません。待ち時間だけでは、メールが消失したとは判断できません。
- 確認が必要な項目
- キューに入った時刻、再試行イベント、直近のレスポンス、サービス側の再試行予定。
受理済み
誰が受理したのかを確認しましょう。APIが送信リクエストを受け付けたのは、サービスが依頼を受けたということです。受信サーバーがメールを受理したほうが、配信のさらに先の証拠になります。
- 受信箱で確認できること
- メールが表示されれば、このサービスで受信を確認できます。まだ表示されていない場合、ラベルだけでは問題箇所を特定できません。
- 確認が必要な項目
- イベントの定義、最終的な宛先、SMTPレスポンス、受理時刻。
バウンスまたは拒否
バウンスは追跡可能な結果ですが、原因がコードの不具合とは限りません。アドレス、ドメインのポリシー、送信元の評価、コンテンツのポリシーなどが影響します。
- 受信箱で確認できること
- 拒否されたメールは通常、宛先の受信箱には表示されません。
- 確認が必要な項目
- 完全なステータスコード、理由、宛先ドメイン、再試行の有無。
送信ログにアクセスできない場合は、操作時刻とリクエストIDをシステム管理者に伝えてください。証拠を補うために、本番環境のAPIキーや認証コード全体をサポート宛てメールに送らないでください。
安全に再テストする手順
一度に変更する条件は1つだけ
次のテストに進む前に、このケースの証拠を残しましょう。アドレスや環境を一度に変更したり、再送を連打したりすると、結果の原因を特定しにくくなります。
ホームに戻って現在のアドレスをコピー-
現在のアドレスをコピーして照合
古いスクリーンショットから打ち直さず、ホームからコピーします。サービス側で実際に送信された宛先と現在のアドレスを比較し、このテストを完了するのに十分な有効時間が残っていることを確認します。
-
再送の待機時間を確認してから、一度だけ送信
サービス側に表示される待機時間と送信頻度の制限を守ってください。最後に発行した認証コードだけが有効なシステムもあり、連続再送すると先に届いたコードが無効になることがあります。
-
時刻を記録し、同じリクエストを追跡
タイムゾーン、リクエストID、配信メッセージIDを記録します。比較が必要な場合は、利用権限のある別の送信システムから、同じアドレスに機密情報を含まないテストメールを送れます。ただし、比較用メールが届いても、元の配信経路に問題がないとは限りません。
-
必要な場合に限り、アドレスを変えて再テスト
機密情報を含まない記録を保存してから、ホームの「アドレスを変更」をクリックします。アドレスを変更すると古いメールボックスは削除され、旧アドレスは現在のテストには使えません。以前のリクエストも新しいアドレスへ自動転送されないため、再度送信してください。
このケースを後から検証できるようにする
配信確認に必要な記録をまとめる
送信側と受信側を照合できれば、それ以上の情報を集める必要はありません。調査に必要な項目だけを記録し、チームで共有するときは不要な個人情報を伏せてください。
| 項目 | 記録方法 | 確認できること |
|---|---|---|
| テスト環境とテストケース | ステージング／テスト環境、登録・パスワード再設定・OTP検証など。必要に応じてビルド番号も記録します。 | 環境の誤り、テスト設定、メール設定の違いがないか。 |
| 実際の宛先と有効性 | 内部確認用として、送信された使い捨てアドレス全体、現在のアドレスとの一致、リクエスト時の有効性を記録します。 | このメールが届くべきケースはどれか。 |
| 操作時刻とタイムゾーン | 例：2026-11-03 14:05:20 +08:00。再送した場合は、操作ごとに別の行へ記録します。 | サービス側のログ、送信サービスのイベント、受信結果が同じ操作に対応しているか。 |
| リクエストIDとメッセージID | サービス側のrequest ID、タスクID、送信サービスのmessage ID。取得できない場合は「未取得」と記録します。 | 画面からのリクエスト、非同期タスク、配信イベントまで追跡できます。 |
| レスポンスと配信結果 | レスポンスのステータス、キュー登録／受理／バウンスのイベント、発生時刻、必要なステータスコード。 | 問題がどの段階で止まっているか、まだ証拠が足りない判断は何か。 |
| 受信状況と次の対応 | 確認時刻、メールの有無、アドレス変更の有無、次に誰が何を確認するか。 | 重複操作を防ぎ、次の担当者に引き継ぐための情報を残します。 |
認証コード全体や本番環境の認証情報は記録しないでください。
認証コード本文、ログインリンク、Cookie、Authorizationヘッダー、本番環境のAPIキーは調査記録に含めないでください。使い捨てアドレスはプライベートな保管庫ではありません。利用前に、プライバシーポリシーと利用規約をご確認ください。
使い捨てメールに認証コードが届かないときは
間違えやすいポイント
観察した事実と結論を区別しましょう。新着メールがないのは観察結果ですが、「コードに問題がある」と結論づけるには、さらに証拠が必要です。
メールが届いたら、テンプレートを確認認証コードのメールはどのくらいで届きますか？
新着メールは通常数秒で表示されますが、すべての送信システムに共通する到着時間はありません。ホームでは約7秒ごとに受信箱を確認しますが、これはページの確認間隔にすぎません。サービス側のキュー、送信サービスの再試行、受信側の処理には別途時間がかかります。時間がたっても届かない場合は、更新間隔を配信の約束とみなさず、配信ログを確認してください。
「再送」を何度もクリックしてもよいですか？
おすすめしません。サービス側の待機時間が終わるのを待ってから、一度だけ送信し、時刻を記録してください。連続再送は送信制限にかかったり、古い認証コードを無効にしたりする可能性があります。複数のメールが後からまとめて届くと、どのコードが有効か分かりにくくなります。
アドレスの期限が切れた後も、先に送られたメールを受信できますか？
期限切れのアドレスを有効な受信先として使い続けることはできません。Tempcaseの使い捨てアドレスはデフォルトで3時間有効です。有効期限内に延長すると、その都度3時間追加され、1つのアドレスの累計有効時間は最長24時間です。期限が切れると、アドレスとメールは削除され、復元できません。送信サービスが再試行中の古いタスクも、新しいアドレスへ自動的に切り替わることはありません。
メールが届かないことは、コードに問題がある証拠ですか？
いいえ。アドレスの誤り、タスク未作成、キューでの待機、ドメイン制限、受信拒否のいずれでも、受信箱にメールがない状態になり得ます。現在のアドレス、リクエストID、配信イベントを照合して、原因を少しずつ絞り込みましょう。ログがない場合は不明のままにし、コードの不具合と決めつけないでください。
ログに「配信済み」とあるのに受信箱に表示されない場合は？
まず、送信サービスが「配信済み」をどう定義しているか、最終宛先、イベント時刻を確認してください。次に、現在のアドレスが期限切れや変更済みでないことを確認し、手動で1回更新します。それでも状況が違う場合は、発生時刻、使い捨てアドレス、メッセージID（機密情報を伏せたもの）を support@tempcase.com までお知らせください。認証コードや本番環境の認証情報は添付しないでください。
すべてのサイトで使い捨てメールを使えますか？
いいえ。使い捨てメールのドメインを制限しているサービスもあり、リクエストを拒否したり、詳細の分からないメッセージだけを表示したりすることがあります。サービスのルールとレスポンスを確認し、アドレスを何度も変えて制限を回避しないでください。自社のステージング環境でのテストは、管理された設定で行ってください。パスワード再設定メールなどを継続して受信するアカウントには、長期転送エイリアスをご検討ください。
証拠を照合してから、次のテストへ
今回のケースに戻る
まず現在のアドレスと受信状況を確認します。メールが届いたら、配信経路全体を同時に変更するのではなく、認証コードの領域とHTMLテンプレートを確認してください。