このドキュメントは、B2B 環境でビジネス電子メール アドレスを検証するために AI 主導のシステムで使用される標準、ルール、手順チェックを定義します。
これは、大規模なデータセット、CRM パイプライン、自動抽出システムに適用できる構造化検証フレームワークを提供します。

目的は、正確性、コンプライアンス、運用の信頼性を確保することです。

1.検証の範囲

検証標準は以下に適用されます:

• 抽出されたビジネスメール

• CRM からインポートされたメール レコード

• 強化されたサードパーティ データセット

• 見込み客発掘の出力

• 自動化されたアウトリーチ パイプライン

主な目的

• 無効または不正なメール アドレスを削除する

• 配信エラーを防ぐ

• 直帰率を減らす

• リスクの高いドメインまたは検証不可能なドメインを特定する

• ビジネス用メール ソースとビジネス用以外のメール ソースを区別する

2.定義

ビジネス メール
検証可能な企業、機関、または商用ドメインに関連付けられたメール アドレス。

検証ステータス
分類結果 (有効、危険、検証不能、無効)。

リスク スコア
配信失敗または ID の不一致の確率を表す数値評価。

MX レコード
ドメインのメール サーバーの能力を示すメール交換レコード。

3.検証カテゴリ

メール検証は、次の 4 つの主なカテゴリに分類されます。

カテゴリ A — 構文レベルの検証

メール形式が構造ルールと一致していることを確認します。

カテゴリ B — ドメインレベルの検証

ドメインが存在し、解決可能であることを確認します。

カテゴリ C — MX および SMTP レベルの検証

ドメインがメールを受信できるかどうかを検証します。

カテゴリ D — リスクと行動の指標

AI とデータ パターンを使用して信頼性を判断します。

これらのカテゴリは順番に動作しますが、独立してトリガーすることもできます。

4.構文検証標準 (カテゴリー A)

メールは RFC 5322 互換の構文ルールに準拠する必要があります。

必須コンポーネント

• ローカル パーツ

• 「@」区切り文字

• ドメイン

構文エラーのフラグが立てられました

• 繰り返しのドット

• 先頭/末尾のドット

• 無効な特殊文字

• ドメイン セグメントがありません

• 空白文字の挿入

承認基準

構文検証が失敗した場合、メールはそれ以上のテストを行わずに無効としてマークされます。

5. ドメイン検証基準 (カテゴリー B)

AI はドメインレベルのチェックを実行して以下を確認します。

5.1 ドメインの存在

• DNS ルックアップ

• WHOIS の利用可能性

• ドメインの有効期限

5.2 ドメインの分類

• ビジネス ドメイン

• 使い捨てドメイン

• 無料メール プロバイダ

• 個人メールボックス ドメイン

5.3 企業のリスクシグナル

• 非アクティブなウェブサイト

• 期限切れの SSL 証明書

• 企業メタデータが一致しません

有効なビジネス エンティティとして分類されたドメインのみが MX 検証に進みます。

6. MX および SMTP 検証プロトコル (カテゴリー C)

このカテゴリは、ドメインのメール受信能力を検証します。

6.1 MX レコードのチェック

• MX エントリの存在

• サーバーの優先順位付け

• サーバーの一貫性

6.2 SMTP シミュレーション ロジック

AI は、メール転送を完了せずに非侵入的なシミュレーションを実行します。
チェックには次のものが含まれます。

• 「RCPT TO」応答動作

• キャッチオール検出

• メールボックスの存在確率

6.3 サーバー動作の解釈

サーバー応答には次のものが含まれる場合があります。

• 同意する

• 拒否

• すべてを受け入れる

• 一時的な拒否

• 曖昧な応答

AI はあいまいな結果を確率的なカテゴリに分類します。

7.リスクスコアリングモデル (カテゴリー D)

検証で配信可能性を確認できない場合は、リスク スコアが割り当てられます。

リスク指標

• 汎用受信トレイ (info@ / sales@) の使用

• キャッチオール ドメインの動作

• 企業活動の低下の兆候

• 不審なドメインまたは最近作成されたドメイン

• ソース間でメタデータが一貫していない

リスク スコア スペクトル

• 0～20: 高い信頼度

• 21～50: 適度な自信

• 51～80: 高リスク

• 81～100: 非常に高リスク / 検証不能

送信システムは、60 を超えるスコアを制限付きとして扱う場合があります。

8.多層の意思決定ロジック

すべてのチェックの後、AI は次のいずれかのステータスを割り当てます。

有効

構文が正しく、ドメインが解決され、MX が検証され、リスクが低い。

注意が必要です

構文が正しく、ドメインが有効で、キャッチオールまたは曖昧な SMTP 応答。

危険

複数のリスク指標、部分的な検証のみ。

検証できません

構文は正しいですが、ドメインが一貫性がない、または曖昧で、信頼できる MX 応答がありません。

無効

構文またはドメイン解決に失敗しました。

このロジックにより、大規模なデータセット全体で一貫した分類が保証されます。

9.エッジケースの処理

システムは以下を正しく処理する必要があります:

• エイリアスベースのメール

• 転送専用ドメイン

• 最近登録された企業ドメイン

• マルチテナントのメール プロバイダ (例: SMB 向け Google Workspace)

• 地域ドメイン構造 (例: .com.cn、.co.uk)

エッジケースの処理により、グローバル データセットの精度が向上します。

10. SaleAI コンテキスト (非プロモーション)

SaleAI エコシステム内:

• データ エージェントは、構文、ドメイン、MX、および行動リスク シグナルを分析します

• CRM エージェントは検証出力を使用してシーケンスとアウトリーチ フローを保護します

• ブラウザ エージェントは、Web ソースと対話するときに企業のドメイン コンテキストを検証します

SaleAI は検証基準を変更しません。上記の標準化されたルールに従います。

11.制限事項

AI ベースの検証では次のことができません。

• サーバーレベルのプライバシー制限をバイパスする

• 受信トレイの ID を保証する

• 内部転送ルールを検出する

• サーバーの一時的な停止を検証する

これらの制限は電子メール インフラストラクチャに固有のものであり、システムの欠陥ではありません。

結論

ビジネスメール検証には、構文、ドメイン、MX、行動指標にわたる体系的な多層テストが必要です。
AI は確率的推論、コンテキスト強化、リスク モデリングを適用することでこのプロセスを強化し、より正確でスケーラブルな検証を提供します。 B2B データ品質のためのソリューション。

標準主導のアプローチにより、信頼性が確保され、運用リスクが軽減され、下流の CRM 自動化がサポートされます。