SMTP プロトコルは、メールボックスの可用性を確認する手段を提供するようには設計されていません。
電子メールを配信する場合、通常、次の手順が実行されます。
メールドメインのMXレコードを確認
へのメールで、 のsomebody@example.comMX レコードがあるかどうかが確認されexample.comます。複数ある場合は、優先度の高いものに連絡してメールを受け付けます。応答しない場合は、優先度の低い既存の MX に連絡します。
MX レコードがない場合、「A」レコードの検索example.comが行われ、その IP が接続されてメールが受け入れられます。
MXまたはAレコードに記載されているサーバーへの接続
受信メール サーバーに接続します。存在する場合、メールが配信される可能性があります。SMTP プロトコルでは、送信メールサーバーが受信メールアドレス、送信メールアドレス、そしてメール自体を送信する必要があります。
受信メール サーバーは、メールをユーザーのメールボックスに配信しようとします。
これは、いくつかの理由で失敗する可能性があります。そして、重要な情報は、送信メールサーバーがメールが受信されたという肯定的な応答を受け取り、接続が終了した後に、このステップが行われる可能性があるということです. したがって、送信メールサーバーは、配信が失敗したという手がかりを取得しない場合があります。
この場合、受信メールサーバーはバウンス メッセージを送信します。ただし、このバウンスメールは、エラー受信用に指定されたメールアドレスに送信されます。これは元のメール アドレスである可能性がありますが、別のアドレスである可能性もあります。さらに、バウンスを受信する責任のあるメールサーバーは、元のメールを送信したサーバーであってはなりません。
この時点で、電子メールが実際には非同期の情報交換媒体であり、信頼性がほとんど組み込まれていないことは明らかです。
多少の改善が期待できるテクニックもあります。通常、バウンス メッセージの送信は最善の方法ではありません。適切に構成されたメール サーバーは、メールボックスが存在しない、満杯であるなどの問題があるメールボックスのメールの受信を拒否します。
一方、メールの新しい大きなブラック ホールはスパム フィルターです。通常、これらはユーザーによって設定され、メール サーバーは既存のメールボックス宛てのメールを問題なく受信しますが、スパムは自動的に削除されるか、スパム フォルダに移動されて無視されます。
また、一時的な失敗状態でメールを配信しようとする試みに応答する、グレーリストのような技術もあります。通常のメールサーバーは後で試行し、最終的にグレーリスト タイマーが終了し (設定によっては 1 時間以上かかる場合があります)、実際の配信試行が行われ、実際の最終的な拒否または受け入れが行われます。一方、メールサーバーは、新しいスパムメールの波を検出するためのスパムフィルターが組み込まれていることを望んでおり、グレーリストは実際には少しの時間を稼ぐだけです. よく知られているメール サーバーによる通常の配信試行は、すぐに成功します。これは、スパム以外のメール配信が成功するとホワイトリストに登録されるためです。
実際のメールがどのように機能するかについてこれまで説明してきましたが、メールアドレスが実際に存在するかどうかを「単純に」検出する方法がないことがお分かりいただけたと思います。あなたができる唯一のことは、それが存在するかどうかを検出しようとすることです.メールボックスが存在しないことを明確に伝えられた場合、ターゲットメールサーバーが配信を拒否するため、おそらくそのターゲットにメールを配信しようとするべきではないと推測できます. .
他の結果は何も教えてくれません。また、メール アドレスが存在するかどうかを検出するには、メールを送信する必要があることにも注意してください - catch-22 の状況。
適切なバウンス管理と配信失敗検出を実装して、明らかに失敗しているメール アドレスを削除する必要があります。それ以外は検出できません。