メールを
アドレスが実在するかを知るために、相手にメールを送る必要はありません。メールシステムそのものを使ってアドレスを確認する手法がいくつかあります。このガイドでは、それぞれの手法と、有効な場面、限界を解説します。
送信せずにメールアドレスを検証するには、形式をチェックし、ドメインにメールサーバーがあることを確認し、メッセージの配信前に止めるSMTPハンドシェイクを実行します。確実な方法は手作業のコマンドラインプローブではなく、多層的な検証API または一括検証ワークフローです。キャッチオール、使い捨て、ロールベースの結果にも対応します。
送信せずに
メールアドレスを確かめるわかりやすい方法は、メールを送ってバウンスするかを見ることです。確かにわかりますが、これは最悪の方法です。バウンスはメッセージがメールボックスプロバイダーに届いた後で発生するため、その失敗はすでに送信元の評価にカウントされています。この方法でリストをテストすると、評価を損ないながら不正なアドレスを見つけることになります。また、実在する宛先には本物のメッセージが届くため、こっそりテストすることもできません。
送信せずに検証すれば、これが逆になります。キャンペーンを1通も送る前に、アドレスがメールを受信できるかを確認できます。受信トレイには何も届かず、バウンスも発生せず、評価にも影響しません。これが可能なのは、メールシステムがサーバー同士で問い合わせ合えるプロトコルの上に成り立っており、検証ツールは実際の配信まで進めずにその問い合わせだけを行えるからです。
手法は、単純な形式チェックから受信サーバーとの完全なやり取りまで、いくつかあります。それぞれが問いの一部に答えるもので、各手法で何がわかり、何がわからないのかを理解することが、うまく使いこなす鍵です。
| 手法 | 証明できること | 主な限界 |
|---|---|---|
| 構文チェック | アドレスの形が正しいこと。 | ドメインやメールボックスが存在することは証明できません。 |
| MXルックアップ | ドメインがメールサーバーを公開していること。 | 特定のメールボックスについては何もわかりません。 |
| SMTPハンドシェイク | その宛先アドレスに対するサーバーの応答。 | キャッチオールドメイン、グレーリスティング、スロットリングによって結果が曖昧になることがあります。 |
| 検証サービス | リスクカテゴリ付きの多層的な到達性の結果。 | 不確かなサーバーの挙動には、推測ではなく正直なラベルが必要です。 |
手法1：構文の
最も高速なチェックは純粋に構造的なものです。メールアドレスの形式はRFC 5322という仕様で定められており、正しいアドレスがどのような形かを正確に定義しています。ローカル部、@記号、ドメインで構成され、使える文字とその位置にルールがあります。
構文の検証では、アドレスをそのルールに照らしてテストします。@記号がない、空白や使えない文字を含む、ドメインがない、または不正な形式である、ローカル部が仕様に違反している、といったアドレスを検出します。ネットワーク接続をまったく必要としないため即座に無料で実行でき、不正なアドレスのかなりの割合を除外できます。その多くはデータ入力時の単純な入力ミスです。
限界は根本的なものです。構文の検証で証明できるのは、アドレスの形が正しいことだけです。アドレスが存在することは証明できません。valid.but.fake@gmail.com というアドレスは構文としてはまったく正しいものの、実在するメールボックスではない可能性がきわめて高いでしょう。構文の検証は最初のフィルターとして扱い、決して最終判定にしないでください。
手法2：
次のステップでは、アドレスからそのドメインへと対象を移します。メールを受信できるドメインはすべて、Mail Exchangerの略であるMXレコードというDNSレコードを公開しています。これらのレコードは、そのドメインに代わってメールを受け付けるサーバーを示します。
MXルックアップでは、ドメインのMXレコードをDNSに照会します。有効なMXレコードがあれば、そのドメインはメールを受信するよう設定されており、接続先が存在します。MXレコードがなければメールはまったく受信できず、つづりに関係なくそのドメインのアドレスはすべて無効です。このステップは、企業の廃業やブランド変更によって古いリストに頻繁に現れる、使われていないドメインの検出に優れています。
限界は、ドメインのチェックが確認する階層を誤っている点です。gmail.com にMXレコードがあると確認できても、わかるのはGoogleがメールを受信できるということだけです。特定のGmailメールボックスが存在するかどうかは何もわかりません。ドメインとMXの検証で対象は絞り込めますが、個々のアドレスまでは判定できません。
手法3：SMTP
これは、送信せずに特定のメールボックスを実際に調べる手法です。メールアドレスへの「ピング」と呼ばれることが多いものの、この名称は誤解を招きます。ネットワーク診断に使うICMPのpingコマンドとは無関係です。メール検証におけるピングとは、受信サーバーとSMTPでやり取りすることを指します。
SMTP（Simple Mail Transfer Protocol）は、メールサーバー同士がメッセージを受け渡すための言語です。通常の配信は、決まった順序のコマンドに従って行われます。SMTPチェックはその手順をたどりますが、1ステップ手前で止まります。
仕組みは次のとおりです。検証ツールは、MXルックアップで見つかった宛先のメールサーバーへの接続を開きます。EHLOまたはHELOで挨拶を交わし、自身を名乗ります。MAIL FROMコマンドで送信者を宣言します。続いてRCPT TOを発行し、検証対象のアドレスを指定します。受信サーバーはステータスコードで応答します。250のコードは、サーバーがそのアドレス宛てのメールを受け付けることを意味します。550のコードはアドレスを拒否していることを意味し、通常はメールボックスが存在しないことが原因です。検証ツールはそのコードを読み取り、QUITを発行して接続を閉じます。DATAコマンドは送信しません。DATAは実際のメッセージ本文が送られるステップであり、やり取りがDATAの前に終わるため、メールが配信されることはありません。メールボックスはチェックされ、宛先には何も届きません。
これが、送信せずに検証する仕組みの核心です。そして、本当の難しさが始まるのもここからです。
SMTP
SMTPチェックは確実そうに聞こえますが、よくあるサーバーの挙動のいくつかによって、手作業の素のチェックは信頼できなくなります。
キャッチオールドメイン
一部のドメインはキャッチオールとして設定されており、メールボックスが存在するかどうかに関係なく、そのドメインのあらゆるアドレス宛てのメールを受け付けます。キャッチオールのサーバーは、実在するアドレス、つづりを間違えたアドレス、完全にランダムなアドレスのいずれにも250のコードを返します。そのため、キャッチオールドメインに対するSMTPチェックでは、答えが常にイエスとなり、メールボックスレベルで確かなことは何もわかりません。キャッチオールを検出するには、ランダムなアドレスでドメインを調べ、それも受け付けられることを確認する必要があります。これは品質スコアではなく検出であり、そのアドレスを個別に確認できないことを示します。
グレーリスティング
一部のサーバーは、見慣れない送信者を初めて検知した際に意図的に一時的な失敗コードを返し、正規のメールサーバーがすぐに再試行するのを待ちます。この一時的なコードを恒久的な失敗と読み取る単純なチェックは、まったく問題のないアドレスを誤って無効と判定してしまいます。正しく扱うには、一時的なコードを認識し、それを最終的な答えとして扱わないことが必要です。
プローブの
これが手作業によるチェックにとって致命的な問題です。GoogleやMicrosoftなどの大手プロバイダーは、単一のIPアドレスからの繰り返しのSMTPプローブを監視し、スパマーが有効なアドレスを探るために行うような偵察行為とみなします。その対応として、プローブ元のIPを完全にブロックします。そのため、自社サーバーやTelnetセッションから手作業のSMTPチェックでリストを検証しようとすると、いくつか答えが得られたところでIPがブロックされ、残りのチェックは本来とは異なる理由で失敗します。手作業のSMTP検証はスケールせず、大量になるとまったく機能しません。
手法4：専用の
ここまでの手法はそれぞれパズルの一部を検証するもので、単独ではどれも明確な弱点があります。専用の検証サービスは、それらすべてを組み合わせて実行し、エッジケースを正しく処理し、手作業のチェックでは不可能な規模で運用するために存在します。
VeriMailsは、各アドレスにすべてのチェックを重ねて実行します。RFC 5322に基づく構文検証、MXとDNSのルックアップ、そして前述のライブSMTPハンドシェイクを、メッセージを一切届けずに行います。そのうえで、アクセプトオールのドメインを誤って有効と報告せず正しく識別するキャッチオール検出、一時的な使い捨てアドレスにフラグを立てる使い捨てドメイン検出、info@ や support@ のようなアドレスにラベルを付けるロールベース検出を加えます。グレーリスティングなどの一時的な応答を認識し、誤って無効と判定せず正しく分類します。さらに検証用に設計されたインフラから実行するため、手作業のチェックを阻むプローブのブロックの問題に妨げられません。
その結果、メールを一切送らずに実用的な検証が可能になります。 REST API を使えば1件のアドレスをリアルタイムで検証でき、登録フォームの送信をその場でチェックするのに最適です。また、一括CSV検証を使えばキャンペーン前にリスト全体をクリーニングできます。料金は1件あたり$0.0019から。10,000クレジットで$19、最大5,000,000クレジットで$1,499のパッケージがあり、年払いのプランは月額$12.50からです。すべてのアカウントに登録時に100クレジットが無料で付与されます。クレジットカードは不要で、有効期限もありません。実際のメールを送ることなく実際のリストを検証し、その違いをご自身で確かめてください。