送信する前にメールアドレスを確認する方法

バウンスしたメールが教えてくれるのは、送信する前に分かっていたかもしれないこと、つまり、そのアドレスが存在しないということです。アドレスの出どころが、登録フォームではなく、ウェブサイト、名簿、名刺であるコールドメールでは、どのリストでも、一部は古くなっています。

このガイドは、本人が登録に同意する形で作ったのではないリストにメールを送ろうとしている、営業チーム、創業者、代理店の方向けです。当社（Outreach）は、アドレスがメールを受け取れるかどうかが分かる3つの確認、その確認が機能しなくなる場面、そして、それでもメッセージが失敗したときに受け取るバウンスコードの読み方を説明します。

先に短く答えると、メールを送らなくても、アドレスが存在することは通常は確認できますが、いつもではありません — そして、確認できない場面を知っておくことは、答えそのものと同じくらい役に立ちます。

送信する前に、メールアドレスを確認すべきなのはなぜですか？

メールサービス事業者が、送信者に無効なアドレスを取り除くよう求めており、バウンスは1通ごとに、誰にも届かなかったメッセージだからです。YahooのSender Hubのベストプラクティスには、「無効な受信者を、速やかにリストから削除してください」とあります。Googleのメール送信者のガイドラインは、「何回もメールが返送された受信者を自動的に登録解除する」こと、そして「メールがバウンスされ始めたり、遅延し始めたりした場合は、SMTPエラー率が低下するまで送信量を減らす」ことを求めています。

簡単に言えば、メールサービス事業者は、あなたが無効なアドレスをどう扱うかを見ています。送信する前に確認しておけば、あとで対処するバウンスが減り、キャンペーンが何人の実在の人に届いたかも、より正確に分かります。

メールアドレスを確認する手順は、どのようなものですか？

順番に3つの確認を行います：アドレスの形式が正しいか、そのドメインにメールサーバーがあるか、そしてそのサーバーが、そのメールボックスは存在すると答えるかです。各ステップは、前のステップでは見つけられない問題を見つけます。

ステップ3を通過することは、送信せずに得られる最も強い手がかりです。ただし、このあと見るように、サーバーによっては、実在するかどうかにかかわらず、すべてのアドレスに同じ答えを返します。

メールアドレスの構文は、どう確認しますか？

@がちょうど1つあり、その前に有効に見える部分があり、後ろに実在するドメインがあることを、SMTPの標準が定める長さの制限の範囲内で確認します。RFC 5321は、「ユーザー名またはその他のローカル部の最大の合計の長さ」（@より前の部分）を64オクテット、ドメインの最大の長さを255オクテットと定めています。

構文の確認で見つかるのは、明らかなものです：sales@@example.com、info@example、ウェブページからコピーしたときの末尾の空白、ドットの代わりに入力したカンマなどです。構文の確認は安くて一瞬で終わるため、必ず最初に行います。分からないのは、そのアドレスの先に誰かがいるかどうかです。jane.doe@example.com は、Janeがそこで働いているかどうかにかかわらず、形式としては完全に正しいものです。

MX検索は、どのように働きますか？

そのドメインのメールをどのサーバーが受け取るかをDNSに尋ね、なければ、そのドメインのアドレスはメールを受け取れません。MX（メール交換）レコードは、ドメイン宛てのメールを受け付けるサーバーを指しています。これを調べると、そのドメインがそもそもメールを受け取れる設定になっているかどうかが分かります。

標準によると、結果は3通りです：

• MXレコードが見つかった。ドメインにはメールサーバーがあるので、ステップ3に進みます。
• ドメインが存在しない。RFC 5321は、「存在しないドメインのエラーが返された場合、この状況はエラーとして報告されなければならない（MUST）」としています。そのアドレスは使えません。
• MXレコードはないが、ドメインは存在する。RFC 5321は、そのアドレスは「暗黙のMXに関連付けられているかのように扱われる」としており、メールはそのドメイン自身のアドレスレコードに送られます。つまり、MXがないからといって、自動的に行き止まりになるわけではありません。

「メールを受け付けない」という明示的な合図もあります。RFC 7505は「ヌルMX」を定めています — 優先度が0で、サーバー名が「.」のMXレコードが1つだけのもので、「ドメインへのすべてのメール配信の試行を、直ちに失敗させる」ものです。これが見つかったら、そこで止めてください：そのドメインは、メールを受け取らないと宣言しています。

SMTPでのメールボックス確認は、メールを送らずに、どのように行いますか？

チェッカーは、ドメインのメールサーバーに接続して配信を始め、受信者を指定し、サーバーの返答を読み、メッセージの内容を何も送らずに接続を切ります。SMTPの用語で言えば、接続し、EHLO、MAIL FROM、RCPT TO:<address> を送り、返答コードを読み、そして QUIT します — 実際のメッセージを送る DATA のステップは、一度も行われません。

重要なのは、RCPT TO への返答です。RFC 5321は、そのコードを次のように定めています：

VRFY コマンドで、サーバーに直接尋ねればよいのではないでしょうか？それは、サーバーがこれをオフにすることが認められているからです。RFC 5321の第7.3節は、セキュリティ上の理由で VRFY を無効にすることをサイトに認めており、そうするサーバーは「252の応答を返さなければならない（MUST）」としています — これは、「はい」でも「いいえ」でもない返答です。だからこそ、チェッカーは代わりに RCPT TO の経路を使います。

2026年9月の当社自身のテストでは、RCPTの方法は、既知の小さな集合に含まれる6つのアドレスすべてを、正しく判定しました：バウンスしたことが分かっていた3つのアドレス、使えている2つのアドレス、そしてキャッチオールのドメインにある1つのアドレスで、これは確認できないものと正しく分類しました。

キャッチオールのドメインとは何で、なぜ確認できないのですか？

キャッチオールのドメインは、実在するかどうかにかかわらず、どのアドレス宛てのメールも受け付けるため、そのサーバーはすべての受信者に「250 OK」と答え、送信前の確認では何も分かりません。会社によっては、綴りを間違えたアドレスでも誰かに届くように、メールをこのように設定しています。ほかには、いったんすべてを受け付け、あとで振り分けるゲートウェイを使っているところもあります。

キャッチオールは、ほぼ確実に存在しないアドレス、たとえば同じドメインの長いランダムな文字列について、サーバーに尋ねることで見つけられます。サーバーがそれも受け付けるなら、そのサーバーからのすべての「はい」には意味がありません。

どのくらい多いのでしょうか？2026年9月のテストで、当社（Outreach）は、収集した200件の企業の連絡先（大半は韓国の企業）から選んだ25のメールドメインに、でたらめなアドレスでRCPTの確認を送りました。約74%のドメインは正直に答え、偽のアドレスを拒否し、約25%はそれを受け付けました — キャッチオールだったのです。これは、1つの市場の1つの標本であり、普遍的な割合ではないと受け止めてください。大事なのは、まれではないということです。

キャッチオールのアドレスについて、誠実な結果は「確認できない」です。確かめる方法は送信するしかなく、それは判断が分かれるところです：企業自身のウェブサイトに公開されているアドレスは、名前のパターンから推測したアドレスよりも、確実性が高い選択です。

一部のメールサーバーが確認を拒否するのは、なぜですか？

一部のメールサーバーは、受信者について問い合わせてよい相手を制限しているため、答える代わりに、応答を遅らせたり、一時的に拒否したり、接続を切ったりします。拒否は、たいてい次のような形で現れます：

• すべての受信者に対して、あとで再試行するよう求める、一時的な4xxの返答。
• メールボックスではなく、ポリシーや評判に言及する5xxの返答 — たとえばエンハンストコードの5.7.1で、RFC 3463はこれを「配信が許可されていない、メッセージが拒否された」と説明しています。
• 返答がまったくない、または接続が切られる。

これらのどれも、メールボックスが存在するかどうかは教えてくれません。優れた確認ツールは、これらを「無効」ではなく「不明」と報告します — サーバーが慎重だったというだけで、実在するアドレスを使えないものとして扱うと、良い連絡先を捨てることになるからです。

ホスティング事業者の中には、SMTPのポートである25番ポートの外向きの接続をブロックするところもあり、そこで動いているチェッカーは、メールサーバーにまったく届きません。この場合も、正しい答えは「存在しない」ではなく「確認できない」です。

送信したあとのバウンスコードは、どう読みますか？

エンハンストステータスコードの最初の数字を見ます：5は恒久的、4は一時的という意味です。次に、真ん中の数字が、どの種類の問題かを示します。RFC 3463は、class.subject.detail という形式でコードを定めています：

• 5.x.x — 恒久的な失敗：「現在の形式のままメッセージを再送しても、解決する見込みは低い」。
• 4.x.x — 持続的な一時的失敗：「将来の送信は成功する可能性がある」。

アドレスに問題がある場合に、最もよく見るコードは次のとおりです：

最後の行は重要です。5.7.xのコードは、通常、メールボックスがないのではなく、受信側のサーバーがあなたを拒否したという意味です。連絡先を削除する前に、SPF・DKIM・DMARCの設定を確認してください。

1つのアドレスを無料で確認するには、どうすればよいですか？

当社の無料メールアドレスチェッカーに入力すると、構文、MX、メールボックスの確認を行い、3つのうちのいずれかを伝えます。新規登録は必要ありません。チェッカーは英語と韓国語で利用でき、確認したいアドレスを入力します。結果は、次のいずれかです：

• このアドレスはメールを受信できます — メールサーバーが受信者を受け付けました。
• 存在しないアドレスです — アドレスの形式が正しくない、ドメインにメールサーバーがない、またはサーバーがそのようなメールボックスはないと答えました。
• 確認できません — ドメインがキャッチオールである、サーバーが確認を拒否した、または確認自体ができませんでした。どの理由に当てはまるかは、ツールが教えてくれます。

このツールが大量のアドレスの調査に使われないよう、1日に行える確認の回数には限りがあります。リスト全体は、1つずつアドレスを確認するのではなく、送信の流れの中で確認してください。

確認できないアドレスは、どう扱えばよいですか？

分けて管理し、少ない数ずつに分けて送信し、5.x.xのコードでバウンスしたものは削除します。実用的な順序は次のとおりです：

1. 構文の確認に通らないもの、またはメールサーバーがないものを外します。
2. サーバーが存在しないと答えたアドレスを削除します。
3. 確認できたアドレスに、先に送信します。
4. 「確認できません」と表示されたアドレスには、より慎重に送信し、恒久的なバウンスで返ってきたものは削除します — YahooとGoogleの両方が助言しているとおりです。

また、有効なアドレスだからといって、受け取る意思のある相手とは限らないことも覚えておいてください。迷惑メールの報告は、アドレスが存在するかどうかにかかわらず、あなたの不利に数えられます（その数字は、コールドメールが迷惑メールフォルダに入る理由で扱っています）。

要点まとめ

• 3つの手順で確認します：構文 → MX検索 → SMTPでのメールボックス確認（RCPT、内容は送らない）。
• @より前の部分は最大64文字まで（RFC 5321）で、ヌルMXは、そのドメインがメールを受け取らないことを意味します（RFC 7505）。
• キャッチオールのドメインはすべてのアドレスを受け付けます — 25のドメインでの当社のテストでは、約25%がそうでした — そのため、「確認できません」としか判定できないアドレスもあります。
• バウンスでは、5.x.xは恒久的で4.x.xは一時的であり、5.1.1はメールボックスが存在しないことを、5.7.xはアドレスの不良ではなくポリシーの問題を示します。
• 1つのアドレスは、当社の無料メールチェッカーで試せます。