メールアドレス検証の仕組み：8つの段階

要点を先に#

メールアドレス検証は、アドレスを、負荷が段階的に高くなる一連のチェックにかけ、決定的な結果が出た時点で打ち切ります。負荷の低いチェックは、その場でローカルに完結します。たとえばメールアドレスの形になっているか、ドメインがそもそもメールを受け付けるかといったものです。これらを通過したアドレスだけが、メールサーバーにメールボックスの存在を実際に問い合わせる、時間のかかるネットワーク経由のステップに進みます。Qualisendは8つの異なる段階を実行します。この記事では各段階について、何を証明でき、何を証明できないか、どの判定が出るかを順に解説します。

順序が重要なのは、各段階がフィルターだからです。メールサーバーを持たないドメインのメールボックスを確認するためにSMTP接続を開く意味はなく、@のないアドレスのドメインのDNSを調べる意味もありません。負荷の低いチェックで先に除外し、負荷の高い問いは最後に回します。

段階1：構文#

最初のチェックは、その文字列が構造的に有効なメールアドレスになっているかどうかです。@が1つだけあるか、ローカル部が妥当か、ドメインがドメインらしい形かを確認します。末尾のカンマ、スペース、TLDの欠落、@の重複といった打ち間違いを見つけられます。処理の外に出ないため、即座に完了し、コストもかかりません。

構文の検証は必要ですが、それだけでは不十分です。definitely-not-real@ some-made-up-domain.comは構文としては完全に有効ですが、配信はまったくできません。正規表現だけで「検証」してここで止めているなら、確認しているのは綴りであって、到達率ではありません。この段階で失敗すると、undeliverableが理由invalid_emailとともに返されます。

段階2：ドメインとMXレコード#

次に検証ツールは、DNSに対して、そのドメインがそもそもメールを受信できるかを問い合わせます。ドメインが解決されるか、メールサーバーを指すMXレコード（または使用可能なAレコードへのフォールバック）が公開されているかを確認します。メールの配送先がないドメインは、誰宛てのメールも受け付けられません。そのため、この段階は1回のDNSルックアップで、綴りを誤った会社名や失効したドメイン、存在しないTLDなど、無効なドメインをまとめて除外します。

ここで失敗したドメインは、undeliverableが理由invalid_domainとともに返されます。通過したドメインには、メールの配送先があります。ただし、対象のメールボックスが存在することは、まだ証明されていません。それを確認するまでには、あと4段階あります。

段階3：使い捨てドメイン#

ドメインの中には、使い捨ての受信トレイを提供するためだけに存在するものがあります。割引コードを入手するために使われ、その後は二度と確認されない10分間アドレスのようなものです。Qualisendは、ドメインを、更新され続けている使い捨てサービスの一覧と照合します。一致しても、そのアドレスが今日メールを受け付けないという意味ではありません。明日には価値がなくなるアドレスという意味なので、信頼せず、フラグを付けてスコアを下げます。

使い捨てアドレスは、riskyが理由low_qualityと使い捨てのサブフラグとともに返されます。そのアドレスに送信するかどうかは別の判断で、役割アドレス、使い捨てアドレス、フリーメールアドレスで扱っています。

段階4：役割アカウント#

役割アドレスは、info@、support@、billing@のような共用のメールボックスで、個人ではなくチームやチケット管理システムが読むものです。多くの場合は実在し、配信も可能ですが、マーケティングでは扱いにくい性質があります。特定の個人が所有しておらず、エンゲージメントの指標を歪め、迷惑メール報告を招きやすいからです。そのため検証ツールは、大文字小文字を区別せず、+tagのサフィックスも無視してこれらを検出し、個人の受信トレイと同じには扱わずフラグを付けます。

役割アドレスはdeliverableのままですが、役割のサブフラグが付きます。特定の配信に含めるかどうかは、お客様が判断できます。繰り返しになりますが、送信するか除外するかの判断は、別のガイドで扱っています。

段階5：入力ミスの検出#

ネットワークの往復を行う前に、検証ツールは、ドメインが一般的なプロバイダーに近い綴り違いではないかを確認します。たとえば、gmail.comに対するgmial.comや、hotmail.comに対するhotmial.comです。ここではダメラウ・レーベンシュタイン距離（挿入、削除、置換、入れ替えを数える編集距離のアルゴリズム）を使います。入力ミスの可能性が高い場合は「もしかして」という候補を提示します。単に拒否するよりはるかに有用で、登録時にその場で修正を提案して、購読者を失わずに済みます。

入力ミスの検出は、それ単独では判定ではなく提案です。それでも、効果が最も大きい段階の1つです。アドレスを取得する時点で入力ミスを見つければ、ハードバウンスと連絡先の喪失を一度に防げるからです。

段階6：SMTPメールボックスプローブ#

ここまではすべてローカルで、即座に完了します。この段階から、実際にコストがかかります。検証ツールは、ドメインのメールサーバーに接続し、HELO、MAIL FROM、RCPT TO:<address>という配信のやり取りを開始します。そして、メッセージを一切送信せずに、サーバーの応答を読み取ります。RCPT TOへの応答は、メールボックスが存在するかどうかについて、実際の答えに最も近いものです。

• 250/251 → サーバーが宛先を受け入れる → deliverable、accepted_email
• 550系 → 恒久的な拒否、該当ユーザーなし → undeliverable、rejected_email
• 4xx → 一時的な保留で、多くはグレーリスティング → 再試行し、続く場合はunknown
• それ以外、またはタイムアウト → unknown

この段階では、応答のテキストとコードから、2つの特別な状態も読み取ります。452/552または「over quota」のメッセージはメールボックスが存在するものの容量がいっぱいであること（risky）を、「disabled/suspended」のメッセージはアカウントが無効であること（undeliverable）を示します。これらの応答の仕様は、SMTPレスポンスコードの解説に専用のリファレンスがあります。

段階7：キャッチオール検出#

SMTPの250が意味を持つのは、存在しないアドレスに対してサーバーが拒否するはずの場合だけです。そこで検証ツールは、対象のアドレスと並行して、同じドメインに意図的にでたらめなメールボックスをプローブします。サーバーがそれも受け入れた場合、そのドメインはすべてを受け付けるキャッチオールであり、対象のアドレスに対する250は何の証明にもなりません。そのアドレスは、riskyが理由low_deliverabilityとキャッチオールのフラグとともに返され、deliverableに切り上げられることはありません。

この段階は、業界で最も誤って説明されることが多く、そのため専用の主要記事を用意しています。率直にまとめると、キャッチオールドメインのメールボックスは確認できません。スコアリングをどれだけ工夫しても、それは変わりません。

段階8：スコアリングと判定#

最終段階では、あらゆるシグナルを1つにまとめます。SMTPの判定、サブフラグ、ドメインのレピュテーション、メールボックスがフリーメールかどうかといった情報です。これらから、1つのステータス（deliverable | risky | undeliverable | unknown）、理由コード、0～100の信頼度スコアが得られます。ステータスは取るべき対応を、理由とサブフラグはその背景を示し、スコアは同じステータス内でアドレスを順位付けします。重要なのは、すべての判定が根拠を伴って提供される点です。MXプロバイダーやプローブの詳細が付くため、数値はブラックボックスではなく、検証が可能です。

8つの段階でも分からないこと#

これだけ徹底したパイプラインなら、どのアドレスにも明確な可否が出るはずだと思われるかもしれません。実際にはそうならず、その限界を率直に述べておく価値があります。

• キャッチオールドメインでは、確実性は「risky」止まりです。 段階7でどのメールでも受け入れるサーバーだと分かった場合、段階6の250は何も教えてくれません。何段階実行しても、そのメールボックスは確認できません。送信せずにこれを解決できる検証ツールはなく、解決できると主張するものは推測にすぎません。
• グレーリスティングやレート制限を行うサーバーでは、unknownにならざるを得ないことがあります。 段階6が制限時間内に4xxの保留しか得られなければ、誠実な判定はunknown、つまり後で再試行することです。有効か無効かを無理に作り出すことはしません。
• 検証はスナップショットです。 今日deliverableと確認されたアドレスも、転職や受信トレイの放棄によって、明日には無効になることがあります。そのため大規模な送信の前に再クリーニングすることが重要であり、バウンス率の上昇は再検証すべきシグナルです。
• エンゲージメントは、検証では測れない唯一の要素です。 何も開封しないdeliverableなアドレスは、到達率の足かせになりますが、パイプラインには見えません。検証が示すのは、アドレスがメールを受信できるということであり、持ち主がそのメールを受け取りたいかどうかではありません。

これらはパイプラインの欠陥ではなく、どんな検証でも知り得ることの限界です。その限界がないかのように振る舞うツールこそ、信用すべきではありません。

無料チェッカーが段階5までで止まる理由#

無料メールチェッカーが実行するのは、ローカルで完結する段階1から5までで、SMTPプローブの手前で意図的に止めています。これは機能を制限した製品ではなく、誠実な境界線です。段階1～5では、アドレスを除外できます（構文の不正、メールの配送先なし、使い捨て、明らかな入力ミス）。しかし、メールボックスの確認やキャッチオールの検出はできません。それには、レピュテーションの高いIPから実際のSMTPのやり取りを開く必要があるからです。実在するメールボックスを確認できると主張する無料のブラウザツールは、段階6を実行していないか、そのことについて誠実ではありません。無料版と完全版のトレードオフは、専用の比較記事で解説しています。