「メールが確認されていません」のHTTPステータス
すべてのHTTPステータスコードのリストを見ました。しかし、私には「電子メールが検証されていません」（認証/承認に使用される）のコードがないように見えます。同じ「問題」があったことはありますか？どのHTTPステータスコードを使用しましたか？
これは「クライアントエラー」なので、4で始まるコードである必要があると思います。
ステータスコードの4xxクラスは、クライアントが誤りを犯したと思われる状況を対象としています。
ステータスコードの
4xx（クライアントエラー）クラスは、クライアントがエラーを起こしているように見えることを示します。HEAD要求に応答する場合を除いて、サーバーは、エラー状況の説明と、それが一時的または永続的な状態であるかどうかを含む表現を送信する必要があります。これらのステータスコードは、すべてのリクエスト方法に適用できます。ユーザーエージェントは、含まれている表現をユーザーに表示する必要があります。
authenticationおよびauthorizationの場合、それぞれ401および403が使用される適切なステータスコードです。 。ステータスコードに関係なく、応答ペイロードでエラーの理由を常に説明する必要があります。
401無許可
このステータスコードは、HTTP認証の問題、つまり無効な資格情報に使用します。
401（未承認）ステータスコードは、ターゲットリソースの有効な認証資格情報がないため、リクエストが適用されていないことを示します。401応答を生成するサーバーは、ターゲットリソースに適用可能な少なくとも1つのチャレンジを含むWWW-Authenticateヘッダーフィールドを送信する必要があります。要求に認証資格情報が含まれている場合、
401応答は、それらの資格情報の承認が拒否されたことを示します。ユーザーエージェントは、新しいまたは置換されたAuthorizationヘッダーフィールドを使用してリクエストを繰り返すことができます（MAY）。401応答に前の応答と同じチャレンジが含まれ、ユーザーエージェントがすでに少なくとも1回認証を試みた場合、通常は関連する診断情報が含まれているため、ユーザーエージェントは同封の表現をユーザーに提示する必要があります。
403禁止
このステータスコードは、認証の問題に使用します。つまり、資格情報は有効ですが、アクセスを許可するには不十分です。
403（禁止）ステータスコードは、サーバーがリクエストを理解したが、承認を拒否したことを示します。要求が禁止された理由を公開したいサーバーは、応答ペイロード（存在する場合）にその理由を記述することができます。リクエストで認証資格情報が提供された場合、サーバーはそれらがアクセスを許可するには不十分であると見なします。クライアントは、同じ資格情報でリクエストを自動的に繰り返すべきではありません（SHOULDNOT）。クライアントは、新しい資格情報または異なる資格情報を使用して要求を繰り返すことができます。ただし、認証情報とは関係のない理由でリクエストが禁止される場合があります。 [...]
CodeCasterはコメントとして非常に明確な答えを提供していますが、正しい答えは時々適切ではありません。
まず、仕様に電子メールアドレスの言及がないことがわかります。同様に、靴のサイズ、鉄道模型のゲージ、犬の品種、その他多くのことについては言及されていません。 HTTPとは関係ありません。これは単なるデータ項目です。
認証の目的で使用するこのデータ項目に関連付けられた状態があるようですが、その状態やその適用方法については説明していません。 「検証されていない」状態とは、データ項目とサイトを操作しているユーザーとの間の唯一の関連付けがユーザーのアサーションであることを意味していると思います。さらに、これをトークンとして使用してユーザーを認証することを許可しません。
私はここで衒学者であるように見えるかもしれませんが、「電子メールが検証されていません」という他の有効な解釈があります。あなたはあなたの質問でより多くの情報を提供するべきでした。
あなたの話には別のギャップがあります：私たちはここでどの要求を取っていますか？繰り返しになりますが、私は、要求が認証の試みであると想定する自由を取ります。
この場合、リクエストに本質的に問題はありません。クライアントには本質的に何も問題はありません。サーバーには本質的に問題はありません。ユーザーに認証を許可しないことは、データに基づくポリシー決定です。
質問から欠落しているもう1つの重要な情報は、実際に要求を行っているものです。フォームがブラウザによって送信された場合、200 OK（または204、または200へのリダイレクト）以外のものをMSIEに返すと、デフォルトで、ブラウザに内部メッセージと送信するコンテンツではありません。
OTOHクライアントがユーザーデバイスで実行されているアプリケーションまたはAjaxリクエストである場合は、APIを制御し、独自のセマンティクスを定義できます。この状態を表す692ステータスコードを返したい場合は、692エラーコードを返すことができます。応答に独自のヘッダーを挿入することもできます（慣例により、これらは「X-」で始まる必要があります）。
定義された状態では、認証は失敗します。ただし、401応答を返すと、ブラウザにHTTP認証を試行するように求められますが、これでは問題は解決されません。
私見、最も近い既存のコードは403または 422 です。しかし、あなたが提供した情報に基づいて、それがあなたが使用すべきものであるかどうかはわかりません。