検証メールが届かない：壊れたステップを見つけよう

検証メールが遅れると、再送ボタンが明らかな答えのように感じられます。しかし、状況を悪化させることが多く、複数のメールが同時に届き、最新のコードだけが有効となり、どのリクエストがどのメールを生成したかが分からなくなります。

配信を一連のチェックポイントとして扱いましょう。確実に成功した最後のチェックポイントを見つけ、次のチェックポイントを調べます。

まず、証拠を固定する

別のメールをリクエストする前に、以下を記録してください：

送信元のページは開いたままにしておきましょう。2 分後に見つかったタイプミスでも、元のフォームに送信した値が残っていれば修正が容易です。

送信したアドレスと GPTMail が表示するアドレスを比較します。ローカルパート、すべてのドットや数字、ドメインサフィックスを確認してください。複数の受信トレイタブを開いている場合や、最近選択したドメインを変更した場合は特に注意が必要です。

次に、ドメインページでドメインが有効か確認します。アドレスが構文上有効でも、ドメインが無効化されていたり、GPTMail にルーティングされていない場合があります。

ウェブサイトが送信前にアドレスを拒否した場合、まだ配信問題は発生していません。別のサポート対象アドレスを作成し、再度送信してください。

ウェブサイト上の成功メッセージは、バックグラウンドジョブが作成されたことだけを意味する場合があります。送信者はまだキューイング中、レート制限中、またはメールの再試行中かもしれません。

再送する前に数分待ちましょう。サービスがアクティビティログを提供している場合、検証リクエストが記録されているか確認してください。自分が運営する製品の場合は、受信トレイを見るよりもアプリケーションキューやメールプロバイダーのイベントを確認します。

手動でリフレッシュし、到着時間でソートします。表示プレビューのサービス名だけでなく、期待する送信者と件名で検索してください。自動送信メールやマーケティングメールは異なるサブドメインから来ることがあります。

複数のコードが届いた場合は、最新のリクエストを使用してください。多くのシステムでは、置き換えが発行されるとすぐに以前のコードが無効になります。

無関係なプロバイダーから同じアドレスへ短いプレーンテキストのテストメールを送ります。

カスタムドメインの場合は、推測不要のカスタムドメイン MX 設定を参照してください。ライブテスト中に DNS をランダムに変更しないでください。変更ごとに新たな伝搬ウィンドウが発生します。

MX ルックアップは、リゾルバのタイムアウト、権威ネームサーバーの不一致、DNSSEC 検証失敗、またはレコードがまだ伝搬していないために一時的に失敗することがあります。「レコードが検出されません」は、特定の時点での特定のルックアップ結果であり、レコードが存在しなかった証拠ではありません。

権威 DNS の応答を問い合わせ、実際のターゲットと GPTMail が表示するターゲットを比較してください。一致すれば、待って再試行します。一致しなければ、権威レコードを修正します。

配信と検証は別々のシステムです。コードが無効になる理由は次の通りです：

新しいコードを1つリクエストし、その特定のメッセージが届くのを待って一度だけ使用してください。失敗した場合は、リクエスト時刻とメッセージ時刻を併せて報告します。

有用なレポートには、受信者アドレス、送信者アドレス、件名、UTC タイムスタンプ、2 番目の送信者が受信トレイに届いたかどうか、送信者が示す正確なエラーが含まれます。公開するログからは検証コードやプライベートリンクを削除してください。

「メールが来ない」は調査が困難です。「14:03 UTC にメッセージをリクエスト、14:05 に別プロバイダーが到着、期待した送信者は 14:15 までにメッセージもバウンスもなし」という情報が失敗側を特定します。

アカウントが重要で、サービスが別の検証方法を提供している場合はそれを利用してください。サインアップのリスクが低い場合は、新しいサポート対象アドレスを生成して再度開始しましょう。保持したいアカウントの唯一の回復手段として一時的な受信トレイに依存しないでください。