How It Works

EmailVerify は、メールの配信可能性を正確に判定するためにマルチレイヤー検証アプローチを使用します。各メールは、可能な限り正確な結果を提供するために複数の検証段階を経ます。

検証プロセス

メール送信
      ↓
┌─────────────────┐
│ 1. 構文チェック │ → 無効なフォーマット？ → 無効を返す
└────────┬────────┘
         ↓
┌─────────────────┐
│ 2. ドメインチェック │ → ドメインが存在しない？ → 無効を返す
└────────┬────────┘
         ↓
┌─────────────────┐
│ 3. MX レコード    │ → メールサーバーがない？ → 無効を返す
│    検証          │
└────────┬────────┘
         ↓
┌─────────────────┐
│ 4. 使い捨て      │ → データベースと一致？ → 使い捨てとしてフラグ
│    検出          │
└────────┬────────┘
         ↓
┌─────────────────┐
│ 5. SMTP チェック  │ → メールボックスが存在しない？ → 無効を返す
│    （オプション）  │
└────────┬────────┘
         ↓
┌─────────────────┐
│ 6. スコア        │ → 信頼スコアを計算
│    計算          │
└────────┬────────┘
         ↓
    結果を返す

検証段階の説明

段階 1: 構文バリデーション

まず、メールアドレスが有効な RFC 5322 フォーマットルールに従っているかをチェックします：

• @ 記号が正確に1つ含まれている
• ローカルパート（@より前）が命名規則に従っている
• ドメインパート（@より後）が正しくフォーマットされている
• 無効な文字が含まれていない

例：

• user@example.com - 有効な構文
• user.name+tag@example.co.uk - 有効な構文
• user@ - 無効（ドメインが欠落）
• @example.com - 無効（ローカルパートが欠落）

段階 2: ドメイン検証

ドメインが実際に存在し、適切に設定されているかを確認します：

• ドメインの DNS ルックアップ
• ドメイン登録ステータスの確認
• ドメインがブロックリストに載っていないかの確認

段階 3: MX レコードチェック

ドメインがメールを受信できることを確認するために、ドメインの MX（Mail Exchange）レコードを DNS に問い合わせます：

example.com → MX: mail.example.com (Priority: 10)
            → MX: backup.example.com (Priority: 20)

MX レコードがないドメインはメールを受信できません。

段階 4: 使い捨てメール検出

5000 以上の既知の使い捨てメールドメインのデータベースを維持しています：

• 公開使い捨てサービス（Mailinator、10MinuteMail など）
• プライベート使い捨てドメイン
• 一時メールジェネレーター
• エイリアスサービス

データベースは毎日新しい使い捨てドメインで更新されます。

段階 5: SMTP 検証

最も正確ですが、最も複雑な検証ステップ。以下を行います：

1. 受信者のメールサーバーに接続
2. SMTP 会話を開始
3. 特定のメールボックスが存在するかを確認
4. 様々なサーバーレスポンスを適切に処理

HELO verify.emailverify.ai
MAIL FROM:<verify@emailverify.ai>
RCPT TO:<user@example.com>
→ 250 OK (mailbox exists)
→ 550 User unknown (mailbox doesn't exist)

段階 6: スコア計算

すべての段階の結果を組み合わせて信頼スコア（0.0 - 1.0）を計算します：

検証速度

異なる検証レベルには異なる速度プロファイルがあります：

エッジケースの処理

キャッチオールドメイン

一部のドメインは、メールボックスが存在するかどうかに関係なくすべてのメールを受け入れます。この場合：

1. キャッチオール設定を検出
2. 結果を accept_all としてフラグ
3. 中程度の信頼スコアを提供
4. これらのアドレスの処理方法はお客様の判断に委ねる

グレーリスティング

一部のサーバーは初回の送信者を一時的に拒否します。この場合：

1. グレーリスティングレスポンスを検出
2. 自動リトライロジックを実装
3. 効率化のために結果をキャッシュ

ターゲットサーバーによるレート制限

EmailVerify とターゲットメールサーバーの両方を保護するために：

1. 検証リクエストを複数の IP に分散
2. ドメインごとに適応型レート制限を実装
3. サーバーが要求する遅延を尊重

インフラストラクチャ

グローバル検証ネットワーク

• 複数のデータセンター: 米国、EU、アジア太平洋
• 冗長システム: 99.9% アップタイム保証
• スマートルーティング: 各検証に最適なパス選択

セキュリティとコンプライアンス

• すべての接続は暗号化（TLS 1.3）
• メール内容は保存されない
• GDPR 準拠のデータ処理
• SOC 2 Type II 認証

ベストプラクティス

いつ検証するか

検証頻度

• アクティブリスト: 四半期ごとに検証
• 非アクティブリスト（90日以上）: 送信前に検証
• 新規取得: 初回使用前に必ず検証

次のステップ