メール検証ツール
アドレスの形式と、ドメインがメールを受信できる設定かを確認します。この高速バリデーターは SMTP 検証を行わないため、メールボックスの存在までは確認しません。
email validator は verifier より狭い問いに答えます: この文字列はメールサーバーを公開するドメイン上の整形式アドレスか？それは形式と MX であり — 人や受信箱の存在の証明ではありません。
検索者は「email validator」「validate email」で高速・無料の初篩を求めます。BillionVerify はこのページを誠実に保ちます: 偽の到達性主張なし、SMTP ハンドシェイクなし、正当な利用向けの無制限浅いチェック。
バウンスリスクが重要なときは Email Checker または Email Verifier へ進みます。これらのツールは同じ形式基盤の上にメールボックス探査とリスクフラグを追加します。
2 層のみ。意図的に SMTP なし。
実用的な形式ルールでローカルパートとドメイン形状をチェック。誤字はミリ秒で失敗します。
公開メール交換レコードを確認します。見つからなければ、この浅いバリデーターは MX なしと報告し、メールボックステストの前に止まります。
SMTP 会話は開きません。catch-all ドメインでもこの validator を通過できます。
到達性が必要なら、Email Verifier と Email Checker が同じプロダクトスタックで SMTP を実行します。
速度がメールボックス証明より重要なとき、浅い検証を使います。
フォームフィールドと手入力は形式エラーを生みます。より深いチェックの前に修正します。
公開 MX 経路は通常の DNS ゲートをクリアします。公開 MX がなければこの浅い確認は止まり、SMTP 枠を使わず理由を示します。
大リストの一括 SMTP ジョブ前の安い第一フィルター。
形式+MX OK をコールドメール安全と見なさないでください。それには SMTP ツールを使います。
これらは対話型 Email Verify Tools — 一括ジョブでも API でも Free Tools（DNS / SPF / DKIM）でもありません。
本ページは形式と MX のみを返します。他のツールは SMTP を追加するか、1 つのリスクフラグに特化します。
| ツール | できること | 使う場面 |
|---|---|---|
| メール検証ツール | SMTPメールボックスの完全チェックとすべてのリスクフラグ | 配達可能性と発送の安全性が重要な場合 |
| Email Checker | 1 アドレスにフル SMTP + 全リスクフラグ | 一か所で完全な多層結果が欲しいとき |
| Free Email Checker | 無料個人ウェブメールプロバイダーを検出（Gmail、Yahoo など） | リード品質と B2B ドメインスコア — 無料枠検証ではない |
| Email Validator | 構文 + MX のみ — SMTP なし | 高速な形式とドメイン初篩 |
| Disposable Email Detection | 一時 / 捨てドメインにフラグ | サインアップとリード獲得 |
| Bounce Email Checker | バウンスと到達不能リスクに焦点 | バウンス率管理のためのリスト衛生 |
| Catch-All Verifier | catch-all ドメインを検出 | SMTP 受理が信頼できないとき |
| Role Account Detection | 一般的な役割アドレスを検出 | B2B アウトリーチ品質 |
| Email List Cleaning | 多数アドレスを一度に検証（貼り付けまたは CSV） | 単一チェックでは足りずクリーンなリストが必要なとき |
| メールアドレス逆引き検索 | メールアドレスから公開されている所有者と企業情報を検索します | リードリサーチと送信者不明の調査 |
| 電話番号検証ツール | 電話のフォーマット、国、タイプ、およびE.164出力を検証します。 | CRM アウトリーチ前の電話の整理 |
形式と MX OK は、アドレスが整形式でドメインが MX 経路を公開していることを意味します。メールボックスの存在は意味しません。無効構文は直ちに止まります。公開 MX なしはこの浅い確認を止めますが、暗黙 MX の特殊ドメインは手動レビューが必要なことがあります。
本ページでは設計上、使い捨て、catch-all、バウンスの読み取りはありません。それらはフル検証または専門ツールが必要です。
2 層の検証
バリデーターは意図的に、安価な 2 層のあとで止まります。フォームと事前スクリーニング向けに速くしつつ、結論をフルメール検証より狭く保ちます。
BillionVerify はローカルパートとドメインを分け、入力を正規化し、欠けた部品、壊れた区切り、アドレスパーサーが受け入れられない位置の文字などの構造失敗を拒否します。ネットワーク照会の前に、よくある入力ミスとコピー＆ペースト問題を捉えます。
構文パスは受信者のプロバイダーに問い合わせません。文字列がすべての形式ルールに従っても、メールを受け取らないドメインや、作られたことのないメールボックスを名指しすることがあります。構文は最初のゲートとして扱い、最終到達性結果にはしないでください。
ドメインネームシステムは、送信者を受信サーバーへ導くメール交換レコードをドメインが公開できるようにします。BillionVerify は構文通過後にその経路文脈を解決します。使える経路は、ドメインがメール配送に参加する設定であることを意味します。
MX 根拠はドメインに適用され、正確なローカルパートには適用されません。同じメール経路が、稼働従業員、廃止エイリアス、未割当名、グループ受信箱、catch-all 挙動を支えられます。だから結果はメールボックス検証済みではなく、形式と MX OK と言います。
ドメインは、メールを受け入れないと明示するために Null MX レコードを公開できます。IETF の RFC 7505 Null MX はこのシグナルを定義し、メールをオプトアウトしたドメインへの配送試行で時間を無駄にしないようにします。
明示 MX レコードがないことは、SMTP が歴史的にドメインのアドレスレコード経由のフォールバックを定義するため、すべての技術文脈で同一ではありません。この浅いページはその暗黙 MX フォールバックを行わず、両方のケースで公開 MX なしと報告するため、特殊ドメインは最終拒否の前にレビューが必要です。
このページは受信者会話を開かず、メールボックスコマンドをテストせず、プロバイダー挙動から受理を推論しません。メールメッセージは送られません。限定範囲により、バリデーターは迅速な事前スクリーニングに適し、メールボックス根拠が必要な確認のためにフル SMTP 枠を残します。
正確なメールボックスが重要なときは、Email Verifier へ進んでください。同じ構文と経路の基盤を適用し、受信者レベルの SMTP とリスクシグナルを追加します。
検証結果
浅い結果は、ラベルが精密なままのとき役立ちます。誤りは、形式またはドメイン根拠をメールボックス根拠と呼び替えたときに起きます。
この結果は、アドレスが構造的に使え、バリデーターのルール下でドメインがメール受信インフラを露出していることを意味します。前向きな事前スクリーニングであり、メールボックスを到達可能と呼ぶ許可ではありません。
フォーム入力を暫定的に受け入れる、補強パイプラインを続ける、フルジョブ前に明らかに不可能な行を減らすために使ってください。ハードバウンスに運用コストがあるメッセージを送る前に SMTP を追加してください。
パーサーは入力を使えるアドレスとして解釈できません。よくある原因は、欠けた @、不完全なドメイン、値の途中にコピーされた空白、句読点の誤りです。
元フィールドをユーザーに見せ、直させてください。欠けた文字を自動捏造したりドメインを置き換えたりしないでください。構文的に良くなった推測は別人物に属することがあります。
検証ルール下でドメインに使える経路がないとき、メールボックス検証を続けても現行アドレスは救えません。誤字、失効、パーク、意図的にメールを受け入れない設定であることがあります。
汎用の invalid ラベルではなく理由を返してください。ドメインレベルの失敗はデータ修復に実行可能であり、それ以外は機能する会社ドメイン上の受信者拒否とは違います。
メールボックスは未割当、無効、満杯、プロバイダーポリシーで保護、catch-all 挙動の裏にあることがあります。アドレスは使い捨て、ロールベース、記録上の人物と無関係であることもあります。
それらはバリデーターの欠陥ではなく、構文と DNS の外の問いです。完全な単一アドレスパネルが必要なときは Email Checker を使ってください。
高速事前スクリーニング
バリデーターは不可能な入力を早く除くとき、時間とネットワーク作業を節約します。メールボックスとオーディエンス判断は後段が担います。
フォーム入力時または送信直後に構文検証を実行してください。ユーザーがページを離れたあとに不正アドレスを見つけるより、フィールド横の明確なメッセージの方が役立ちます。
入力途中の過度に攻撃的なリアルタイムブロックは避けてください。安定した操作点で検証し、入力値を残して、オートコレクトルールではなくユーザーが修正を選べるようにしてください。
フォームが業務上重要なときは、一般分析に完全アドレスではなく理由カテゴリを記録してください。製品チームは、検証イベントストリームを第二の連絡先データベースにせずに、失敗が構文か DNS かを知る必要があります。
公開 MX なしの結果は、メールボックス探査や連絡先補強の前にこの浅いパイプラインを止めます。早い DNS スクリーニングは不要な下流作業を減らし、暗黙 MX に頼る特殊ドメインは、通常のハード失敗として静かに扱わずレビューへ回すべきです。
DNS は一時失敗し得るため、再試行挙動は妥当に保ってください。確認済みのメールなし状態と、完了できなかった照会を区別し、一時インフラ失敗を顧客データの恒久削除にしないでください。
ワークフローがきれいな形式とメール対応ドメインだけを必要なら、ここで止めてください。オンボーディング、営業、パスワード、請求、キャンペーンメールを送るなら、送信イベントの近くでフル SMTP 検証へ進んでください。
この層別アプローチは、到達性の基準を下げずに速い確認を速く保ちます。結果名はデータと一緒に移動し、下流システムが検証済みかフル検証済みかを分かるようにするべきです。
有用なフィールドモデルは、構文ステータス、公開 MX ステータス、検証深度、確認時刻を別に保存します。後のエクスポートが形式と MX 成功を誤解を招く verified ブールに平らにするのを防ぎます。
大きなファイルには一貫した重複排除、ステータス処理、再試行論理、エクスポートが必要です。浅いバリデーターはデータセットを事前スクリーニングできますが、どの正確な受信者が SMTP 探査を受け入れたかはキャンペーン運用者に伝えられません。
キャンペーン規模の検証には Email List Cleaning を使い、構文、経路、SMTP、リスク理由を別出力フィールドとして残してください。
誠実な限界
テストした層を省くと、valid という語は誤解を招きます。BillionVerify は層に名前を付け、ユーザーが正しい次ステップを選べるようにします。
バリデーターは受信システムに対象ローカルパートを尋ねません。だから company.com がメールを受け入れても、jane@company.com が割り当て済みかは確立できません。
構文と MX だけで到達可能と主張する結果は、根拠を過大に述べています。BillionVerify はメールボックスレベルの言葉をフル SMTP ワークフローに予約します。
Catch-all ドメインは有効なメールインフラを持ち、任意のローカルパートを受け入れることがあります。アドレスは完璧に見え、ドメインはメールを経路できても、指名された人物レベルのメールボックスは未確認のままです。
そのドメイン挙動を理解するには Catch-All Verifier を使い、個別検証済みと呼ばず catch-all 連絡先をレビューセグメントに残してください。
これは生成された B2B パターンで最も重要です。会社ドメインで firstname.lastname を推測すると、すべての従業員名で構文と MX を通れますが、catch-all 挙動はそれらの浅い確認が推測受信者を確認するのを妨げます。
DNS レコードは CRM 行に付いた人物について何も言いません。ドメインはメールを正しく経路しても、アドレスに付いた氏名、雇用主、役職、同意が誤っていることがあります。
身元と許可には一次または認可済み根拠が必要です。検証は技術的な入力誤りを防ぎますが、第三者連絡先データを検証済み身元に変えません。
身元の信頼度は技術検証と別フィールドに保ってください。営業チームは、アドレス構造と公開メール経路が独自確認を通った事実を失わずに補強ソースをレビューできます。この分離は後のデータ品質監査も説明しやすくします。
有効な宛先でも、送信者評判が低い、認証欠落、リスクの高いコンテンツ、不健全なキャンペーン挙動があると、メッセージはスパムに入ります。それらの条件は送信側にあります。
送信ドメインの準備には Email Deliverability Test を使ってください。同じ送信ワークフローで、受信者検証と送信者到達性を別コントロールとして保ってください。
プロトコル参照
アドレス文法、DNS メール経路、SMTP 受信者応答はインターネットメールの別部分です。製品境界はそのアーキテクチャに従います。
IETF の RFC 5322 Internet Message Format はメールアドレスとメッセージを表す構文を定義します。文字列をアドレスとして解析できるかの判断の基盤です。
文書はメールボックスの存在を証明するネットワーク照会を提供しません。BillionVerify はその区別を検証結果に見えるままにします。
IETF の RFC 5321 Simple Mail Transfer Protocol は、受信者コマンドと一時対恒久の応答クラスを含むメール交換挙動を定義します。それらの受信者応答はフル検証に属し、このページには属しません。
バリデーターはドメイン準備を確立するのに必要な経路層を使い、受信者対話の前に止まります。その結果は速く、説明可能で、正しく範囲が限定されます。
消費者ウェブメールの分類には Free Email Checker、捨てプロバイダーの特定には Disposable Email Detection、現行メールボックス受理が必要なときはフル検証を使ってください。
仕事が不正入力と、メール受信設定のないドメインを捉えるだけなら、Email Validator は正しい出発点のままです。
この email validator は 2 層のみを確認します:（1）アドレスが整形式か（構文/構造）、（2）ドメインがメール受信可能な MX を公開しているか。メールボックスと SMTP 会話は開かず、特定の人や受信箱の存在は証明できません。その誠実さは意図的です — 形式と MX は安い初篩であり、完全なメール検証ではありません。
いいえ。SMTP メールボックス検証は Email Checker、リストクリーニング、ログイン済みプロダクトフローで利用できます。validator は構文と MX で止め、高速で基本的に無制限（乱用防止のソフト制限のみ）に保ちます。バウンスリスクと到達性が必要なら Email Checker でフル SMTP 結果を開いてください。
高速な形式とドメイン初篩だけが必要なとき — 誤字の捕捉、MX のないドメインの拒否、重いジョブ前の事前フィルタ — に email validator を使います。誤ったアドレスがバウンス、ESP 罰則、無駄な SDR 時間になるときは email checker を使います。多くのチームはフォーム入口で validator 式チェック、キャンペーンや CRM インポート前にフル SMTP メールチェックを行います。
はい。浅い検証（構文 + MX）は無料で、Email Checker の 20 回フル SMTP 枠には制限されません。自動化乱用防止のためのソフトレート制限のみがかかることがあります。一括 CSV クリーニングと API 量にはアカウント登録が必要です。
無制限の浅いチェックには email validator:「メール受信可能なドメイン上のメールに見えるか？」多層検証には email checker: SMTP 到達性に加え使い捨て、catch-all、役割フラグ。答えは異なる問いです。validator 結果をフル検証のように使うのはよくある到達性の誤りです。
はい。catch-all ドメインは通常有効な MX を公開するため、特定のローカルパートが実在しなくても構文 + MX は問題なく見えます。catch-all の不確実性を示すのはフル検証ツール（Email Checker / Catch-All Verifier）だけです。names@company.com を推測してリードを増やすなら、validator だけに頼らないでください。
メールボックスレベルの証明とリスクフラグには Email Checker を実行するか、一括クリーニングと API アクセスのために登録してください。
24h で 20 回無料 SMTP チェック · 浅いチェックは登録不要 · 数秒で結果
