2026 .NET 11 RC.3のメール認証をどうテストする？

まず決めるのはメール認証テストの合格範囲

ここで確認する対象は、自社のASP.NET Coreアプリが行う登録とメール認証です。.NET自体にメール送信機能が追加されたかを確かめる記事ではありません。RC.3はテスト時点で使用している候補版として扱い、RC版固有のメール機能があるとは推定しないでください。

検証結果は、次の証拠に分けて記録します。

• アプリの起動と登録処理：登録要求を受け付け、アプリの処理が進んだか。
• メール送信処理への受け渡し：送信インターフェースが呼ばれ、宛先や本文が渡されたか。
• 管理下の受信先での実受信：実際にメールが届き、内容を読めるか。
• 確認リンクの処理：リンクを開いたとき、アプリが想定した応答を返すか。
• アカウント状態：確認処理後、対象アカウントが自社仕様どおりの状態になるか。

送信処理への受け渡しを合格にするテストと、受信箱への到着までを合格にするテストは別物です。どちらを今回の受け入れ条件とするか、テスト開始前に決めます。

テスト方式ごとに証明できる範囲

同じ登録フローでも、メール送信処理を差し替える統合テストと、外部へ実際に送る確認では、得られる証拠が異なります。ASP.NET Coreの公式資料にある統合テストの構成方法を参考にしつつ、検証目的に合わせて方式を選びます。

テスト用の送信差し替えは、アプリが何を送ろうとしたかを検査する仕組みです。外部の配送経路や受信側の判定を通らないため、受信成功の証拠にはなりません。

隔離した環境と再現条件

最初に、テスト実行に使うSDKとプロジェクトのターゲット設定を記録します。複数の開発環境でSDK選択がずれないようにする場合は、Microsoftのglobal.jsonによるSDK選択の説明に沿って、リポジトリ側の設定と実行環境を照合します。

次に、アプリ設定、テストアカウント、受信先を自社の試験用または利用許可を得た環境に限定します。実運用の認証情報や、実在する利用者の氏名・メールアドレスなどを持ち込まず、合成データを使います。データの扱い方をチームでそろえる際は、テストデータとプライバシーの考え方も確認できます。

実行前に、少なくとも次の点を記録しておくと、失敗時に再現条件を追いやすくなります。

• 使用したSDKとターゲットフレームワークの設定。
• 登録に使う合成データと、対象環境が開発・検証・本番のどれか。
• 送信処理を差し替えるのか、外部へ実際に送るのか。
• 受信確認の担当者と、証拠を保管する場所。
• テストに使う設定が本番の接続情報や認証情報を参照していないこと。

ASP.NET Core統合テストで送信内容を検査

WebApplicationFactoryでテスト用ホストを作り、メール送信インターフェースを記録用の実装に差し替えます。登録要求を実行した後、送信処理が呼び出されたか、宛先が登録対象と一致するか、本文に自社アプリが生成した確認リンクが含まれるかを確認します。公式のASP.NET Core統合テスト資料は、アプリのテストホストを使う構成を確認する際の基準になります。

期待するリンク形式や文面は、製品の実装に合わせてアサートします。テスト用の差し替えが渡された値を記録しているだけなら、メールサーバーへの接続や外部配送は検査していません。ログに「送信済み」と出た場合も、そのログがどの処理段階で記録されるかを確かめ、実受信の代用にしないでください。

アカウント確認処理の考え方は、MicrosoftのASP.NET Coreアカウント確認とパスワード回復の説明で確認できます。掲載されている例をそのまま現行アプリに当てはめず、利用中の実装とフレームワーク設定に合うか確認します。

よくある疑問：模擬送信から実受信まで

FAQ

WebApplicationFactoryの結果だけで、確認メールの到着まで分かりますか？
分かりません。送信処理をテスト用実装に置き換えた場合、確認できるのはアプリから渡された宛先や内容、呼び出しの有無などです。外部送信を行わない構成なら、配送経路も受信箱も通過しません。実受信を合格条件に含める場合は、別の受信テストを組み合わせます。

模擬送信と実際の受信を、テスト結果にどう記録すればよいですか？
アプリの登録要求、メール送信インターフェースへの受け渡し、受信先での到着確認を別項目で記録します。送信ログやAPIの成功応答は、実受信を確認した記録とは分けてください。これにより、アプリ処理の失敗と、受信を確認できなかった状態を混同せずに調査できます。

確認リンクを開くテストでは、何を合格条件にしますか？
受信したメールからリンクを開き、自社アプリが想定した応答を返すことと、対象アカウントの状態が自社仕様どおり変化することを確認します。リンクの有効期間や再利用の可否は製品ごとの実装で異なります。共通ルールとして決めつけず、実装上の条件をテストに反映してください。

正式版の公開後、どの検査を再実行しますか？
公式のバージョン情報と互換性変更を確認したうえで、影響を受けるビルドと回帰テストを再実行します。メール送信処理、受信先での到着、リンクを開いた後の応答、アカウント状態を分けて確認してください。RC版の結果をそのまま正式版の合格根拠として扱わないことが重要です。

管理下の受信先で実受信を確認

統合テストでアプリが作った内容を確認した後、隔離した環境から管理下のテスト用メールアドレスへ実際に送ります。受信箱で到着を確認し、宛先、本文の読みやすさ、確認リンクの内容を検査します。テストアカウントと受信先は自社で管理するもの、または利用許可を得たものに限定してください。

記録は、アプリ側の送信証拠と受信側の証拠に分けます。たとえば、登録要求の結果、送信処理に渡った内容、受信箱で確認できた内容を別々に保存します。「送信処理が成功した」というログしかない場合は、受信確認は未完了として扱います。

受信先を使い捨てにするか、長期に管理するかは、再試験やリンクの追跡が必要かで選びます。受信先の有効期間と確認タイミングを整理する場合は、受信先の有効期間を考えるための案内を参照し、実際のサービス条件は利用前に確認します。

確認リンクからアカウント状態まで閉じる

受信したメールのリンクをテスト環境で開き、アプリの応答とアカウント状態を照合します。リンクを開けない、再使用したときの結果が想定と異なる、アカウント状態が変わらない場合は、利用したテストデータ、操作手順、応答、状態の確認方法を一組にして記録します。

リンクの有効期間や再使用の扱いは、アプリの実装に基づいて判定します。業界共通の値を想定して合否を決めるのではなく、自社の仕様と実装が一致しているかを確認してください。

失敗箇所の切り分けと正式版後の再確認

結果を見て、次のように調査先を分けます。

• 登録処理から送信呼び出しまで進まない場合は、登録処理、依存性注入、テスト設定を確認します。
• 宛先や確認リンクが誤っている場合は、アプリ側の生成処理と設定値を確認します。
• アプリ側の送信記録はあるが受信を確認できない場合は、受信先と外部送信を含む経路を別途調査します。
• リンクを開いても状態が変わらない場合は、リンクの処理とアカウント状態の更新を再現します。

Microsoftのダウンロードページでは、2026年10月25日が最新の公開日として示され、.NET 11.0.0-rc.3が掲載されています。公式の.NET 11ダウンロード情報に基づく状態確認であり、RC.3にメールテスト機能が追加されたという意味ではありません。Microsoftの説明では.NET 11正式版は2026年11月の予定ですが、公開日とRC.3以後の変更は公式発表で確認してください。

正式版が公開されたら、.NETのライフサイクル方針と.NET 11の互換性変更一覧を確認します。その後、SDK選択、アプリの統合テスト、管理下の受信先での実受信、リンク処理、アカウント状態のうち、変更の影響を受ける自社の回帰テストを再実行します。RC.3の結果だけで正式版の動作を保証しないことが、移行時の見落としを減らします。

最終更新：2026年11月5日。 RC.3の公開状態と日付はMicrosoft公式ダウンロードページ、正式版の予定と互換性確認はMicrosoftの.NET関連資料で照合しています。

アプリ内の検査を終え、実際の受信まで自社環境で確認したい場合は、テスト専用の受信先を使う方法もあります。temprapidを候補にする際は、受信機能や利用条件を事前に確認し、機密情報や本番アカウントには使わず、自社アプリの検証に限って利用してください。

よくある質問

.NET 11 RC.3の統合テストで、確認メールの受信まで証明できますか？

証明できる範囲は、テストの構成によって異なります。WebApplicationFactoryと送信処理のテスト用差し替えを使えば、登録処理が送信処理を呼び出したことや、宛先・本文・確認リンクの生成を検査できます。一方、外部のメール配送や受信箱への到達は確認できません。実受信の証拠が必要なら、隔離した環境から管理下の受信先へ送り、受信側も別に確認します。

ASP.NET Coreのメール認証で、模擬送信と実際の受信はどう区別しますか？

模擬送信では、アプリがメール送信インターフェースを呼び出した事実と、渡された内容を検証します。これはアプリ内の処理を確認する方法です。実際の受信確認では、テスト環境からメールを送り、管理下の受信箱で到着と内容を確かめます。アプリのログ、送信サービスへの受け渡し、受信箱での確認は別々の証拠として記録してください。

WebApplicationFactoryで登録確認メールの流れを確かめるには？

テスト用ホストで登録リクエストを実行し、依存性注入されたメール送信インターフェースを記録用の実装に差し替えます。記録した呼び出しから宛先、件名や本文、確認リンクを取り出し、自アプリの仕様と照合します。リンクを実際に開く検査は別のテストとして扱い、テスト用データベース上でアカウント状態が期待どおり変わることまで確認します。

.NET 11正式版の公開後、RC.3でのメールテストは何を再確認しますか？

まず公式ダウンロード情報とライフサイクル情報で、正式版の公開状態と対象のSDKを確認します。そのうえで、SDKの選択、ビルド、統合テスト、メール送信処理、実受信、確認リンクの応答、アカウント状態を順に再実行します。互換性変更の一覧も確認し、影響がありそうな箇所を優先して回帰テストします。正式版の日付や変更内容は、公式発表で確認できた範囲だけを採用してください。