2026 Auth.js Magic Linkログインメールをどう検収する？

メールの送信処理は成功したのに、テスト用受信箱に見当たらない。あるいは、リンクを開いてもログインできたか判断できない。
判断：Auth.js Magic Linkログインメールのテストでは、本文とリンクを実際に読める受信先を使い、受信・リンク処理・セッション確立まで確認してください。送信要求の成功だけでは、ログインが使える証拠になりません。

Auth.js Email Providerを使って自社アプリのログインを検証する開発者や、メール回帰を担当するQA向けです。
個人用・業務用の受信箱にテストメールを混在させたくない、開発者や小規模チームにも役立ちます。

検証を始める前に、合格条件を決めます

テスト対象は、自分が開発するアプリ、または検証を許可された環境に限ります。まず、メールの送信要求、テスト用受信箱への実着、リンクを開いた後のログイン完了を、別々の結果として記録してください。

開発・プレビュー・本番のどの環境を試すか決め、ログイン後に表示される画面と、期待するユーザー状態も書き出します。「ログイン画面から移動した」だけでは、セッションが確立したとは限りません。

Auth.jsのEmail Provider公式ガイドではメール認証の流れが案内されています。利用するアダプターや設定はプロジェクトによって異なるため、Email ProviderのAPIリファレンスと実際の実装を併せて確認します。

テスト要求を発行し、環境とひも付けます

自社アプリのログイン画面から、受信を確認できるテスト用受信アドレスを入力して要求を発行します。手動でメールを送るだけでは、アプリのログイン入口から送信要求を作る経路を検証できません。

テスト記録には、使用した環境、受信先、実行時刻、実行を識別する情報を残します。メールの記録とアプリのログを対応づけられると、送信要求が処理されたのか、メールが届いたのかを切り分けやすくなります。

Auth.jsのインストールとルート設定の案内も参照し、リクエストを受けるアプリ側の経路が対象環境のものか確認してください。送信側が要求を受け付けた記録は、あくまで送信処理の証拠です。

受信メールで宛先とリンク先を照合します

受信箱を開き、対象のメールが届いているか、宛先が今回入力したアドレスか、本文にログインリンクがあるかを確認します。届かない場合は、アプリの送信記録、メール送信側の結果、受信箱の迷惑メール判定を分けて調べましょう。

リンクは開く前に、ホスト名とパスが意図した環境を指しているかを確認します。想定外の環境へ移動する場合は、サイトURL、コールバック先、メールテンプレートの設定を自分のプロジェクトで照合してください。Auth.jsの既定動作だと決めつけて、原因を一つに絞るのは避けます。

受信メールを読む用途では、本文とリンクを確認できる方法を選ぶ必要があります。用途ごとの受信先を整理したい場合は、使い捨てアドレスとマスクアドレスの違いも参考になります。

リンクを開き、アプリ側のログイン状態を確かめます

リンクを対象環境で開いたら、コールバック処理が完了するか、意図したページへ移動するかを記録します。そのうえで、アプリが正しいユーザーとして認識していることを確認してください。遷移先の表示だけを成功条件にすると、セッションの問題を見落とすことがあります。

保護対象のページがある場合は、ログイン状態でアクセスできるかも確認します。セッションを使ったアクセス制御の考え方は、Auth.jsのリソース保護ガイドを参照し、自分のアプリで採用している方式に合わせて検証してください。

再申請とリンクの再利用を自分の設定で試します

新しいメールを申請したあとに以前のリンクを開く、同じリンクを再度開く、無効なリンクを開く、といったケースを自社のテスト環境で確認します。どの操作でリンクが使えなくなるか、またはログイン状態がどう変わるかは、プロジェクトの設定と実装に基づいて記録してください。

Auth.jsの一般的な仕様として固定の有効期間や、すべての実装に共通する再利用ルールを想定してはいけません。失敗時には、画面が状況を理解できる形で案内するか、意図しないログイン状態が残らないかも確かめます。

受け入れ記録をそろえ、未検証の範囲を残します

テストを終えたら、送信要求の記録、受信箱で確認したメール、リンクを開いた結果、最終的なログイン状態をまとめます。受信確認まで成功していても、対象の受信先で確認した結果を、本番の全受信者への到達保証に広げてはいけません。

受け入れ前の確認項目は、次のようにチェックできます。

• [ ] 検証対象が自社アプリ、または許可された環境である
• [ ] 開発・プレビュー・本番のうち、今回試す環境を記録した
• [ ] アプリのログイン入口からメール送信要求を発行した
• [ ] 受信箱でメールと宛先を確認した
• [ ] リンク先が意図した環境を指している
• [ ] リンク処理後、アプリ側のログイン状態を確認した
• [ ] 再申請、再度のリンク利用、無効リンクの結果を記録した
• [ ] 本番や別の受信先で未確認の項目を明記した

メール本文やリンクを読む必要がないテストなら、受信箱を介さない検証方法が適する場合もあります。一方、実際のテンプレートやリンク先まで確認する受け入れでは、受信内容を確認できるテスト用受信先が必要です。テストメールを個人の受信箱に集めない運用を考える際は、メール受信の時間管理に関するガイドも参照できます。

よくある確認事項

送信ログが成功なら、受信も成功と判断できますか？

判断できません。送信処理の記録と、受信箱にメールが届いた証拠は別です。実際に受信箱を開いて宛先と本文を確認し、届かない場合はアプリ側とメール送信側の記録、迷惑メール判定を切り分けてください。

リンクを開いて画面が変われば、ログイン成功ですか？

画面遷移だけでは不十分です。アプリが期待するユーザーとして認識していることや、ログインが必要なページへアクセスできることを確かめます。メール到達、リンク処理、セッション確立を個別に記録すると、失敗箇所を特定しやすくなります。

Magic Linkの再クリックで、どんな結果を期待すればよいですか？

特定の結果をAuth.js全体の共通ルールとして期待するのではなく、自分の環境で再申請後の古いリンク、同じリンクの再利用、無効リンクを試します。表示された案内と最終的なログイン状態を記録し、プロジェクトの設定と実装に照らして合否を決めてください。

リンクが別環境へ移動した場合は、どこから調べますか？

メール本文にあるリンクのホスト名とパスを確認し、対象環境のサイトURL、コールバック先、メールテンプレートを照合します。開発環境とプレビュー環境のどちらで要求を発行したかも記録し、実際のリンクと設定の食い違いを調べてください。

一時的な登録やログイン確認のためにメール本文を読み、リンクまで試す必要があるなら、テスト用受信先を個人・業務用の受信箱と分ける方法があります。TMPFoxを候補にする場合は、TMPFoxの現在の受信画面で、今回必要なメール本文やリンクを確認できるかを確かめてから使ってください。銀行や決済など、長期の復旧や継続受信が必要なアカウントには、使い捨ての受信先ではなく管理可能なメールアドレスを使いましょう。

よくある質問

Auth.jsから送信したメールがテスト用受信箱に届いたか、どう確認できますか？

自社アプリから操作した時刻やテスト識別情報を記録し、受信箱で宛先と本文を確認します。送信処理の成功ログだけでは受信の証拠になりません。受信できない場合は、送信ログ、メール配信側の結果、迷惑メール判定を分けて調べます。

メールのMagic Linkを開いたあと、ログイン完了は何で判断しますか？

リンクを開いた後の画面遷移だけで判断せず、アプリが期待するユーザーとして認識されているか、保護対象の画面へアクセスできるかを確認します。セッション管理はプロジェクトの実装に沿って検証し、メール到達とリンク処理の記録も別に残してください。

Magic Linkを何度も開いたとき、どの挙動を確認すべきですか？

新しいリンクの発行後に古いリンクを開く場合、同じリンクを再度開く場合、無効なリンクを開く場合を自社のテスト環境で確かめます。結果は実装や設定によって異なるため、共通の有効期間や失効ルールを前提にせず、画面表示とログイン状態を確認します。

テストメールのリンクが別環境へ移動するとき、最初に何を確認しますか？

メール本文のリンク先ホストとパスを見て、対象環境のサイトURL、コールバック先、メールテンプレートの設定を照合します。Auth.jsが常に同じURLを生成すると決めつけず、プロジェクトの設定と実際のメール内容を比較してください。